Things you SHOULDN’T do in an agile SAP implementation

It’s one thing to have the desire to implement SAP software in an agile way, envisioning the benefits of significantly lower cost and much happier end-users.  It is a whole other thing to actually make it happen, resisting the constant desire to fall back to the old waterfall ways of doing things.  And have no doubt, that desire will be there for quite some time, like a juicy carrot on a stick – if only we could map the entire project in a Gantt chart, if only we could put a deadline on every task no matter how far out that task is, if only we could achieve precise estimates on anything and everything and compare them to actual time spent, then and only then we can take control of the project, determine exact go-live date and keep our executive management properly informed.  Falling into this type of thinking in an agile project is very simple.  Having the understanding, discipline and commitment to the core principles of agile throughout the entire project is often very difficult.  This is especially true if this happens to be one of your first SAP implementations delivered through an agile methodology. In his article titled Scrummerfall: World’s Worst Software Development Methodology Aaron Erickson does a great job describing the typical mutation of an agile project into “scrummerfall”, the term that was originally coined by Brad Wilson and describes “the practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.”  In the world of SAP, which is still dominated by ASAP professional project managers, it is almost certain that anyone trying to implement SAP software in an agile way will face battles that Aaron describes in his article.  Talking to the client up front about these common pitfalls and coming to a mutual agreement on how to react when they arise is one of the ways that you can minimize the likelihood of getting your project into scrummerfall.  Here are some things that we at BestXperts have learned to watch out for:

Detailed long-term planning

Few projects are lucky to have executive management that understands and supports the absence of long-term planning and deadlines, so some form of such planning is usually unavoidable in an SAP project.  The mistake that many companies make is involving the majority of the project team in such planning.  If it takes more than 1 hour and 2-4 people to update your long-term plan, then you are doing it wrong.  You should utilize a few key solution architects to estimate the percentage complete on major features of the project and assess the velocity of your team to provide an overall project health status to executive management.  You should not engage the rest of your team in this counter-productive but often required task.  Keep them adhered to agile principles and focused on short-term commitments and getting things done.

Time-based estimates of tasks and user stories

SAP implementations come with a lot of user stories and tasks so it is quite easy to get lost in continuous management of estimates.  There is quite a bit of debate going on in regards to whether doing any estimation in software and IT projects is counter-productive.  Michael Dubakov, the founder of Target Process agile project management software package that we use here at BestXperts, presents a few good reasons for avoiding estimation alltogether in his article titled 5 Reasons Why You Should Stop Estimating User Stories.  If you absolutely must estimate the effort associated with your user stories and tasks try to utilize a relative point system, not hours.  Peter Sergeant does a great job explaining how to utilize points for estimation in his article Estimating like an Adult – What to Steal from Agile.

Bloated layers of management

It is quite common to have a large number of managers in a waterfall project – some responsible for building long-term plans and schedules, others who compose extravagant reports comparing estimates to actuals, yet another group of managers that are responsible for coordinating testing, integration, blueprinting, on and on and on.  Since agile either does away with or greatly reduces most of these tasks many companies find that managers are the ones who struggle the most with the adoption of agile practices, as opposed to business users and folks that do the actual work.

It is of utmost importance to help managers find their niche and clearly understand new responsibilities under the agile paradigm.  Scrum has a simple yet powerful delineation of management into 2 major roles – Product Owner and Scrum Master.  And despite what experienced waterfall SAP project managers will tell you, if done right there is very little that needs to be managed in an agile SAP project beyond what is already spelled out under these two roles.  Product Owners and Scrum Masters can and should be applied to other agile practices, like Kanban and XP.  One of the most critical responsibilities of a Scrum Master is ensuring that agile processes are adhered to.  In many ways this is a brand new role within an organization and the one that is often one of the major causes of falling into scrummerfall if not done properly.

Watch out for any managers that ask for team members to inform them of progress, roadblocks and questions via formal meetings and status reports.  In agile if you want to know something you need to get involved – attend the daily stand ups, take part of design and solutioning sessions, sit in on the demos.  But only do so if you intend to take an active role by driving decisions, enforcing agile practices and assisting the team with getting the work done, not just being a passive listener.

Separate distinctive phase for testing

This one is actually a lot easier said than done in an SAP implementation.  Due to high coupling and integration of functionality within SAP systems some form of integration testing is almost unavoidable in a separate phase of the project.  However, unit, functional and business acceptance testing should be happening continuously as user stories and features are being solutioned and demoed to business users.

Departmentalized team structure

Agile places significant emphasis on the use of cross-functional and self-sufficient teams.  This goes against the common structure of teams within waterfall SAP projects where developers, analysts, testers and instructional designers are often compartmentalized and separated into distinct units.  The pass-down mentality of such team structure is one of the major causes of poor velocity and lack of progress.  Wherever possible, look for building teams that are capable of scheduling and handling most of the work that is assigned to them on their own.  We find it helpful to build teams around a business process area, like Sales or Materials Management, and make sure to include members that are capable of performing blueprinting, configuration, development, testing, documentation and training as dedicated members of each team.  Due to the nature of SAP, some volume of pass down tasks from one team to the other is going to be present, but keeping it to a minimum and paying close attention to the completion of such tasks is key to a successful agile SAP implementation.