Over-commitment

When I wrote the “Long time, no see” post in December I was planning to resume writing regularly (at least bi-weekly) but since then I’ve only managed one. I thought I would have some spare time that could be put towards it but other things got in the way.

Does that sound familiar? How many teams start a sprint having planned to complete a number of things, only for that plan to go awry? If your team hasn’t experienced it yet, then it’s just a matter of time before you do… or maybe you’re playing it safe and you have a second planning session mid-sprint.

I’m not saying this is a bad thing – stuff happens and not adapting would be worse. Sticking blindly to a plan and ignoring reality sounds ridiculous and yet many organisations still do precisely this.

So how can we reduce the chances of our plans being impacted? Plan smaller steps; discuss risks and dependencies as part of planning; understand your capacity; and say “no”, or at least “not right now”.

Plan smaller steps

If you plan once a year (e.g. an annual budget cycle) then try moving to quarterly planning. If you create quarterly roadmaps that describe what needs to be delivered, then break it down into smaller feedback loops. If you’re a scrum team that plans four-week sprints but finds yourself replanning during sprints, then try two-week sprints. Whatever your cadence, if your plans often need updating then try a shorter timeline. It’s also possible that your plans are too detailed or rigid; there needs to be room to adapt based on learning, discovery and feedback. This is also why there are multiple “planning layers” – the team meet (at least) once a day to coordinate their efforts, share new insights, identify obstacles and make adjustments as needed. The shorter these feedback loops are, the sooner the team can respond.

Discuss risks and dependencies as part of planning

Sprint planning isn’t simply for the team to decide what “fits” – there should be (or have been in preparation for planning) discussions about the risks, assumptions, issues and dependencies. The somewhat-controversial Definition Of Ready is a good place to keep a list of reminders of the types of things to consider, e.g. if it takes a while to get access to a particular system, then make sure the team knows to start that process ASAP (in extreme cases, it may mean postponing a story until the access is granted). What else might throw the plan off course? It’s not possible to predict and anticipate everything but the team should learn from past “gotchas” and try to avoid repetition.

Understand your capacity

Even if everything goes smoothly, there’s no point in planning for more than could be realistically achieved. If a team uses story points consistently, then they probably have a good guide as to their capacity. Even without putting a number on it, stable teams should have a good feel for what is possible. The trouble with both those approaches is that teams can believe (or be cajoled into believing) that they can do more “just this once”. Forecasting (e.g. using cycle time) is based on the reality of historic data and is less open to “interpretation” or wishful thinking.

Say “no”, or at least “not right now”

The previous steps can help improve the likelihood of success, but one other defining factor is whether the team feels they can say “no” to taking “just one more thing”. If they feel they have to say yes to everything then there is no true commitment. (I know commitment is a controversial term; I’m using it as a shorthand for what the team tell those outside the team what they believe is achievable.)

In short: don’t make promises, because things change. Small steps with frequent feedback let your customer/sponsor see progress (which should lead to increased confidence) and collectively you can make adjustments based on new information.

I’m not committing (out loud or even just in my head) to updating this blog every two weeks, but I will try to write when I have time and have something to say. 🙂

Start With The End In Mind

We have completed another lap around the sun, and that’s often a time to think about our plans for the new year. In my previous post, I talked about New Year’s Resolutions and thinking in smaller steps rather than a goal that might take 12 months to complete. But if you only think in small steps and focus on where you want to be in a few days or weeks, then it’s often hard to know if you’re going in the right direction – there can be such a big gap between where you are and where you want to be.

If you were planning on travelling from Toronto to Montreal then you need to plan further ahead than just “which street do I take now?” You might think that was a bad example as the 401 covers the vast majority of the distance, but that assumes you’re optimising for time and that your method of travel is by road, i.e. you have already ruled out many alternatives. Take a step back and consider your goals: if minimising travel time is the primary aim, then flying is significantly faster. If you want the freedom to move around and have a meal without it impacting your travel time, then the train could be your best option.

