Agile Software Development means different things to different people, but have you ever asked yourself why you are trying do agile, or what are the implications of practicing agile?. Many never do, finding it instead easier to simply try to follow the tenets, or worse, simply advertise that "we do Agile". But if Agile is the magic bullet for software development, why is it that 80% of software projects are still over time, over budget, and not fully featured when delivered? [1. The CHAOS report, Standish Group]. Is it that a low number of projects are executed with agile methods, that agile is being employed incompletely or incorrectly, or indeed that there is no magic bullet for software project success? The answer to these questions is simply, “yes.”
Making matters worse, stakeholders exhibit role biases. For example, software development practitioners experience the benefits of a software method differently from the customers for whom the software is being built. This article explores these biases and aims to explain some high-level differences between methods by painting the Mona Lisa three times.
Agile Values, Principles, and Methods
Good backgrounders on individual practices and methods can be found online by searching for “Agile Software Development”, so I won't attempt to compare them here. However, It should be noted that an Agile “method” is different from an agile “principle” (and that principle’s related practices) and is further distinct from an Agile “value.” For your method to be both meaningful and successful, you must begin with what you value. Your values will then engender choices of principles and practices, which are composed and aggregated to form your “method” – there is no such thing as “the ultimate Agile method” - there are only specific compositions of principles and practices based on the values of the team and the choices made by it.
Furthermore, blind adherence to principles and practices without regard to values will eventually lead to rote, improper, and inconsistent application of the practices due to the lack of motivation; motivation that one might get from assigning meaning to them. And nobody wants that.
Choosing a software vendor shouldn't mean that you need to know much at all about Agile software methods (after all, this isn’t your area of expertise). However, the lack of standardization in software engineering does mean that you have to evaluate their value system to help predict mutual success. In another post, I talk a bit more about some questions you might ask to help drive this out.
The Manifesto for Agile Software Development
So we don't have a lot of standards, but what do we have? Agile methodologists and pundits have banded together to produce a statement of values and principles upon which they all generally agree - abstractions of what the various Agile methods have in common. Not surprisingly, these devolve to values and principles as opposed to specific practices and methods. They have collectively named this the The Manifesto for Agile Software Development.
The Jonah Group signed the manifesto in 2003, identifying heavily with the values within it (not everyone does). They are presented clearly, with common sense, and they resonate with our experience of what works on real world projects. Our practices continue to evolve over time according to what we find most useful, but our adherence to the values and principles remains intact.
Project Engagement Styles
Software project engagements can be thought of as existing on a continuum from “predictive” to “agile”. Agile styles are the most responsive to change, whereas predictive styles are best at answering what the price and timeframe will be, early on. Before choosing an engagement style, the client and vendor must sort out their role biases, which create distinct needs that are sometimes at odds. Not surprisingly, these needs generally center around sensitivity to the 4 main project management drivers: time, price, scope, and capacity. And herein lies the problem:
- Executive teams are generally most concerned with cost and time
- Business Teams are generally most concerned with time and scope
- Development teams are generally most concerned with scope and capacity
And no matter how hard you try, you can't maximize all of these at the same time. But reconciling the relative importance of these on your particular project will help you choose an appropriate engagement style.
As a vendor, you'll often have to help ensure that the various client stakeholders have taken a step at this reconciliation, and further have a meeting of the minds before you even get involved. Don't skip this step! Ask: what is the budget? when does it have to be delivered? What is the minimum amount that you can go live with? How long do we have to ramp up the team? Write up a charter describing all of this, and get everyone to sign off on it.
A number of activities are always in play in software and web development, regardless of the engagement style chosen. Everyone is familiar with these in one form or another, but Jonah uses the labels “Discover”, “Prioritize”, “Analyze”, “Design”, “Build”, “Test”, and “Deploy”.
After “Discover”, the remaining six activities in the Jonah Method can be repeated:
- Once for each project (“Waterfall”)
- Once for each iteration within a multi-iteration project (“Iterative”), or
- Once for each feature or story within a single or multi-iteration project (“Agile”)
These characterizations are somewhat artificial, given that the dividing lines can be somewhat fuzzy, and that “Agile” styles are also generally highly “Iterative”, but I'll use these terms to refer to the descriptions above.
As we will see, an "Agile" style suits projects in which there is a relatively low sensitivity to scope and price variability. A waterfall style suits projects in which there is a high sensitivity to scope and price variability, but it requires a very stable set of requirements.
The differences between these engagement styles can be demonstrated with Gantt charts, but these aren’t particularly evocative in explaining the concept. Instead, let's paint the Mona Lisa.
Waterfall methods organize the activities in sequential phases, with milestones and gates separating phases to help ensure that one phase doesn’t begin before the prior one ends. This makes it expensive to revisit earlier phases and make changes, but works well enough if change is kept to a minimum. I can hear you laughing, but… bear with me.
If Da Vinci was a waterfall specialist, the Mona Lisa might have been painted in layers - each representing one of the activities of the project - starting from the background and moving to the foreground. Da Vinci would have argued that we wouldn’t ever need to go back and remix any of the colours of the background as he painted them, and that if they were simply patient, the glory of Mona’s face, eyes, and smile would appear in a big reveal near the end of the project, which would occur on a precise date, with a precise effort and associated cost. He'd also tell you that apart from some conversations he’d need to have with you at the beginning of the project, and again at the end to hand over the painting, you could spend the intervening weeks focusing on your important work.
After those initial meetings, he’d begin painting.
A number of things should be noted here. Firstly, it’s clear, though that if the project were cancelled after phase 2, 3, or 4 due to budget reallocations, the painting wouldn’t be hanging in the Louvre today. Little value would have been realized for the client, who would be forced to declare that the project was a complete failure: without Mona’s face, there was simply no point. Also, a late request to change the background from sage to lavender would have raised Leonardo’s ire. Considering that the palette for the entire painting would now require an update, such a change in the late stages would be an expensive prospect indeed. But if he made it to phase 5, of course everything would be sweetness and light.
Due the dynamic nature of software projects, or other projects that require adaptability to change throughout their lifecycle, a Waterfall engagement style is generally no longer accepted as a prudent choice. Requirements change. Budgets are variable. Projects are always under pressure to ship before they’re complete, and are often in danger of being cancelled for reasons that have nothing to do with the delivery of the project.
However, waterfall might work for you if the following are true:
- There is a high sensitivity to both price and scope variability. These need to be known to support up-front decision making
- Requirements are very stable and not likely to change.
- The client is overextended with work, and is not available for very much consultation after the project is kicked off and they help you with discovery and analysis.
- The overall timeline for the project is relatively short (< 2-3 months) so that catastrophic failures are avoided if the project is cancelled for some reason, and also to help ensure there isn't a lot of time for requirements to change.
Waterfall methods are highly “predictive”. They will
- Predict the time and cost of a project with a high level of certainty, supporting up-front go / no go decision making by executive teams
- Realize no value for money spent if the project fails or is cancelled
- Usually prove unsatisfactory for business teams that use the development lifecycle to help drive out requirements, since course corrections are difficult and expensive.
- Best satisfy executive and management teams (until something goes wrong).
- Require the least interaction with the client after kickoff is completed, and as a result are at the highest risk of being implemented incorrectly unless the specifications are exact, which they almost never are.
To help address the shortcomings of the waterfall method, agile methods were developed. One of the first innovations was the concept of an “iteration” (sometimes called “sprints” as they tend toward shorter time frames). Iterations are scheduled sequentially, with individual features assigned to the each iteration according to “what’s next”, which is usually the result of either an ongoing prioritization exercise, or prototyping or exploration based on feedback on what has already been developed. Analysis, design, build, test, and deploy are still performed for each feature or story, but they are performed in a more organic, overlapping fashion as they are encountered by various members of the team. “Late stage” activities for feature X often overlap with “early stage” activities for feature “Y” within the same iteration. System integration occurs continuously to ensure an operational system at all times, and people often synchronize with each other daily in stand-up meetings.
If Da Vinci were an agilist, he may have painted the Mona Lisa as follows:
Entire fully-rendered features would be available on each pass. He may have discarded the need for a lot of up-front planning and estimation in favor of getting whole features up and running quickly. He would have known the head and face were of primary importance because the client had emphasized this in initial discussions, but may have discovered the neck, torso, arms, and background scenery as being important via continued organic exploration from the head down.
He wouldn’t have known at the start how long it would take, or how much it would cost, but as each successive iteration is completed, this information becomes clearer and clearer. He would also have had to have his full suite of colours available each morning when we woke up ready for the next sprint. As he discovered each new element in the painting, he would have solicited feedback from the commissioner (client) to determine how they wanted him to proceed. This may have been annoying for the client who would likely have thought “Yo Leo, I've got a job of my own, you know..." or “Which one of us is the painter, dude?” under her breath on more than one occasion.
Projects executed in an agile fashion are often completed more quickly and with lower overhead than they might have otherwise been, but require a lot more involvement of the client. They are also more responsive to change – a colour palette change at iteration 3 only affects half of the painting rather than the entire canvas.
All of this comes at the cost of not knowing how much time the whole project will take, or how much money will be spent when it’s finally completed. To respond to this added risk, agile processes generally employ short iterations in order to gain visibility into how much effort has been spent per unit of value, and to allow adjustments to be made at the end of each sprint.
Other characteristics of an agile engagement style are:
- Low overhead – long planning steps are rendered less necessary by the short iteration lengths, given the reduced requirement for planning, documentation, synchronization and signoff before proceeding to each new step.
- Most enjoyment for the delivery and business teams, but often unsatisfactory or painful for financial and management teams due to lack of visibility into eventual project financials. Can also be painful for business teams, as they don’t necessarily know when they will receive certain functions.
I like that Da Vinci fellow, but he never seems to answer my questions about how much it will cost me by the time it's completed.
- Operations staff are put to work in parallel with development staff, and are able to tune the environment long before it goes into production, shortening overall delivery time frames.
- The entire palette needs to be available at all times. Analysts, developers, designers, testers, and deployers. Don't expect that your BA will do some analysis and move on to other projects while the system is being built.
- Time and cost for the overall project is difficult to predict until it’s over, though if the project goes smoothly, overall efficiency will generally be higher than with waterfall.
- The business team sees value for money spent after only a single iteration, which may be as short as 2 weeks, but not more than 3 months.
- Project cancellations leave more residual value than with waterfalls – working software and complete features are left behind at all times.
The Jonah Group
The Jonah Group engages with clients all along the continuum of predictive to agile. Not surprisingly, the choice of an appropriate engagement style is a key success driver. To address the shortcomings of the waterfall process, iterations are almost always used. Importantly, prioritization exercises occur at the beginning of each iteration, to allow for course corrections. Depending on the team composition and availability of client resources, the prioritization, analysis, and design activities of one iteration can overlap the build, test, and deployment activities of the previous iteration. This helps reduce the overall timeline of the project.
Jonah is often asked to commit to fixed-price estimates and hard timelines before the project begins. The million dollar question is: how can these, then, be executed in an agile fashion?
The “Discover” activity of Jonah’s method is important here. In a situation in which time, cost, and scope predictability is proving difficult, Jonah will perform a short Discovery, during which a small portion of the project budget is spent on exploration of the entire problem domain, with emphasis placed on high-risk and high-value areas.
Through a series of workshops and meetings, we facilitate the definition of each feature's business priority, and approximate implementation difficulty and risk to the overall delivery schedule of the project. We will work with the project manager and delivery team to get high-level estimates of effort for feature delivery, and plan the activities at a high level to help estimate time and capacity requirements.
The end result is a high-level delivery plan with well-defined iterations, approximate milestone dates, and a list of prioritized features that will be implemented in each phase. The plan establishes a baseline which will deliver critical requirements in a predictable timeframe, and approximates delivery of the remainder. Additionally, a Charter document is produced which provides guidance as to how the project will proceed from iteration to iteration, who will be involved when, and how difficulties and exceptions will be handled.
The first version of the requirements specification is also a deliverable of Discovery, organized into a prioritized list of use cases, or wireframes, with 80% of the details in place for the functions assigned to the first iteration, and 10-20% of the details fleshed out for features assigned to future iterations. Note that not ALL of the details for ALL of the features are elaborated.
This document provides a framework for all further discussion of the system, including the goals for the system, the relative timeliness for delivery of various system functions, the actors (roles) that interact with the system, and of course descriptions of how this interaction occurs and how the system responds.
Requirements that are least likely to change usually address key business functions, i.e. ones that deliver the most business value. We use this fact in the assignment of business functions to iterations.
So what would the Mona Lisa project look like if Da Vinci worked at Jonah?
Leonardo would have insisted during Discovery that he draw some broad strokes to outline what he was about to do, get a sense of how long it would take and what it would cost. Feature choices wouldn’t necessarily need to be assigned to iterations in an exploratory manner (obviating the need for “what’s next” being overly linked to “what came before”), since a context for all features would already have been established.
Upon receiving signoff from Discovery, the high-value, and potentially high-risk features of Mona Lisa would be addressed in order, even if they weren’t directly related to one another within the confines of the iteration. The facial expression would be key. The blending of the paint in the folds of her garment in the arms would also be difficult to attempt with oil. These would be addressed first, and everyone would understand generally how these would eventually fit into the overall picture, because of the output of Discovery. If the Mona project was cancelled for whatever reason after iterations 2, 3, or 4, the most value would have been delivered for time spent, the most risk would have been mitigated, and most importantly, approximate budget for the entire project could have been validated before starting.
The Jonah Group’s choice of engagement style depends heavily on the needs of multiple different types of stakeholders, which are generally driven by the team composition and constraints imposed by the client. Remember that a single development method cannot effectively handle all kinds of projects, because of the distinct imprint that project’s goals and stakeholders imparts. We consider ourselves to be an agile shop, but we know how to tailor our development method activities and engagement styles according to an agile value system that integrates competing stakeholder needs.