I couldn’t count the number of times that I’ve heard jokes about SAP and Agile and the countless sighs and shrugs that soon follow. I’m no CRM expert and I’m certainly no SAP expert, but the limited amount of knowledge I do have about them is enough to color my opinion about how hard it truly is to achieve agility within a robust and rigid SAP environment.
There are, however, some guys out there that make their living kicking butt in SAP environments and utilizing some facets of Agile. Mike Curl, from Bluefin tells us how to implement Agile within SAP:
- Chose a suitable first trial project with a trusted business customer, a real problem and challenging timescales.
- 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.
- 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. Agile 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.
- Things will go wrong. You need to be pragmatic and adapt. 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.
- 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.