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

Happy Birthday Agile

It’s twenty years since the Agile Manifesto was created in Snowbird, Utah. There’s obviously been lots of people posting about whether it’s still relevant, whether it should be revised, and so on, but I think it’s still important and applicable.

It starts with: “We are uncovering better ways of developing software by doing it and helping others do it.
It doesn’t claim to be definitive; “We are uncovering” means we still have room to learn and improve how we do this. There are many “flavours” of agile, including Heart of Agile and Modern Agile, and some organisations develop their own take on agile (but “hybrid” agile-waterfall monstrosities don’t count in my book).

The next few lines (i.e. the rest of the manifesto) seem to be problematic for some people because they don’t fully understand “we value the items on the left more” – the manifesto’s authors even spell it out by saying “while there is value in the items on the right” and yet some people still think “Agile means we don’t do documentation”.

The first of these, “we have come to value: Individuals and interactions over processes and tools” is one I’ve see many organisations fail to grasp. It’s a long-running joke in the community that “installing Jira” equals “adopting agile”. I’ll refrain from ranting about Jira because the point is that any tool is not the way to become agile – it’s about people. I remember another coach saying “If a company doesn’t understand that it’s all about people then they don’t deserve agile”! 🙂

The next line, “we have come to value: Working software over comprehensive documentation“, is the one I see people misunderstand most – I wonder if that’s because so many people hate writing documentation? If you think about the two extremes, neither is ideal: documentation without software is clearly not a useful product, but also software with no documentation is rarely desirable (a simple tool with no user interaction might just about be ok, but even then anyone trying to fix/enhance the code is likely to benefit from some docs). That’s why we value working software more than documentation but not instead of.

I think the third line is easier to appreciate if you’ve ever worked on a waterfall project where we’re expected to blindly follow the documented specifications and hit deadlines, even if it means delivering something we know to be wrong. By valuing “Customer collaboration over contract negotiation” it means we would rather work with our customer, e.g. show them demos (or better yet give them something they can use) and get feedback early and often. If you don’t work with your customer and respect them, then how can you expect to keep them as a customer? (Ignoring monopolies/cartels, obviously; add banks to the list of rants I’m avoiding in this post!)

The final line, “Responding to change over following a plan” is closely linked with the previous one – in an ever-changing environment like software development there is always going to be change, whether that’s feedback from the customer “course-correcting” the direction of the product, or how the team works together (e.g. coming out of a retrospective), or the tools/technology that we’re working with. To ignore those changes is to say that we can’t learn anything during a project; I can’t think of a single instance where that’s been true, even working on tightly constrained legislation/standards-based projects – there’s always something discovered along the way. However, just like documentation, that doesn’t mean we work without plans – we need to understand where we’re heading and how we think we can get there… but we also need to revise the plan when things change. We need a roadmap (i.e. a destination and options for getting there) rather than a single route set in stone … but that feels like a future post 🙂