In this instalment of our #Zone5Principles blog series, Zone’s head of engineering, Paul Kiernan, discusses how to best manage changing scope when delivering digital products and services to market quickly.
Continuously managing scope is arguably one of the most important parts of delivering a product/service into market quickly and often one of the hardest to do. If you’ve managed to lay out and create a really great lean MVP, one that’s set up to get your product into the market quickly and with the right level of quality, the last thing you want is to have that hard work dashed due to scope bloat throughout the project.
The following are some key practices that, if done well, will help the team to enable change but also restrict bloat, ultimately delivering high-quality, at speed and returning the maximum value.
- Measure your delivery to support scope change decisions
- Iteratively discover and refine features
- Constantly and transparently communicate
Before we get into it, it’s worth discussing the two different ways to manage scope. The first is to limit and restrict change — this approach generally means that you lock what you’ll deliver after agreeing on the MVP scope. This might sound attractive at first, but “locking” makes people feel like they need to put extra effort into up-front analysis to be super confident they have covered every last requirement that needs to be delivered. Which normally means a long discovery period impacting your speed of delivery. I also feel locking scope creates a culture that fears change, and if there’s one thing we know will happen in product delivery, it’s change.
Instead, embracing change will help the product owner (PO) continuously make informed decisions on what should be included in the MVP to hit the agreed objectives within the right timeline. Embracing change will also allow the team to react and respond based on new information or unknowns in the system.
It’s sometimes the case that once a team has partially built their product, requirements are actually made easier to deliver, normally because they’ve had x weeks to learn more about how they are building the product, but also there are a lot fewer unknowns.
If you’re working in a client/supplier relationship, allowing some degree of change works for both sides of the relationship, but to make that work the relationship requires trust. The client needs to trust that their supplier isn’t going to take them for a ride and the supplier needs to trust that the client will support the team with hard decisions when required.
The creation (or not) of this high-trust relationship can make or break a good MVP delivery. I’ve seen this go badly but I’ve also seen it work incredibly well. We’ll go deeper into creating great relationships in a future article on creating a culture of speed.
So if we need to allow change, and agile is all about embracing change, then why do projects still go wrong… In reality, it’s all about balance, you don’t want to totally lock what you’re going to deliver, but you also don’t want everything to change all the time. You need to balance having a core set of functionality that you agree to deliver for the MVP to produce value (use measurement frameworks to determine value), but have enough flexibility to pivot or persist when you have to. This balance is often what I’ve seen teams do wrong.
Measure your delivery
Measurement… Often talked about but also often missed and arguably the most important underlying method for managing scope change throughout a project. When I say measurement I don’t mean measuring the value the team is delivering (although this is very important), I mean measuring the velocity of the team.
Measurement helps in multiple ways, it allows …
- The team to make informed decisions if a feature can be in/out of scope or when to build a “quick and dirty solution”.
- The team leads and PO to have objective discussions on how much scope can be delivered in the timeline. Being crystal clear on your business goals and measures of success are also really important here, they will help have effective conversations on scope.
- The team to diagnose where their bottlenecks are and make optimisations.
In an agile environment, measurement is often manifested in two ways. In SCRUM as burn downs/ups and in Kanban as throughput. I’ve seen both work well and at this point in time, I think the best option is whatever works for the team. Whichever is chosen, having a single Kanban board the team uses to visualise the stages of feature development will enable more granular measurement and surface blockers quicker.
Long-term projections
Often missed in reporting is the long-term view. To create a long view, you work out the team’s current throughput (velocity) and use that to project when the current agreed scope will be completed by. Obviously, to do that you need to know the size of the scope in your backlog.
In SCRUM you’ll need to roughly estimate the backlog, in Kanban we often T-shirt size the items to understand relative sizes (for use later) but treat each feature as 1pt. Then, simple algorithms like Little’s Law can be used to work out lead-time and throughout. The result is a projection of our finished date. Comparing the team’s projection to the ideal throughput will let you know if the team is on or off target and by how much.
At the start of the project, the projections are often off, however, over time the projections will start to realign and hopefully move closer to the required ideal.
Key: Red = Ideal throughput, Blue = Test Complete, Green = Done
Creating charts like the above help visualise progress for stakeholders and just as importantly, the team, creating a high-level of transparency and trust. Showing the team these projections is essential for a team to be empowered and make informed decisions on when to go quick and dirty and when to take longer.
When talking to stakeholders about these graphs it’s important to layer on the qualitative feedback from the team. Sometimes the report can paint a picture of doom and gloom but in reality, the team are setting themselves up to rapidly accelerate in the future, or conversely, the team are well on track but they have some really big unknown features about to hit. Data isn’t everything and human opinion needs to augment it.
Short-term goals
Longer-term projections are great for the big picture but it can be hard for a team to relate to a long-term goal on a 3+ month project, it’s also hard to aim for something so far in the future. To help give the team a focus we must create short-term goals, in SCRUM these are often short sprint goals, in Kanban we’ve often created short iteration goals.
These smaller goals need to ladder up to the overall MVP and be something small and achievable the team can pull towards. Ideally, these goals will be “product slices” (discussed in the previous article on creating a true MVP) so that each time the team achieves their goal, they have delivered a new working coherent feature set of the product. If these slices are too big, break them down into smaller goals.
Measuring the team’s progress towards these goals will help focus effort in the short term.
Finding the root causes
Setting up long-term projections and short-term goals are great at measuring progress and focusing the team. In reality, what can sometimes happen is that these methods highlight that the team is not on track to hit the deadline… So how do you fix that? Do you pretend it will be fine? Do you ask the team to work weekends? Or do you try to help the team become more efficient and faster? If you want a happy team it’s best to pick the last option, you then need to work out what needs to be optimised and how to optimise it.
It’s important to say that measurements are great at highlighting inefficiencies and supporting discussions with stakeholders. However, the best way to really understand how to help the team move faster is to talk to the team. Retros and focused workshops to break bottlenecks will always be the best way to move quickly and keep the team engaged at solving problems.
Bottlenecks and drag come in many different forms — maybe requirements aren’t being written correctly which is causing rework of code, maybe deployments take ages which sucks up the dev team’s time, maybe the understanding of features is taking longer than expected and that’s due to stakeholder availability… You need to identify the biggest bottlenecks in the system and the root cause of those bottlenecks.
When it’s hard for the team to take a step back and separate symptoms from root causes, techniques such as “Theory of Constraints” (ToC) and root cause analysis (“The five whys”) can help identify and fix bottlenecks. I won’t discuss these concepts here, a simple Google will give endless resources on the subjects.
ToC in particular is based on understanding stages in a process and this is where the Kanban board helps. You can measure the throughput and cycle time of each stage in the Kanban board (e.g. understanding, design, development, test, done) to understand which stage is taking the longest. It’s also possible to implement card ageing (measure the time a card has spent in a stage) to find out if it’s just a couple of features that are holding up the team, or if all features are affected.
If helpful, key Kanban stages can be modelled as distinct lines on the projections graph (as can be seen in our example above with different coloured lines) to help stakeholders understand where the delays are and how they can support the team to move faster. For example, if the requirements sign-off stage is taking a long time, this can be modelled in the projections and directly related to the team’s ability to hit a deadline.
Measure waste and don’t hide it
What happens when the team has been working on a feature and it has taken a considerable amount of time, but for whatever reason, the feature is thrown out before it’s completed?
Waste can occur if stakeholders change their minds, or for some reason, the feature is deemed no longer viable. If the team has spent considerable effort on the feature, it’s important to reflect that effort in reporting, to maintain an accurate view of throughput (velocity) and acknowledge the amount of work the team is performing. Often the time spent on these features can be simply recorded as ‘done’ although they are never finished and included in the final product.
Key takeaway… Presenting measurement-based information to stakeholders can help them understand and support you in fixing the bottlenecks, this is particularly important when the bottlenecks are caused by factors external to the team (which is often the case).
Iteratively discover and refine features
If the team has done a good job of creating a true MVP, they will have a lean set of features to build. These features will hopefully have assumptions and any lean solution hypotheses attached. However, they won’t have detailed requirements and as is often the case, the devil is in the detail with scope.
As part of any iterative methodology, we build up our understanding of what a feature is as it moves through the development process. At the start of the process, we might have high-level notes and when it hits the development phases it should have whatever is required to build and test the feature e.g. acceptance criteria, designs, diagrams, copy etc.
Sometimes as we move through the process of ‘hydrating’ features there is a moment when the team thinks “Oh dear, this is bigger than we thought” — personally this has happened to me many times. I’ve learnt this is a natural part of iterative development and nine times out of 10 it’s not a problem as long as the right process is followed.
Like when creating the MVP, the team needs to break apart features as/when they understand them. This is important for both SCRUM and Kanban: in SCRUM we want to maintain features with small points, in Kanban we want to maintain a constant relative size between features. Both approaches aim to maintain a good flow of work (value) through the team.
The following steps can help when features are bigger than expected:
- Break apart — Split the feature into its atomic sub-features, each part needs to deliver some value (business or user), but normally not all features are required to deliver value. Splitting the bigger feature into multiple smaller features will help the stakeholders and the team understand the complexity hidden within.
- Estimate — Have a go at sizing the new features, if they are still too big break them apart more.
- Descope — Interrogate the newly created features — are they all required for a true MVP? Often they aren’t, and some can be classified as ‘nice to haves’ or moved into the backlog. If it’s hard to descope, agree and record, then create low-effort solutions for features that need to stay in scope.
- Update projections based on current data — Plug the newly expanded feature estimates into the projections discussed earlier and see what impact there is on the deadline. Do you need to extend the deadline? Do you need to descope other features? Do you need to add more people to the team?
As with everything, there is a balance you need to keep when breaking down features. Don’t go wild breaking features into hundreds of smaller granular ones, also don’t split them by technology layer — a feature should slice across the stack to deliver value. If you split features up too much or in the wrong way, it will make them harder to manage in the long run and the overall process confusing. Try to keep features reasonably small (not tiny), atomic and deliver some user or business value. Practice and experience will guide you on what is right.
Constantly and transparently communicate
If you’ve implemented your measurements correctly, you’ll be optimising the team, identifying inefficiencies and breaking down features to help manage scope bloat. The next question is, do you do this internally and keep it within the team? Or do you open up transparent conversations with stakeholders or clients?
If you want to move quickly while maintaining quality and delivering an agreed amount of value you have to have transparent and open conversations with stakeholders. These conversations create a culture of speed, which will be discussed in a future article.
The key when reporting is to highlight the right level of information for stakeholders, answering the key questions like…
- Is the delivery on track (projects and reporting)?
- If not, why not (blockers and root causes, not symptoms)?
- What are the actions the team will take to bring it back on track, and what does the team need from the stakeholders (solutions)?
- Do stakeholders need to remove blockers?
- Are features more complex than thought, why is that and what parts of the features need to be descoped (feature refinement)?
Stakeholders don’t need to know about each little impediment or gripe the team has, they need to know clearly and succinctly the status and how they can support.
It’s worth expanding the final point above regarding descoping. The backlog should be constantly refined based on your measurements and based on the team’s new knowledge of the product. If you believe a feature is at risk of not making it into the product, have that conversation with stakeholders as soon as you’re aware.
Giving foresight to stakeholders will allow them to manage their own stakeholders, and put in workarounds or fallback plans in case the feature cannot be delivered. I’ve seen this done well on many projects and it’s always ended in positive results. Scope discussion can be hard for even seasoned professionals, but be brave and have the hard conversation early.
It’s also important to point out that we don’t only have early and often discussions to descope features or talk about impediments. When a team is working faster than expected, we can discuss features that were deemed as ‘nice to have’, so they can be brought into the scope for delivery.
As the delivery progresses we may also discover new features that are required for the MVP, stakeholders can make informed decisions on swapping out existing features for new features, or extending the final delivery date. If you have a good and reliable delivery measurement framework in place, you can use this to project the new delivery deadline based on the new features.
Whatever the discussions involve, they should be early and often — having a status meeting each week or every two weeks is fine. Having a regular meeting in the diary will mean delays/issues are addressed as they occur and don’t build up into big problems, avoiding the need for crisis style meetings.
From my experience, stakeholders love being involved in the process and it builds a high level of trust between them and the team. I’ve also seen this not happen and problems/delays hidden until the eleventh hour. More often than not this ends up with pushed timelines, compromises on product value or quality, broken trust and unhappy stakeholders.
Conclusions…
Managing scope is a continuous process that will never finish. If you do it well, the team has a high chance of delivering a great quality product into the market at speed, ultimately proving the market demand early and returning maximum value for investment. Done incorrectly, the product can be late, compromise on quality and ultimately not deliver to its full potential.
The team needs to…
- Measure your delivery to support scope change decisions
- Iteratively discover and refine features
- Constantly and transparently communicate
It’s worth saying, these aren’t the only things a team need to do to balance quality, speed and value, but if you get these right, you’ll be putting in a good delivery framework for the team to do their best work and succeed.
Notes:
This article is part of an overarching series aimed at people who develop digital products or services, either in-house or agency side, and have been frustrated by missed deadlines, poor output quality or the overall experience not delivering the value you hoped for.
The information discussed isn’t new or groundbreaking; however, it is generally talked about separately and in silo. These articles will provide a holistic and balanced view of the key focus areas to help teams move quickly while still delivering value.
It’s an iterative process to get all these practices and processes in place, so start small, experiment, persist with what works and take the learnings from what fails.
For a full introduction to the series please read the series introduction article.
Principle One: Look at the big picture, but don’t get lost in it
Principle Two: Create a true MVP (Part One)
Principle Two: Create a true MVP (Part Two)
