This summer I started working on an ERP implementation project that contains a fair amount of custom development. When I came to the project it was in iteration #2. This iteration was to focus on product definition. The project team was struggling to define the product requirements to obtain a design that could be implemented. They had been thrashing a little because so much of the product design was dependent on how the product would be used on the sales order.
When I arrived on-site, the sprint was already supposed to be complete. In fact, I was involved in a kickoff meeting intended to start capturing requirements for the Customer / Contact iteration (#3). However, the product design had been "completed" and data had been loaded but everyone knew it was not correct. They just didn't know how to make it correct yet because many of the design details would be discovered during the "Sales Order" sprint.
The project team was a little reluctant to define the customer requirements for the current sprint because they didn't want to end up in the same position with customer design that they were in with the product design. So a decision was made to start the "Sales Order" sprint right away and then use some of that discovery to "inform" the work in the "Customer Contact" and "Product" sprints so they can complete.
I'm sure you have guessed what happened. The attempt to capture "Sales Order" requirements dissolved into an attempt to understand "invoicing" requirements without starting that sprint also.
Did Agile Renege?
What happened to the "Agile" promise? You know, "early and continuous delivery of valuable software." One may argue that you can't expect an Agile methodology to deliver on a promise if core principles of the methodology are violated. For example, one of the principles is "Welcome changing requirements, even late in development." It is clear the team was not willing to live with unknown requirements, much less "changing" requirements.Before you write off this organization as ignorant of agile methods and assume the solution is simply found in training let me tell you that this is a business is a mature development organization that has been successfully delivering software using agile methodologies for three years. There may some missteps involved but most of the issue revolves around trying to stick the "square peg" of development methodology into the "round hole" of integrated ERP system deployment and implementation.
Microsoft (the ERP vendor) provides project guidance for using an "Agile" implementation methodology. If you google "agile implementation methodology" the pages found will fall into one of two categories:
- information on how to implement an agile methodology for software development
- Sales materials on how consultants and resellers will help you implement software using an "agile implementation methodology"
The Mythical Agile Implementation Methodology
What you won't find is any credible source that has actually defined an agile implementation methodology. There is a reason for this. Agile methodologies are applied to the domain of software development not general IT project management. The methodologies have one objective, build working software.Software development and system implementation are two completely different animals. As a small example of where the disciplines diverge simply take on of the basic processes in agile methodologies - refactoring. "Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior." (Martin Fowler)
The purpose for refactoring is to preserve the current software functionality while changing the design to support the addition of new functionality. Since agile projects to not capture requirements and do "big design" at the beginning of a project, they need to continuously modify their design to support newly discovered requirements.
With modern development environments and tools it is often very easy to refactor code and with automated testing strategies it can be relatively risk free. This is not true with implementations. How do you refactor an implementation simply and with little risk? I have seen attempts but have not seen a cost effective solution.
Another aspect that does not transfer from software development to implementation is "deliver working software frequently." How does the business community define "working software?" I define working as "using the software for the business purpose for which it was purchased." This excludes a "conference room pilot" from "working software." Implementations often require so many concurrently "working" pieces that it becomes difficult to draw any line in the sand for a single sprint. My conclusion is that wide-breadth, integrated systems (like ERP) by their very nature do not allow for "early and continuous delivery of valuable software." The breadth and integration creates so many dependencies that you can not "deliver working software frequently."
Let me say this a different way. If there is "go-live" date, you have a single point in time at which the software will be "valuable" and "working." That is not early and often. That is not continuous. That is "big bang."
Phased Implementation
My conclusion does not exclude iterative implementations. I simply contend that implementation iterations does not an agile methodology make. My recommendation is to iterate over the business processess defining requirements and possible solutions. These iterations can even produce useful (but not "valuable") conference room pilots. These pilots are often used to discover more requirements with changes in the current configuration. Much of this is messing and at times more closely resembles sausage making than software development.
Often these iterations may include actual development efforts that may be managed in an agile manner. Great! Scrum away, or use whatever agile methodology floats your boat. Just don't call your implementation agile.
Serious or Semantics
Is this really a serious topic or am I getting my shorts in a bunch over semantics. What difference does it make if we call it "agile" or "phased?"
My main concern is with successful implementations. To be successful an implementation has to meet business needs and it must do it in an affordable manner. A realistic project plan is mandatory to a successful implementation.
It is my opinion that the project approach that is being referred to as "agile" is neither workable nor agile. I want any project plan in which I have a stake to have a known path to success. If that path has a "go-live" date then I want to know the plan has a realistic management methodology that admits some sort of waterfall approach.
To have a minimal level of comfort in an implementation plan I need to see an integrated approach to managing the dependencies. Managing dependencies often means that all the related requirements are discovered and all the related designs are defined so all the related configurations can be determined and entered and all the related reference data can be defined and entered and all the dependent master data can be defined and entered / imported etc.
My next blog (hopefully less than 8 1/2 months from now) will include more detail on what this implementation methodology may look like.
