Why Agile SAP Teams Fail
Blog: Capgemini CTO Blog
Just as Cap-tivate embraces lean, and lean focuses on eliminating process defects, here are four key defects SAP project leaders should remove to optimize their agile process.
According to the 11th annual State of Agile Report™, the top three benefits cited by survey respondents for adopting agile are the ability to manage changing priorities, increased team productivity, and improved project visibility. Other benefits include cost and effort savings (up to 40%), faster deployments (by up to 50%), and the reduced risk that comes from reusing standard, prebuilt, and tested solution content — such as error-proofed business processes, SIPOC Visios, function tests, KPIs, and more.
But reusing error-proofed content does much more than just reduce risk; it also obviously speeds deployments and lowers software implementation costs. Instead of reinventing the wheel, you can focus 80% of your effort on the 20% that isn’t error-proofed yet because this is the new, non-standard code the customer needs in order to support its own particular way of doing business. That’s not just agile thinking; it’s lean thinking. Lean says to reuse what is proven and work on improving what remains — the defects. In other words, focus on the 20% that is not error-proofed (yet). That 20% is where 80% of project value comes from.
So, what’s good for our customers should also be good for us as SAP team leaders. Of all the things an SAP team leader can focus on, what are the 20% that, if fixed, would return an 80% improvement in project success rate? (Let’s define “success” as any project that returns a ringing customer endorsement.) Or, to put it another way, could 80% of project failures be avoided if a relatively few defects were fixed?
Here are four common agile process defects I nominate for that 20% bucket:
The Agile “Team” Is Not a Team
A key reason agile outperforms waterfall is because in waterfall everyone worked mostly in their own silos — architects with architects, developers with developers, testers with testers, and so on. But an agile team of, say, 10 will include people from different specialties. So there’s a high likelihood that the software that is implemented is software that will actually work as it was designed to work. The question leaders should then ask is: Do the people on this team really function as a team — as evidenced by close hour-to-hour collaboration and mutual trust — or are they mentally still back in their separate silos?
Projects Not Time Boxed
Another reason agile outperforms waterfall is that agile teams are committed to producing a working, demonstrable deliverable at regular short intervals — like every two to four weeks. That ensures rapid development and also that a product of actual value is being produced. But a couple of conditions have to be met for time-boxed activity to occur. First, the activity has to be carefully planned so that the goal is actually achievable. If planning is not given enough attention or not done by people with enough experience then the time box is meaningless. The second condition is to avoid scope creep. That’s when the customer or the consultants themselves see an opportunity to add “just a little more” in terms of features or functionality than was originally promised. Such add-ons should be put on the agenda for the next scrum meeting and — if justified — included in a new (time-boxed) sprint.
Lack of Training
This applies both to the agile methodology itself and to the host of new agile tools that SAP and Capgemini have introduced. For example, all our agile consultants should be able to answer questions like:
- What is a scrum?
- What is buildprint?
- What is the Digital Delivery Framework (DDF)?
- What project content does the DDF contain?
- What level of SAP processes undergoes agile development in Cap-tivate?
- PTP is a pre-populated value stream in Cap-tivate. What are the others?
Until consultants are comfortable using the tools, and speaking the language, of agile they are likely to struggle at being agile.
Lack of a Customer Champion
Many agile SAP teams struggle because they are working against a tide of internal customer resistance. Maybe key client stakeholders are old school. Maybe some feel like they can’t commit the time that agile requires for interacting with project team members. Maybe they feel that agile really means “holding the consultant’s hand.” Just like consultants need to be educated in order to become agile advocates, so too will many customers. You just can’t assume that customers will embrace what for many is an unfamiliar style of work. So selling the project may not be enough, you may also have to sell agile. And in particular you need at least one strong internal agile advocate on your side — someone typically placed high in the customer organization who understands agile.
That’s it. If we can consistently identify any of these four defects (where they actually exist) and fix them then I have no doubt we can achieve an 80% improvement in our project success rate. Then we can go ahead and identify the next 20% of things we need to focus on to achieve the next 80% improvement.
Leave a Comment
You must be logged in to post a comment.
