For ages, consultants have delivered ERP projects in waterfall fashion, and to be honest, they didn't fare too well as far as project success was concerned. Budget overruns, missed schedules, scope creep or scope reductions - these have been more of a norm than an exception. And even though agile methodologies were gaining momentum, and getting accolades, the ERP world still preferred the thunder of the big-bang waterfall approach.

In its latest release, by offering support for the agile project type, Sure Step has made a giant leap into the realm of agile project methodologies. While Sure Step does not yet fulfill all the ideals of agile methodology, many of the building blocks are now in place to bring positive change to many Dynamics ERP projects.

Agile approach is radically different from the waterfall approach.

In waterfall, the implementation process is divided into distinct phases which are executed in a strict order, without a possibility of ever falling back to a previous phase or stage. All requirements are analyzed first, then functionality is designed, then developed, then tested and finally deployed. It is often also called the big-bang approach, because all the functionality is delivered at once.

A big risk of the big bang approach is that if there is a misunderstanding of a requirement, there are big chances that the solution will not match customer’s need, and this will only be found out very late in the project. Falling back is expensive, if not impossible, and costs of fixing these mistakes are often huge.

Agile methodologies, on the other hand, are iterative and incremental in their nature, focusing on delivering a functional whole through smaller chunks of functionality over a series of relatively short development cycles. By iteratively delivering smaller functionalities, the risk that the customer ultimately won’t get the right solution is effectively mitigated. If the solution delivered doesn’t fully match the need, it can be easily fixed during the next development cycle, customers generally get more influence over the design and development of the solution, and generally a deeper understanding of the requirements is achieved, resulting in a higher solution quality at often considerably lower costs. The drawback, though, is that agile projects can only be efficiently executed with a time and material agreement (we’ll look at this factor in more detail in another column).

In Sure Step, the agile project type starts with the detailed business process analysis and the definition of the high-level requirements, upon which the fit gap analysis is conducted. The output of fit gap becomes a cornerstone document for the agile project, which is called the Solution Backlog. The Solution Backlog is a living document that is used throughout the project to continually track current business and project priorities. Up to this stage, an agile project pretty much resembles the standard project type, and most of analysis activities executed in scope of a standard project are executed, to a varying degree of detail, in agile project as well.

The project execution is where the agile project is radically different. While traditionally in Sure Step project execution is split into two distinct phases - Design and Development - the agile approach executes the project through a series of 30-day sprint cycles. During each sprint cycle, a smaller subset of the requirements is taken from the Solution Backlog into the Sprint Backlog. Each requirement is broken down into smaller manageable tasks, no longer than 16 hours in duration, and assigned to developers.

During the execution of a sprint cycle, the project team gathers every day in a short daily sprint cycle meeting, where each team member shares what has been achieved since the last meeting, what is planned to be achieved until the next meeting, and which issues have been identified that interfere with the smooth execution of assigned activities. The goal of such meetings is to keep all the team members in the loop about what’s going on, to address issues early, and to eliminate any showstoppers quickly.

Developed functionality is consolidated once per day into the daily build which is deployed into the test environment. As soon as a requirement is deemed developed, it is immediately tested through a process called sprint testing. If any changes are identified during testing, they can be included in the next daily sprint cycle only if they wouldn’t impact with other deliverables, otherwise they have to be forwarded to the next sprint cycle.

At the end of a sprint cycle, the Sprint Technical Preview is executed together with the customer over a series of steps, where a customer reviews, and signs off on the developed functionality. Then a Sprint Post Mortem is held to communicate and document any lessons learned and to officially conclude the sprint cycle.

Then the next sprint cycle is initiated, and the process is iterated as many times as necessary until the solution backlog is exhausted. At this time, the development team executes a detailed Solution Testing activity to verify that the project requirements have been satisfied and that the solution operates as expected.

Following the Solution Testing, the project again starts to resemble the standard project type, as deployment activities are executed, and the solution is deployed into production.

If all of this sounds familiar, you are right—Sure Step agile project type draws its structure and guidance from Scrum, an increasingly popular and equally successful agile software development methodology. Sure Step team has done a fantastic job in matching and applying the Scrum guidance and theory to Microsoft Dynamics implementation process and specifics, and has also made a good decision by choosing an existing project framework, rather than developing one starting completely from scratch. The developers of the waterfall Sure Step method took a similar approach, building upon the very successful and acclaimed PMBOK standard.

Even though agile project type in Sure Step provides a good framework for environments in which requirements are volatile and fuzzy, Sure Step fails at achieving the most important goal of the Agile Manifesto: to deliver functionality to the customer early and incrementally. In Sure Step, the solution is only developed incrementally, while deployment still happens in a big bang fashion. There are many strong reasons why Sure Step takes this approach, one of them being ERP data consistency for example, but still there is a lot of room for improvement, which Sure Step will surely deliver over future versions.

After all, this is the first release of Sure Step that includes the agile project type. And even though there is much to be desired, the introduction of the agile project type into Sure Step is a promising move which encourages a completely different approach to implementing Microsoft Dynamics solutions, one that surely has more chance of delivering a better fit for customer’s requirements than other project types generally can.

This overview of the agile approach must have left a couple of questions open. Why would a Dynamics customer choose agile over waterfall approach? Are all the service providers going to be able to apply agile methodology in their projects? Do the benefits of agile really outweigh the comfort seemingly present with a fixed-price, carefully scheduled waterfall approach? We are going to address these and many more issues in upcoming columns.