‘Big Group Planning’ – the winners and losers

Planning on a scale with more teams and numerous dependencies is always both exciting and challenging. Program Increment (P.I.) Planning and similar derivations (sometimes also referred to as Big Group Planning, Big Room Planning etc.) that have been inspired by the need to have a clear picture for a period of several months in advance is a perfect case in point. Gathering a group of some 150 people divided across more than 10 teams to fix the scope of their work for the upcoming months may seem very logical, but the question is: Is it a win-win scenario where you have a detailed plan and everybody has clarity, or does the format present ‘unexpected’ challenges?

Prioritising in the dependency jungle

One of the first challenges to a Big Room Planning is that it is time consuming. Over the usually 2 days there are often seemingly endless discussions on the order of the priorities in each team and within the entire department. The further one moves away from the next sprint the more dubious the prioritisation often becomes. Even with clear overall objectives and goals it is challenging to get the priorities on the more granular level. It is in fact a waste of time because priorities at this level can and do change.

Ultimately, the image with all the epics and user stories hanging on the wall covering a period of 3 months becomes messy and confusing with numerous (potential) interdependencies emerging. Perhaps the biggest benefit of this result is the ability to pose questions on whether the current team cut actually makes sense in reality and can be improved on.

However, it is not always the case that this is taken with much concern because the focus is on hammering out a detailed plan for the next 3 months. Predicting every eventuality, including availability of staff members, exact velocity of teams and the exact priorities of every pre-defined user story takes priority. Not only does this run the risk of requiring amendment but has very little to do with the logic of inspecting and adapting. Instead, it is pretty inflexible and reporting oriented.

The mere focus on noticing dependencies and defining how best to deal with them, instead of asking why they come about and how they can be solved is a crucial fallacy in any planning process of this type.

Constructive exchange and silent Scrum Masters

But it is not all negative. Planning at this level also ensures useful exchanges between the different teams, product owners and other stakeholders to get a general feel for the direction in which the products are going. There are sometimes also sessions where some of the key achievements from the previous quarter are presented. And, there is a chance to get a better idea of what kind of impediments the entire department is dealing with.

What is often concerning is that the Product Owners present the challenges or impediments the different teams are facing. There is nothing to say that they, as intelligent human beings, are not qualified to do this. Indeed, many very good points are raised. But why aren’t the Scrum Masters taking this responsibility? Is there a cultural issue where old ‘Bosses’, turned Product Owners, never really changed much except the signature in their emails? And meanwhile the Scrum Masters got some Post-its and markers to play with? It certainly doesn’t feel like an eye-to-eye level proceeding. Come to think of it, maybe, just maybe it would be nice to also have the team present what they achieved rather than the Product Owners doing that.

Big learnings from ‘Big Planning’

 But what do we learn from the whole planning process?

There is no excuse for using two entire days for a meeting like this. Even a whole day is too much. A department level review, or presentation of what was done is a great idea, and helps people put all the work that is being done in other teams into context. Speaking about challenges or impediments in such an arena is nice. But would it not be better suited to a weekly round where Scrum Masters exchange and jointly decide how to go about impediments based on the feedback, they as Scrum Masters got from their teams?

But the focus here was on Planning. So, the question that needs answering is how much planning was actually done? The simple and superficial answer is: quite a lot. Digging beneath the surface however, the picture changes. Almost always a significant proportion of the planning has not proven to be useful and will need to be amended on the go. The reason is that priorities need to be reprioritised and dependencies need to be readjusted accordingly. This is actually the best-case scenario because the scope is allowed to change. The worst case is when departments blindly stick to the plan and end up delivering solutions that don’t solve the problems and challenges, they were supposed to address. Either way, there seem to be more efficient ways of conducting work in a scaled environment where more teams work together in one department.

Get on the right track

To avoid many of the pitfalls noted above a logical alternative possibility would be to have regular shorter meetings. Implementing and sticking to Backlog Refinement and Sprint Planning 1 and 2 meetings in teams, while at the same time holding Product Owner weekly meetings is a good start. The team meetings define the backlog for the teams. While, during the PO Weekly the participants discuss upcoming user stories for the next 2-4 weeks and how they contribute to the bigger services or products (in any case concrete user-centred targets) the department is focusing on. That way not only would a clear priority order be easier to establish and would not have the same risk of needing to be amended, but the potential dependencies could be immediately addressed and not hypothetically discussed. Maybe it would also be a good opportunity to consider removing dependencies and ensuring more end-to-end focus of teams.

The agreed upon order of user stories could then simply be pulled into the particular teams for estimation and planning. Unlike with planning for 3 months in advance this approach gives you the flexibility to inspect and adapt to the circumstances around you and not worrying about making plans that will inevitably change with the high degree of volatility and interdependencies. After all, being agile is about being able to take in what is around you rather than blindly guess the future.

And the winner is …?

Perhaps I’m being ungrateful, but I think there are no real winners in these medium-term planning meetings. Except for the company making Post-its maybe. Planning on a strategic level is something else, but the detailed planning just takes way too much time, is not productive and seems to only make top management happy. Isn’t agile about delivering high quality working solutions to use problems? And shouldn’t that make the management even more happy? As a department head I would not be satisfied with the result of 3-month detailed planning cycles and would ensure that I take the time to learn from a retrospective on the process.

Eisenhower famously said: ‘Plans are useless, but planning is indispensable’. Reducing the timeframe of planning and being ready to adapt the scope of your solutions and processes will bring you more success than a nice-looking plan. After all, the more time you spend on planning and amending it the less you have for developing solutions.

 

Fotos: pixabay license – eak_kkk

 

Geschrieben von

