plans are worthless, but planning is everything

Capacity based planning, now this a topic I love the most when it comes down to being Agile.

Peace-time plans are of no particular value, but peace-time planning is indispensable. - Dwight D. Eisenhower

Practically saying that Plans are worthless, but planning is everything. This is a sentence I truly believe in. I’ve been working in a couple of companies until now to see that there is no way to lock down a Sprint Scope for 2 weeks or more. But there is, tough, value in planning it, in one form or another. There was always something important happening and coming to the team, which should be welcomed. In the end being Agile means working with a process that should foster empiricism. Change.

But let’s see what I am talking about in here. First, you start by spending 4 to 8 hours in a meeting with the expectation that the team defines to the point what needs to be done in the next 2 to 4 weeks. The artefact that results out of planning session is a Sprint Backlog, with all the tasks that needs to be completed. Coming next day, the team starts getting busy, new knowledge descends from the heavens above, and you soon after find out that your Plan needs adaptations. Now question yourself if all that effort was really worth it. It is hard to work in the unknown, that’s true, but if we embrace more of this and give up more of the control we so much desire, we might just find a better way. Look at the team as a whole, at what are they able to deliver together and understand the trends they are embarking on. Work needed to be done will change always. Instead keep your team stable and ready for action, avoid disturbing their focus with unnecessary activities.

Product development should be a continuous planning and re-prioritisation activity. You need to adapt, to pivot, based on the new learnings. So why would you limit your focus to just a fraction of what needs to be achieved?

Generally when a team gets a goal, and here I mean a goal that truly matters, it is not expected to be delivered in 2-4 weeks, is it? Rather it takes some months to achieve the goal for your Product to be successful. It was always challenging for me and the teams I was part of, to really keep track of that end goal, when we needed to always try to hit that Velocity, sprint after sprint. Velocity was always a thing on our minds and in our conversations, how can we meet ends. Once you discuss too much about Velocity, you create out of this metric a target, something to be aspired to, something to be achieved. This is just derailing your attention from what really matters, delivering joy to your users. You know, see the forest for the trees.

Capacity based planning was just another stress factor for the teams. You practically create mini-deadlines along your development, that do not bring the return you would expect out of it. The focus will be on delivering those promised SPs and little focus on the actual value for your users. In order to hit the SPs and to avoid yet another dreading retro where you are asked “why?”, you start making shortcuts, to meet that Velocity. There will always be a reason for which you did not hit the Velocity. These shortcuts are generally extremely costly for your product and your bottomline as a company. At first you may not realise it, but if you spend more than 6 months in development, you will start to noticing that you will get slower and slower at delivering value.

Furthermore, you create the expectation that the Product Owner must define to the letter what a team should do, in the form of a user story. The practice says that you should let the how to the team, Scrum guide changed lately a little bit around this topic, but still. I would rather say that if you really want to build what your users need next, you need to involve the whole team into the what and why as well. Give them the insights they need to be great. Utilise the creativity of the people you hired, do not transform them into line workers. Focus your team on the end goal and ask them how you, together, can achieve that. Remove the self-induced pressure that comes from making deadlines sprint by sprint, in the end it will all level up, of that I am most certain, you will see.

This is why, I am a big fan of Scrumban, a slightly adapted version of it. Practically you start with a goal that you want to achieve for your product. You put a team on the course of achieving it, and you get out of their way. Once you have your goal set, make out of prioritisation and refinement a focus, rather than spending too much time in building master plans. Make the two, a continuous activity, focus your team on your end goal and the progress towards that. In order to see your progress introduce a cadence of inspect and adapt, by having regular reviews and retrospectives. To be able to predict a future possible date of delivery, combine all this with time effectiveness and focus on reducing waste. Last, but not least just deliver the things when they are ready.

For me this is an environment where the focus is put on the right things. On achieving valuable goals, on learning, on adapting, where the stress and pressure is a positive factor for the team and the people part of it. Because it will come from the desire of helping out your users. In the end this is what you want isn’t it? To change a piece of this whole world, which is a noble and admirable mission, so just do that and nothing else.