The Agile Sure Step Project Type: New Options for Implementing Microsoft Dynamics

September 20 2010

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.

FREE Membership Required to View Full Content:

Become a MemberLogin
Joining MSDynamicsWorld.com gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more, and it’s all FREE. You’ll also have the option to receive periodic email newsletters with the latest relevant articles and content updates. Learn more about us here
About Vjekoslav Babic

Vjekoslav Babić is an independent Microsoft Dynamics NAV consultant, trainer, author and blogger, with 10 years of experience in NAV and 16 years of experience in IT.

As a solutions architect and a project manager with a leading Microsoft Dynamics President's Club service provider company, as a Microsoft Dynamics NAV consultant with Microsoft Services, and as an independent consultant, he has been working on Microsoft Dynamics NAV implementations ranging from tiny one-man-bands to international mega-corporations, delivering services and trainings all over the world.

In 2008, Vjekoslav co-authored the acclaimed book "Implementing Microsoft Dynamics NAV 2009". Vjekoslav runs an active blog about NAV implementation, project management and development best practices, acts as a columnist and editorial advisory board member at MSDynamicsWorld.com, and as a columnist in a number of other web or printed periodicals in Croatia and worldwide. Vjekoslav is also a frequent speaker at Microsoft or Microsoft Dynamics conferences.

Since spring 2010, Vjekoslav has been awarded the prestigious Microsoft Most Valuable Professional (MVP) award for Microsoft Dynamics NAV.

More about Vjekoslav Babic

Comments

Steve_Goldstein's picture

An excellent introduction to a highly-relevant topic, my good friend. Unquestionably, SureStep has made major advances in each successive revision, and you have concisely highlighted many of the advantages and pitfalls of its foray into agile project process. In proper context, however, SureStep is a high-caliber methodology; a narrow focus adaptation of project framework (PMBOK in this case). How much of the additional weight of making SureStep a complete project solution, without diminishing its ease-of-use mission, remains to be seen. Specifically, SureStep in its current incarnation is overwhelmingly a partner tool. This is understandable, given both its intended audience and the Microsoft channels for disseminating such tools. Critical elements of what PMBOK refers to as the Initiation and Planning stages of a project are assumed to have been completed by the client before the SureStep process begins. Those of us who have seen projects aimlessly meander for lack of a clearly articulated (and accepted) charter, executive endorsement and stakeholder vetting may surely grasp the signifigance of these "missing pieces." Adaptation of agile (agile SCRUM in your example) further tax these deficiencies. Strong client-side grasp of the principles and usage of project process AND SCRUM application may be viable within sophisticated, process-mature client environments. The client-side "spectator" role that often exists within waterfall deployments is likely incompatible with such approaches. Whether this constraint qualifies or disqualifies mid-market Dynamics users from a particular project deployment strategy is probably best evaluated on a case-by-case basis. The underlying question where agile strategies are being contemplated, however, is often one of whether a client is "adept enough to be agile." Vjeko, you've correctly cited many of the departures from generally-accepted partner approaches inherent in an agile SureStep strategy. Surely a reliance upon multiple iterations of user acceptance testing-- a frequent project bottleneck-- is beyond the current SureStep approach. This is, matters of practicality aside for the moment, curious as the textbook definition of "project" includes a mandate for reiterative capabilities. Correctly stated is that further refinement of the SureStep "big bang" deployment is needed before an incremental (read as "genuinely agile") project strategy may be accommodated. Being in full agreement that the SureStep foray into agile project strategies is a very promising work-in-process, I look forward to reading your further blogs on this topic.

Jim Wang's picture

Jim Wang MCBMSP :: http://jianwang.blogspot.com