Context is king
I know the common phrase is “content is king”, but as far as Agile is concerned it’s context that is key.
When a team starts a new initiative, it’s important that they understand who it is for, why it is important, what value is it expected to provide, what problem(s) will it solve, etc. Without this context, the team can’t be expected to know if they are building the right thing – all they can do is follow the Product Owner’s direction.
As much as we look to the PO to represent the stakeholders’ needs, the development team need to understand the bigger picture: how does this feature fit into the product? With a wider context, the team can think about a general technical direction, bearing in mind things will change and the project might end before finishing the whole thing (hopefully because the customers are happy rather than running out of time/money).
The team can also identify risks, dependencies and unknowns – not all of them, of course, because there will always be discoveries as they dig deeper. They can create spikes, run experiments, build a proof of concept, and/or change the prioritisation of the backlog in order to reduce those concerns. This is a big difference from my experience of waterfall projects where the project manager would fill in the risk assessment sheet and file it away.
Tackling the high-risk issues early can improve the confidence in the rest of the backlog, or (in at least one project I can recall) result in the project being canned because it would be too expensive to resolve a showstopper… and this is a good thing! It’s far better than we identified the risk and investigated our options, so that the PO could make an informed decision whether to proceed. The alternative is to plough time and effort into the project and only think about the problem when we couldn’t ignore it any longer – that would have been a huge waste.
So how do we help the teams gain the context they need? I find Jeff Patton’s Story Mapping incredibly useful – the template I use is slightly different to Jeff’s because I really want the initial conversation to focus on the who and why pieces. The “Frame the problem” section is important in Jeff’s approach too, but I find the addition of specific sections in the template reminds the team (and the facilitator!) that we need to spend time really discussing and understanding this context.
I find teams often want to jump to the details, the minutiae, the weeds – junior developers tend to be detail-oriented, so it’s important to repeatedly bring them back to the bigger picture. An experienced software engineer knows that the technical details are important but so are other things: are we building the right thing (e.g. does it address the problem? does it provide value?) as well as are we building it right (e.g. is our testing strategy solid? is our architecture evolving?).
Context is important throughout: in Refinement and Planning, we should set goals that move us towards the initiative’s objective; during the sprint, keeping the context in mind helps ensure we build what’s needed, not necessarily something because that’s what’s written in a user story; and then the Sprint Review should use the initiative’s context as the frame for understanding progress and any impact on the product backlog. Refer to it early & often. If we were in a team room, big posters of business and technical context FTW! (Jim Benson did a great presentation on this in the Agile Virtual Summit recently, but I’ll come back to this in another post.)
https://paulhenman.medium.com/context-is-king-f1137df95f4f