But let’s go back to driving between the two cities, and assume we have picked the route we would like to take. We set off but before long we discover there’s a problem ahead: an accident is causing a long delay. If we had only been inspecting our progress over small steps, then we might not see the impact of the accident until we’re sitting in the traffic jam and it’s too late to do anything else. We would see a similar outcome if we set the route and followed it regardless of what we discovered along the way. One of the reasons we chose to drive is to have flexibility – we can’t easily change our route if we chose to fly or take the train.

Choosing flexibility (aka agility) may not be the cheapest, fastest or most comfortable path, but it gives us options when new information (whether that’s delays or shortcuts) is available … so we should ensure that we take advantage of that discovery, otherwise we probably shouldn’t have picked this approach!

The plans we create should provide clarity on where we want to be in the future (and why!) but we also should revise them when we see a better alternative. Sometimes it’s a detour that still gets us to our destination but in a better (faster / cheaper / safer) way, but sometimes the discovery is that our goal needs to change – maybe the reason we were heading to Montreal can also be achieved in Ottawa, saving about an hour of driving. If we don’t respond to that new information, then why didn’t we just get on the train, put our feet up, and just enjoy being passengers?

Incidentally, this is why we call some plans “roadmaps” – their purpose is to show potential alternative routes and to allow for changing course while still heading towards the destination. If our plan has only one path from A to B, then it’s not a roadmap. If the plan says “build X” rather than “solve problem Y”, then it’s not a roadmap.

I’m not saying you always have to drive (i.e. use an agile approach) – there are times when the train makes sense, for example when I travel to Montreal for a concert I know the destination isn’t going to change and I would rather get there with minimal stress. In the same way, if we know exactly what we need to build and don’t expect any changes along the way, then we could create a plan, write detailed specifications, and do all the design upfront … but, in our industry, how often can we go from A to B with no learning, no discoveries, no need to adapt?

So: start with the end in mind (understand where you want to go and why); consider what your constraints are (e.g. time) and how you expect to react to new information (do you want to accommodate discoveries or follow the plan); then choose your vehicle and route accordingly.

*Yes, I know the second habit that Stephen Covey describes in “The 7 Habits of Highly Effective People” is “Begin…” but he has a registered trademark for that phrase so I’m avoiding it, and anyway I’m not using the phrase in the way he does.

New Year’s Resolutions

I’m sure most people will be happy to see the end of 2021 but also trying not to build up too much expectation for 2022. There won’t be a sudden end to COVID – it’s going to take a continued effort from everyone. It won’t go away just because we’re all tired of dealing with it. Stay strong; hang in there; support each other; and keep safe, please.

The New Year is a time when many people set Resolutions – things they want to improve, e.g. eating better, getting more exercise. It’s a handy reminder to review how happy we are with various things, but is doing it once a year really enough? It often leads to huge goals because it’s going to be so long until the new review… and, of course, huge goals aren’t usually achievable. That’s why most resolutions are abandoned within a few weeks. It probably helps to have a vision of how you would like things to be in a few months (even a year), but set smaller goals – what are the steps that you think will take you towards that vision?

Hopefully that sounds familiar: regular retrospection, identifying where you want to improve, deciding on small steps to go in that direction; take a step, then go back to retrospection, rinse and repeat.

Engineers and product owners should be well practised in this – retrospectives to look at how we work, and experiments to probe what to build. So how do we convince HR that annual appraisals should be replaced with frequent feedback, and Finance that regular (e.g. monthly) planning trumps attempting to predict six or even twelve months ahead? That’s a challenge I’d like to add to my backlog for next year. Suggestions are welcome!

p.s.
2014: Didn’t jog
2015: Didn’t jog
2016: Didn’t jog
2017: Didn’t jog
2018: Didn’t jog
2019: Didn’t jog
2020: Didn’t jog
2021: Still haven’t jogged
This is a running joke! 🙂

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.)