Agile Software Implementations
Complex software implementations have always been a challenge for most businesses. The systems are complicated, they touch people, processes and other systems across the company and have a low rate of success. There are many reports published on implementation failure rates, for example the 2020 Standish Group Chaos Report shows only 31% of the studied projects were successful, while 50% were challenged and 19% outright failed. This is not a new topic, the low success rates have plagued implementations for years. The numbers do seem to be improving though. One of the reasons for that improvement is the growing use of agile methodologies for complex implementations.
The agile methodology was built to facilitate better software development. Through the years since it was developed though, its use has expanded to many new use cases including business operations, software selection and software implementation. Agile was developed with these 4 principals in mind:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Since we’re focused on implementation and not software development I won’t go through the full methodology, but if you want to learn more check out this agile 101 post from the Agile Alliance.
When should you use an agile methodology?
When the project is complex
When requirements are not clearly defined
When the requirements will likely continue to evolve and change during implementation
Adapting agile to other than software development use cases requires some modification and refinement. Applying agile in the strictest sense is probably not advisable for software implementations, mostly because the desired outcome is different from a software development project. For a dev project the “end result” is a minimum viable product (MVP) that is then incrementally improved over time based on user feedback. That doesn’t work for software implementation, which by its nature strives to deliver a fully functional system, not a MVP. The key components of the agile scrum approach do apply, including the daily stand-up meeting, operating in 2-4 week scrums, incremental and iterative development (and configuration), retrospectives, prioritized / reprioritized backlog, integrated team and user stories. Taking a more flexible approach to implementations leads to a hybrid agile - waterfall methodology.
The biggest shift is related to upfront planning. For an agile dev project the upfront planning is minimal, but for software implementation the project’s entire scope should be defined up front at a high level, including clear success criteria. This doesn’t mean that you build / use a rigid project plan though, instead the team has the freedom to refine the detailed scope and to manage priorities as they go through the project. Additional modifications include:
Start with a “standard” backlog and build off that with the project team (users)
A milestone plan (not project plan) can be used but it’s only a guideline, not a rigid set of deadlines
Demonstrate incremental progress on the solution to users after each sprint. After each sprint collect user feedback to roll into the backlog.
The production ready system is developed in phases and deployed in smaller increments.
The “product owner” is an in-house position, but an outside “advisor” can help keep focus on the business strategy and refine themes, initiatives, and epics.
The methodology works fine for in-house implementations and also for mixed teams that include a partner and/or vendor as long as all participants are trained.
For the sake of clarity it’s probably useful to make sure we have a common language around the methodology. Some agile terms seem to be used with slight variations among different groups. The backlog is built from user stories, and there is a structured way to break the stories down. The following diagram defines themes, initiatives, epics and stories.
As you can see, the format for the user story is straight forward; “As a I want to so I can .” This role based approach to the stories is critical to get the system configured correctly based on the needs of each functional area and a set of roles in each.
The hybrid methodology works nearly the same as any agile project. The differences mostly happen at the beginning of the project, as described above. The standard backlog is customized and the milestone plan is built. Here’s a process diagram of the overall project process:
Agile Implementation Process
Finally let’s look at the team structure. Here’s a diagram that breaks it down:
Agile Team Structure
If the project and organization are very complex, it may be necessary to modify this approach to a “team of teams” model, where multiple teams work in tandem but with a top level control element that keeps the backlog prioritized correctly and all the teams progressing on its specific subset of stories.
The shift from the traditional waterfall methodology to a hybrid agile approach has many benefits. It keeps the configuration and customization of the system in sync with the business strategy and the new and modified processes. Making sure the system correctly represents the evolving business strategy is critical for project success. It is usually much faster than the waterfall methods as well. The extensive use of user stories is far superior to rigid requirements and will improve project success rates.