Tihomir Vollmann-Popovic Tihomir Vollmann-Popovic Planning on a scale with more teams and numerous dependencies is always both exciting and challenging. Program Increment (P.I.) Planning and similar derivations (sometimes also referred to as Big Group Planning, Big Room Planning etc.) that have been inspired by the need to have a clear picture for a period of several months in advance is a perfect case in point. Gathering a group of some 150 people divided across more than 10 teams to fix the scope of their work for the upcoming months may seem very logical, but the question is: Is it a win-win scenario where you have a detailed plan and everybody has clarity, or does the format present ‘unexpected’ challenges?

Prioritising in the dependency jungle

One of the first challenges to a Big Room Planning is that it is time consuming. Over the usually 2 days there are often seemingly endless discussions on the order of the priorities in each team and within the entire department. The further one moves away from the next sprint the more dubious the prioritisation often becomes. Even with clear overall objectives and goals it is challenging to get the priorities on the more granular level. It is in fact a waste of time because priorities at this level can and do change. Ultimately, the image with all the epics and user stories hanging on the wall covering a period of 3 months becomes messy and confusing with numerous (potential) interdependencies emerging. Perhaps the biggest benefit of this result is the ability to pose questions on whether the current team cut actually makes sense in reality and can be improved on. However, it is not always the case that this is taken with much concern because the focus is on hammering out a detailed plan for the next 3 months. Predicting every eventuality, including availability of staff members, exact velocity of teams and the exact priorities of every pre-defined user story takes priority. Not only does this run the risk of requiring amendment but has very little to do with the logic of inspecting and adapting. Instead, it is pretty inflexible and reporting oriented. The mere focus on noticing dependencies and defining how best to deal with them, instead of asking why they come about and how they can be solved is a crucial fallacy in any planning process of this type.

Constructive exchange and silent Scrum Masters

But it is not all negative. Planning at this level also ensures useful exchanges between the different teams, product owners and other stakeholders to get a general feel for the direction in which the products are going. There are sometimes also sessions where some of the key achievements from the previous quarter are presented. And, there is a chance to get a better idea of what kind of impediments the entire department is dealing with. What is often concerning is that the Product Owners present the challenges or impediments the different teams are facing. There is nothing to say that they, as intelligent human beings, are not qualified to do this. Indeed, many very good points are raised. But why aren’t the Scrum Masters taking this responsibility? Is there a cultural issue where old ‘Bosses’, turned Product Owners, never really changed much except the signature in their emails? And meanwhile the Scrum Masters got some Post-its and markers to play with? It certainly doesn’t feel like an eye-to-eye level proceeding. Come to think of it, maybe, just maybe it would be nice to also have the team present what they achieved rather than the Product Owners doing that.

Big learnings from ‘Big Planning’

 But what do we learn from the whole planning process? There is no excuse for using two entire days for a meeting like this. Even a whole day is too much. A department level review, or presentation of what was done is a great idea, and helps people put all the work that is being done in other teams into context. Speaking about challenges or impediments in such an arena is nice. But would it not be better suited to a weekly round where Scrum Masters exchange and jointly decide how to go about impediments based on the feedback, they as Scrum Masters got from their teams? But the focus here was on Planning. So, the question that needs answering is how much planning was actually done? The simple and superficial answer is: quite a lot. Digging beneath the surface however, the picture changes. Almost always a significant proportion of the planning has not proven to be useful and will need to be amended on the go. The reason is that priorities need to be reprioritised and dependencies need to be readjusted accordingly. This is actually the best-case scenario because the scope is allowed to change. The worst case is when departments blindly stick to the plan and end up delivering solutions that don’t solve the problems and challenges, they were supposed to address. Either way, there seem to be more efficient ways of conducting work in a scaled environment where more teams work together in one department.

Get on the right track

To avoid many of the pitfalls noted above a logical alternative possibility would be to have regular shorter meetings. Implementing and sticking to Backlog Refinement and Sprint Planning 1 and 2 meetings in teams, while at the same time holding Product Owner weekly meetings is a good start. The team meetings define the backlog for the teams. While, during the PO Weekly the participants discuss upcoming user stories for the next 2-4 weeks and how they contribute to the bigger services or products (in any case concrete user-centred targets) the department is focusing on. That way not only would a clear priority order be easier to establish and would not have the same risk of needing to be amended, but the potential dependencies could be immediately addressed and not hypothetically discussed. Maybe it would also be a good opportunity to consider removing dependencies and ensuring more end-to-end focus of teams. The agreed upon order of user stories could then simply be pulled into the particular teams for estimation and planning. Unlike with planning for 3 months in advance this approach gives you the flexibility to inspect and adapt to the circumstances around you and not worrying about making plans that will inevitably change with the high degree of volatility and interdependencies. After all, being agile is about being able to take in what is around you rather than blindly guess the future.

And the winner is …?

Perhaps I’m being ungrateful, but I think there are no real winners in these medium-term planning meetings. Except for the company making Post-its maybe. Planning on a strategic level is something else, but the detailed planning just takes way too much time, is not productive and seems to only make top management happy. Isn’t agile about delivering high quality working solutions to use problems? And shouldn’t that make the management even more happy? As a department head I would not be satisfied with the result of 3-month detailed planning cycles and would ensure that I take the time to learn from a retrospective on the process. Eisenhower famously said: ‘Plans are useless, but planning is indispensable’. Reducing the timeframe of planning and being ready to adapt the scope of your solutions and processes will bring you more success than a nice-looking plan. After all, the more time you spend on planning and amending it the less you have for developing solutions.   Fotos: pixabay license - eak_kkk  

TEILE DIESEN BEITRAG

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email