Popular misunderstandings

There are several widespread misunderstandings about planning in agile environments. Let’s first look into some popular ones:

In agility, there is no planning required…

There should be a book written with the title “Epic misunderstandings of agility”. The same category of epic misunderstandings like “Agile people are faster because they do not document” is:

“We do not need to plan, we’re agile”.

The opposite is the case: in agility, people plan DAILY! And not only daily. And on different altitudes. Keep reading and you’ll see.

Fear of planning…

You may heard already sentences like

“We are not agile, we are just doing waterfall with sprints”

Such statements and following discussions – with very smart people involved – are indicating friction and – not yet – consequently applied agile practices. You may observe a broken link between the empirical approach with short iterations on sprint (and maybe release) level typically done within R&D Teams and higher altitude planning (releases, roadmaps and strategy).

What is planning?

Let’s double-click first on planning in general. There are precise definitions out there, so I will not hold back to quote one here:

Planning is nothing but thinking before the action takes place. It helps us to take a peep into the future and decide in advance the way to deal with the situations, which we are going to encounter in future. It involves logical thinking and rational decision making.

https://businessjargons.com/planning.html

Yes, the more complex your environment is, the more difficult it gets. So far so good. As of now, I can see no contradiction to agility at all, do you?

You may have noticed, that the classical planning approach is static. It is done at a certain point of time and leading to decisions lasting for a period of time, in some cases for the whole project or enterprise. For example budget, staffing or scope or timing related decisions. Or all at once. Ouch – now we have found the glitch in the matrix. Because when time is passing, our experience and knowledge grows. In classical planning approaches there is by design neither empiricism nor learning involved.

Agile planning includes several layers with different altitudes and different rhythms, each containing feedback cycles. 

Planning in agile context

Let’s circle back to how and when people are doing planing in agile approaches. There are well known and widespread practices of planning and there are areas of pioneering. In Scrum, planning is an substantial and frequent executed element of the flow.

Daily

To get out the most of the working day within a team, the upcoming tasks are assessed in the Daily Scrum. Roadblocks are identified and countermeasures immediately started. It is all about the best possible planning for the day. With the latest and greatest knowledge at that day.

Of course nobody can anticipate in advance which teammate is on sickness leave, which incoming dependency is delayed and if the physical presence in the office is possible (thanks to covid). As a consequence all planning related to the optimum efficiency during the day in advance is simply a waste of time. And we do not like waste.

Here the first big difference to big design upfront waterfall project planning reveals:

 Plan as late as possible and only the bare minimum required. 

That is by the way part of the lean mindset. This does not say do not plan at all – just to be absolutely clear.

Sprint

Higher altitude, there is the Sprint Planning in Scrum. Of course a Sprint Planning may take place weekly, bi-weekly or even 4-weekly.

In the Sprint Planning the What and the How of an valuable increment is planned. Yes, we aim to close and deliver this 2-weeks container of a team’s workforce. Because we do not know what will happen in 5 weeks and who misunderstood which epic before

The WHAT is a result of the priority (in the backlog), dependencies and capabilities of the Team and – in scaled environments – of the teams.

Plan the outcome, not utilization 

In the latest update of the Scrum Guide, it was explicitly mentioned to define a Sprint goal. Manage the outcome rather than the work of people. Do not get stuck in the utilization trap, do not try to keep everybody busy here. Remember the PO’s responsibility: maximize the value created. Do not try to maximize the time of individuals spent. Classical project managers are used to do that, but this is counterproductive.

Powerful questions for Sprint Planning:

• How does our increment brings us closer to our (market relevant) goal?
• Can we even get faster there?

Refinment

In the refinement especially the HOW is assessed by the experts. An substantial part of the requirements engineering is happening here. Wait, requirements engineering, isn’t that an “classical discipline” not required in agile disciplines? Sorry to disappoint you. But in agility we of course do not do everything in the beginning leading to huge word files containing hundreds of pages (which nobody can remember the details or even read in one go) and sober enough to get a noble price for. Again, this is often waste. Similar to planning you might follow the principle:

Refine as late as possible and only the bare minimum required. 

Your engineers will tell you what they need to assess the dependencies and estimate complexity. I promise.

Next to preparation of the next increment we look during the regular refinement even further – based on the progress and clarity of the top priorities. We keep always the iceberg model of the backlog in mind:

Plan a backlog like an Iceberg: if you go deeper, the backlog items are less exact refined and typically bigger in size.

Release planning (frequent)

I have heard that there are still people out there who do not want to get their invested money back as soon as possible. No joke, these kind of people are still existing in the business world. I have seen them, believe me.

All the other people want to release a valuable increment to the market, to the customers as fast as possible. The more frequent the better. We want to fail early, shorten the time-to-market, have earlier ROI, facing less risks etc etc etc etc.

There is of course an exception to this rule of thumb: if you aim for the bigger value, the higher mountain, you might have to invest in mid- and long-term enterprises creating a stable foundation creating more revenue with higher efficiency and scaling abilities. Platform strategies are a typical example. This is where complexity in planning kicks in. But this should not stop you at all from testing your assumptions as fast as possible in the market. This is the ultimate proofpoint for your strategy.

How to plan these (frequent) releases?

Your building blocks for planning are

• Priority, typically based on value, risk, timing, effort.
  • Sophisticated methods like https://www.scaledagileframework.com/wsjf/ can be used.
• Epics and their contributions (Stories)
• Dependencies
• Estimated complexity of Epics and/or contributions
• Empirical measured velocity of Epics
• Empirical measured velocity of team(s) (contributions/stories per sprint)

One key is to define the smallest possible value worth it to ship it to the market. Or to test your strategy assumption as fast as possible.

Keep in mind to maximize the value, aim for the smallest possible increments and minimizing your risk next to minimizing the time for delivery. This is where the MVP kicks in:

A minimum viable product (MVP) is a concept from Lean Startup that stresses the impact of learning in new product development. Eric Ries, defined an MVP as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. This validated learning comes in the form of whether your customers will actually purchase your product.

https://www.agilealliance.org/glossary/mvp/#q=~(infinite~false~filters~(tags~(~’mvp))~searchTerm~’~sort~false~sortDirection~’asc~page~1)

Once enough value for an MVP is created, you want to ship instantly. We name this step the

MRD - Market Release Decision

Now real-world problems – or assumptions in your platform strategy – are addressed. In this MRD we assess the completeness of the artifacts and organizational preparation. If done means done (for example proven by regression testing), Product Owners, Product Managers and involved business people decide together to ship this value to the market.

Plan within the context

In addition it is very important to create a context in which the people can focus on the common goals.

Plan the project or enterprise to be stable over time to deliver towards the goals

Which involves

• People and their skills
• Budgets
• Financial results
• The best possible view on your customers and the market

This is exceeding – depending on your context – the “release and value” area but is highly connected to it.

Planning, Part II

In the upcoming article “Planning in agile environments (Part II)” the topics Roadmap, Strategy and Vision will be covered. Stay tuned …