We love agile software delivery, so why don’t we always use it?
At this point in my agile journey I’d describe myself as an agile pragmatist. I encourage our teams to practice an agile mindset and refer back to the agile tenets and principles, to incrementally and pragmatically find ways to improve what we are doing with an overall focus on how to best deliver value.
Focusing on delivering value (above almost all else) means we adapt our toolbox for each client we work with and each project we work on. As a result, our version of agile is well… agile. Agile purists may not love all of our methods but would surely agree that consistently delivering working software is a solid way for a software company to measure success. We’ve delivered something like 1,500 projects over 17 years now and we haven’t yet delivered something I would consider a failure. That is a track record I am immensely proud of and aspire to sustain.
When I talk with clients about how we might approach their problem and deliver their project, I tend to break it down into two, contrasting models which have quite different risk controls.
- A known budget with a fixed scope; or
- A known budget with a flexible scope.
In both cases we start from a known budget as I’m yet to have a client turn up with a totally blank cheque. Ultimately, the choice ends up being how we approach scope and where change fits within the project. The fixed or flexible scope mindset has massive implications for how a project unfolds. One of the interesting implications is around is how financial risk is perceived and controlled between the two models.
The Fixed Scope View
In order to arrive at a well-understood fixed scope, you need to do a huge amount of upfront design and planning. This is fine (and often it’s even better) for short projects or quite simple problems, where scale makes it possible, or even more efficient, to scope everything in one go. It can also work well when a client is not resourced to provide a strong “product owner” to the joint development team. Doing lots of upfront planning is often appealing for stakeholders who carry any personal/professional risk on the project but are not involved in the detail or planning. The artifacts created during the planning process gives them something tangible to hang their hat on.
Where it typically falls down is in larger or more complex projects, where you might need to spend many months (or even years) in the planning phase.
Front loading the planning can make the overall project life cycle (time to deliver) longer than an agile project where planning is more intertwined with development. Additionally, upfront planning on fixed scope projects can end up with a significant separation between the requirements gathering and delivery phases. That gap can be a risk to delivering the right thing – because requirements (and people) often change over time.
On top of that, our understanding of the client’s problem-domain deepens during delivery and even continues after the software has been delivered. Experience has shown us that some of the best ideas probably won’t land till pretty late in the piece. You run the very real risk of being unable to incorporate those into the project or needing to find additional budget at the tail end. Equally, things you once assumed were really important may feel less important as the project progresses. A well-known phrase sums this up pretty well. “The start of a project is the point of maximum ignorance”. With this in mind, making all your decisions upfront at the start of a project could be considered high risk.
While a fixed budget and fixed scope will deliver you something at a known price, if the solution doesn’t actually solve your problem then it may as well be considered a bad price.
My own internal rule of thumb, is that a project with a development duration of more than 3 months should start to see the benefits from an agile, flexible-scope mindset. Less than 3 months, and you should certainly consider whether it is possible, or desirable, to scope it all upfront and find the most efficient and low risk way to deliver that scope.
The Flexible Scope View
This is Agile’s happy place. We do sufficient planning to identify the most critical requirements of the solution and enough work to determine a responsible budget. The focus is then on delivering working software early in the project life cycle so that we can get feedback from users and prove that we are, in fact, solving the problems we have been tasked with solving.
Much of our toolbox has been heavily influenced by some of the agile subcultures such as Lean Development, DevOps and User-centered design. You’ll hear us talking about minimum viable product (MVP) a lot. That means we ask the team to stay focused on the minimum amount of work required to solve the problem. I know clients can initially find it frustrating when we pare back their ideas or remove the polish from their project, but ultimately, focusing on MVP is an important aspect of our agile practise because it forces prioritisation. In order to prioritise you need to be clear about the problems you are trying to solve. Being clear about a problem requires you to understand the problem deeply. I believe you can only come up with the right solution once you have grasped a deep understanding of the problem from multiple perspectives.
For us, MVP is a tool we use to peel away the layers of requirements and get down to the important business of solving the core problems. By attacking the biggest problems first we reduce the project risk early, and when there is still runway to accommodate change if we need to. With a responsible budget there should absolutely be room to come back and polish things ahead of a first release. So worry not, the polish is coming, it just doesn’t always make sense for that to be the first thing we do.
Agile helps us to reduce risk in a project early by quickly getting us deep into the domain, so we can help you to come up with better solutions. Ultimately, it gives us the ability to change course if required and it gives project teams a sense of empowerment – building software that tackles real problems feels meaningful.
Under an agile model you might not know exactly what you are building upfront (which can be challenging for clients to stomach) but if you can trust in your team, you will get working software at a known price – which is more likely to solve the right problems.
Where Does Planning and Analysis Fit Within These Models?
We do the majority of our work for public sector clients. It is pretty common for our clients to do a lot of analysis work up front to define requirements before putting a project out to tender. Analysts are often hired on contract to do the first planning phase and are frequently unavailable to us during the delivery phases. This can leave projects with a significant disconnect in both time and personnel, between the requirements gathering and delivery phases. When delivery and planning work streams are disconnected, the delivery team can be left with only a superficial understanding of why they are doing something. Closing the gap between the analysis, planning, user interviews, design sessions and decision making that led to the requirements, and then delivering on those requirements, leads to better outcomes. Good ideas and obvious efficiencies are easily lost when operating with a fixed scope mindset.
Agile looks to solve this problem by getting the development team as close as possible to the problem domain, requirements gathering and planning phases as possible. In this way, the development team are able to make (or help the client to make) informed trade offs and suggest alternative solutions to problems. Some of our very favourite solutions haven’t required writing any code.
One aspect of effective agile delivery, which I don’t think gets enough airtime, is that the development team can actually do meaningful analysis and planning work. This absolutely does not mean that we cut out business analysts, simply that they are a critical part of the development team rather than working in isolation ahead of delivery. You will often see BAs within our delivery teams. It’s likely that you’ll hear them being called Product Owners, User Experience Designers or Solution Architects – all of which use analytical skills within their specialty.
Agile Is Not…
Agile is not a silver bullet. Agile delivery alone will not make your project a success. Agile is not a way to avoid planning and analysis, an excuse to defer decision making or a way to make up for lost time.
Any successful project will likely to come down to having a highly engaged and motivated team working rigorously and with focus. If you have that team, then an agile delivery of a flexible scope could give your team a sense of ownership and responsibility that stands to make your project even better than you expected.
Banner image: Photo by Kammeran Gonzalez-Keola
