OUTSIDE THE BOX Forum: When is Agile Required?
We’ve all read articles that talk about choosing between traditional approaches and agile approaches.
Traditional projects can use an agile approach but agile projects cannot use a traditional approach.
There are some projects where that choice is a valid concern. But there are projects where some type of agile approach is not an option. It is a requirement. These are projects where the goal and/or the solution are not clearly defined or understood. In such cases the discovery of the missing piece(s) must be imbedded in the work of the project and that can only be achieved through some form of iterative process. Each iteration is an attempt to learn or discover missing parts of the goal and/or solution. After some number of iterations the goal and solution will be clearly known. To avoid an agile approach some traditionalists might try to jury rig their favorite waterfall model but that thinking is seriously flawed.
So complexity and uncertainty are the factors that lead to the conclusion that some type of agile approach is needed. But agile is a journey not a destination. There are several different agile approaches. So how do we choose the one that is the best fit given the project characteristics? Let’s try to answer that question.
THE COMPLEX PROJECT LANDSCAPE
The most intuitive illustration of the situation is the four-quadrant landscape defined by the two project characteristics: goal and solution. Every project has a goal and a solution to achieve that goal. Complex projects lack some clarity of goal, solution, or both and are found in Quadrants 2, 3 or 4. All of them will require some type of agile model.
Figure 1: The Complex Project Landscape
Agile Models Ranked from Mostly Defined to Mostly Undefined
After 25 years of client engagements where all types of agile projects were planned and executed I have adopted a ranking from mostly defined to mostly undefined. You might also use least complex/most certain to most complex/least certain. This is not an objective ranking. There are at least a dozen models that could be included. I’ve only chosen five for this article to illustrate the point. Each is briefly discussed. For a more complete treatment see [Wysocki, 2013]. The ranking is quite subjective but based on my personal experiences in using the models. There are also variants of each of these that affect their application.
Prototyping
This is a tried and true approach couched in the language of the client. There are a variety of variations from iconic models to production models. Prototyping is a very robust tool with a long history of uses including even the most complex and uncertain of project situations. Those would be situations where the project manager is using prototypes to suggest a starting point for the client to get on board with the search for a solution. Prototyping is a tool that keeps the client in their comfort zone during that search. It is quick and simple. There are several software applications that can generate and modify prototypes in real time.
[widget id=”custom_html-68″]
Evolutionary Development Waterfall
The only reason for using this is that it keeps the development team in their comfort zone. Project teams that have a long history of using the Waterfall Model will often choose this as their first step towards an agile environment. Unfortunately that is probably the only reason for using it when the situation calls for an agile model. It is very inefficient and wasteful of resources and time.
Scrum
The agile project world is dominated by Scrum [Schwaber and Beedle, 2001]. It is a sound model that keeps the client in charge through the Product Owner. That is, if you have a properly skilled Product Owner. Of all the common development models Scrum is a customer-driven model. Scrum does not have a project manager but the role is subsumed primarily by the team of senior developers, which operates as a self-managed and self-directed team. Co-location of the team is a critical component. Scrum teams tend to be small (less than 10 members). The temptation is to equate Agile to Scrum. There are many agile models of which Scrum is the most popular but the complex project landscape is broad and deep and can validly support a much richer portfolio than just Scrum.
Dynamic Systems Development Method (DSDM)
This model is popular in the EU [Stapleton, 2003]. At any point during implementation it allows the team to return to any previous stage in the design, development and deployment of the solution. DSDM is what the Waterfall Model would look like in a zero gravity world.
Effective Complex Project Management (ECPM) Framework
This is the new kid on the block [Wysocki, 2014] and [Wysocki, 2016]. It isn’t a model in the sense of the above. Rather it is a framework (Figure 2) that embraces a portfolio of models and a decision process for choosing and adapting the best fit model from the portfolio.
Figure 2: The ECPM Framework
It can be used for any agile project but is most useful when so little is known about the goal and/or solution that choosing and adapting the best fit model is not much more than a coin toss. it offers a decision model to help in that choice. The major advantage of using the ECPM Framework is that is designed to include the meaningful involvement of the client. ECPM is also a significant step towards establishing a collaborative project environment. Scrum includes that involvement through the Product Owner. The other models do not have meaningful client involvement as a design feature.
PUTTING IT ALL TOGETHER
All of these models and others should be included in the organization’s portfolio and the best fit one chosen based on the project’s characteristics, the organizational environment and culture in which the project will be executed and the market conditions the prevail. The specific types of projects the organization encounters might suggest that other models be included as well as customized models the organization has developed for repeatable projects. Choosing the best fit model is a multi-criteria decision. Preferences and availabilities have a lot to do with the choice. For example, Scrum requires more senior level developers because the projects are self-managed and self-directed. In the absence of senior level developers Scrum would not be a good choice.
[Schwaber and Beedle, 2001] Schwaber, Ken and Mike Beedle, 2001. Agile Software Development with Scrum, Pearson.
[Stapleton, 2003] Stapleton, Jennifer, ed., 2003. DSDM: Business Focused Development, 2nd Edition, Pearson Education
[Wysocki, 2013] Wysocki, Robert K., 2013. Effective Project Management: Traditional, Agile, Extreme. 7th Edition, John Wiley & Sons.
[Wysocki, 2014] Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing
[Wysocki, 2016] Wysocki, Robert K. and Colin Bentley, 2016. Global Complex Project Management: An Integrated Adaptive Agile and PRINCE2 LEAN Framework for Achieving Success, J. Ross Publishing