Many people don’t think that the words SAP and agile should appear in the same book, yet alone the same sentence. SAP projects take years to deliver and cost millions, don’t they? And according to many organisations still often fail, even when using the tried and tested “waterfall” or ASAP approach. So why on earth would anybody take the risk of trying to run a large scale SAP project using an agile approach?
Agile methods have been around for many years, and have been very successful in areas such as software development and web based applications. There are many different methods (DSDM, XP, SCRUM to name but a few) but to simplify greatly, they all focus on getting systems live more quickly by breaking work down into smaller, iterative chunks and following a leaner, more collaborative process.
However, following an agile approach in the SAP world can be tough for some of the following reasons:
- SAP governance and quality processes are typically designed to protect production systems and are usually slow and risk adverse. Many organisations have quarterly or monthly “release cycles” which don’t exactly scream agility but do reduce the number of “surprises” and live incidents. In addition, in some industries where SAP is very strong, such as pharmaceuticals or financial services, systems are heavily regulated and documentation intensive processes remain king.
- A typical SAP implementation covering several components of the Business Suite involves a large number of resources and skills sets. The coordination and communication effort across these different teams and individuals isn’t to be under estimated and can be a real barrier to agility.
- The resourcing model used for SAP implementations often needs very detailed functional and technical specifications which flow from experienced, skilled resources to lower cost, more junior or offshore developers and back again for testing and acceptance. This process can be slow and doesn’t lend itself well to agile development.
- There are complex inter-dependencies on other SAP components and environments which can hamper productivity, and a small change in one system can lead to cascading re-work in numerous different places. This also means that the overall solution progresses at the speed of the “slowest ship”.
- Core SAP processes and functionality can be time consuming and difficult to customise when needed, and doing this in small incremental steps might not be the most efficient or cost effective way to get the job done.
- The agile approach can be more expensive than alternative methods as it tends to involve more re-work and less optimal resource utilisation. However, these downsides need to be evaluated against the opportunity to realise some business benefits sooner.
- When many business processes are being implemented at the same time, e.g. Order to Cash, Purchase to Pay etc, these tend to be setup as separate teams which can result in a lack of synergy between them and conflicting demands which need to be managed and resolved.
- Agile tends to focus on short term results at the expense of the longer term “right thing to do”. This means that “greater good” decisions are avoided, such as hardware or software upgrades, as they will hamper agility. Getting agreement and planning for the implementation of a SAP support pack on one project was a major achievement which took a lot longer than it should have done.
- Trying to build a business case when you don’t know exactly what you’ll get for what cost requires either a leap of faith, or the courage to pull the plug on a project which isn’t delivering the expected benefits. Trying to manage suppliers in agile world is particularly challenging as whilst the timeline might be fixed, scope and quality can still vary enormously.
- Many team members become indispensable with the agile approach, and documentation isn’t always a priority. This means that the impact of someone leaving the project can be a significant set back as much of the knowledge will walk out the door with them. For the same reason, brining new people onto a large “agile” project which is already underway can be a daunting prospect.
The good news is that none of these challenges are insurmountable on their own, but you will have a bumpy ride adapting your organisation, processes, support models and corporate mindset to an “agile SAP” approach. At Bluefin, we like to think we’ve pioneered the use of agile methods in the SAP arena. We started initially with areas such as BW and CRM which lend themselves more naturally to the agile approach, but within the last year have actually been involved in full scale agile SAP implementations.
We’ve tended to use the SCRUM approach, which aside from some rather humourous terminology, is actually grounded in common sense and has proved very workable. Here are a number of “lessons learned” and observations from following this approach on a number of engagements. Please bear in mind that these are based on real world experiences, rather than the pure theory of the agile or SCRUM approach!
- Agile tends to mean different things to different people and communities within an organisation so clear and consistent communication is needed about “the move to agile”. Stakeholders and “the business” tend to love the agile message as they hear it. They think it means they can change their minds all the time and don’t need to be as precise when it comes to scope and requirements. In a world of unlimited funding, this would be largely true but sooner or later the commercial reality bites and some hard questions are asked about whether the scope delivered for the price represents good value. Project teams and developers on the other hand love the sound of just getting on and doing stuff, without lengthy processes, controls and documentation.
- Chose a suitable first trial project with a trusted business customer, a real problem and challenging timescales. This is ideally an extension to existing functionality such as Employee Self Service, and shouldn’t be primarily a roll-out exercise (remember agile is development rather than deployment oriented). Try to have something with a strong visual element where progress and daily changes will be very evident.
- Don’t just get a bunch of people together and start “doing stuff”. You need a real problem to solve and genuine business demand leading to an empowered Product Owner. When you’ve got several potential initiatives, you’ll still need a mechanism for evaluating the costs and benefits and a prioritisation process.
- Give careful consideration to how many SCRUMS you’ll be running and the resource mix of each. As the number of SCRUM teams increase, so does the complexity of coordination, communication and the risk of conflicting development.
- You can’t expect project teams to adapt to new methods overnight. Training, education and coaching are needed, as is some serious change management to sell the benefits and overcome the cynicism which traditionally accompanies the move to agile.
- The agile world lends itself to having fewer, more skilled senior resources and this is especially true in the SAP world. Team members need to be able to think, design, develop, troubleshoot, test and communicate, often at the same time! Weaker resources soon stand out and become a bottleneck.
- The pressure to deliver is constant and relentless. Keeping the team focused and motivated on longer engagements is a real challenge. Holidays, training courses and sick days can have a significant impact when get used to having constant access to everyone at any time of the night or day!
- Things will go wrong. You need to be pragmatic andadapt. If a finger pointing culture starts to emerge, it needs to be quashed quickly or it will poison the environment and lead to risk avoiding behaviours.
- Use some form of micro-blogging so that everyone knows what you’re doing at all times. This helps prevent misunderstandings, promotes good communication and also saves time. We’ve used Present.ly in this space and feedback has been consistently good.
- The concept of regression testing doesn’t easily fit into agile methodologies where development often goes to the wire. When you’re building on critical SAP systems, it’s the only way to ensure that your “working software” doesn’t lead to broken software somewhere else.
- When multiple components and technologies are being used at the same time, there is a tendency for teams to seek out the “weakest link” and try to pin responsibility for under delivery or slippage on them. This is a cultural problem which needs to be addressed – the whole project succeeds or fails, not individual parts of it.
- The impact on support models and organisations must not be an after thought. Throwing something into production and then immediately focusing on the next iteration of delivery isn’t likely to win the project or the agile approach any popularity contests. It’s a fact that this approach results in more support incidents, not less, and so planning for these is essential. All too often the project team ends up doing development and live support at the same time, to the frustration of all!
- Having remote resources can work, provided that they 1) are in the same time zone, or prepared to work in the same time zone 2) are strong resources in terms of skills and communication 3) use technology such as tele-conferencing, webcams, screen sharing and instant messaging to break down the communication barriers and ensure that out of sight doesn’t mean out of mind.
Good luck with your aligning your SAP projects to agile – I’m sure you’ll have as much fun as we did and learn an awful lot along the way.