Thoughts that keep you awake
Why is it so hard to deal with changing requirements? Why is time pressure in a project forwarded to teams that are last in line, like developers and testers?
Above some thoughts that kept on spinning through my head the past months. Please allow me to take you with me on my trip in looking for answers on the above questions. This blog is not an extensive description on Scrum, there is an excellent document that explains Scrum in 5 minutes.
Why doing things differently?
When I first heard about agile project approaches in 2006, I felt that this was not applicable for the SAP world. Almost all projects used waterfalls (as ASAP describes). But things change, and so do SAP projects. With SAP NetWeaver, E-SOA and the openness of SAP as a Business Process Platform, the SAP work within a project has changed a lot. In the old days there was the customer, a project manager, a functional consultant and an ABAP developer (like me 😉
Now try to figure out how many different SAP roles you have in your current project (UI designer, Process design, Integration consultant, Web Dynpro developer, Java consultant, …)
Fortunately there is still a customer 😉 But he changed as well. In the old days a business process was captured in a blueprint, that was translated to a functional design and so on. Nowadays customers do not know exactly what they want. Well of course there are thoughts on the end situation, but not described in detail. So what happens during the project: specifications change on the fly (e.g. due to new insights). And even worse, delivery must be faster and faster. A quick response to market situations is a way to stay in business, to survive!
The traditional waterfall approach does not cope with these changes. As a result you get postponed delivery and huge overruns. So what can we do about it?
When I read ESME: anatomy of a community based project, I understood they used Scrum as the approach to deliver ESME. I was impressed how the team, in only 90 days, converted a dream into a real working application as shown on the SAP TechEd Demo Jam.
That triggered me into reading more on Scrum. Next was to search for experiences in the SAP projects world. I did find a blog SCRUM and SAP by Daniel Graversen on SDN. In a reaction Christiane Kuntz-Mayr stated that “the number of Scrum projects is increasing constantly” and “Lots op positive experiences within SAP”.
But still no ‘real life’ SAP project experiences. Time for me to attend a seminar on Agile development in practice hosted by Sander Hoogendoorn … I was the only SAP guy.
The SAP Scrum
So time to do the SAP Scrum.
(Image from Scrum alliance)
Learn by doing and gain experiences! This week we started the second phase of our project. The first phase was a traditional waterfall one and all participants felt the need for doing things differently. For this phase again time to realize is short and requirements are not perfectly clear yet. The perfect ingredients to do a Scrum. By doing so we want to achieve:
- Focus on the solution.
- Deal with changing and new requirements.
- Delivery in iterations, within fixed time intervals.
- Involve business by conducting demo’s after each iteration.
- A multi disciplinary team (SAP CRM, SAP XI, SAP ccBPM, Information analyst, Tester, ABAP developer) that takes its own responsibility.
- A Continuous process of tuning requirement priorities with the business.
- Eliminate ‘air’ in project planning by working multi disciplinary. No document validation process before the next role in line can start his or her work.
We want to realize our goals by:
- Working in sprints: three fixed time intervals of 4 weeks.
- Delivery in iterations: delivery of working parts (components or applications) at the end of a sprint.
- Compile the product backlog together with the product owner with clear priorities for all known and future items.
- The daily scrum stand up meeting of max 15 minutes where the scrum team members explain 1. What did you do yesterday, 2. What will you do today and 3. What prevents you from doing what you want to do. Only three questions to answer and no room for discussions in that meeting.
- Doing only activities that are necessary to deliver only what is really required (based on backlog priorities).
- End each sprint with a working demo and an evaluation of the sprint.
- Support by an Agile coach, Sander Hoogendoorn, http://www.sanderhoogendoorn.com.
Challenges
Challenges? Of course:
- Translating Scrum into the SAP project world.
- A multi disciplinary SAP team is formed by specialists (SAP CRM, SAP XI, Information Analyst, ABAP). How to deal with “There are no set project roles, everyone should be able to swap tasks with another member.”?
- What about end to end process testing when you deliver in iterations?
- How to prevent that our approach is Scrum in name only, as Sander describes in Why Newton was agile and the Titanic was not.
Interesting times ahead of us, I will keep you posted on our experiences. In the meantime feel free to share yours.
7 Comments
