Planning for component teams – the hell of it
Lately, by chance, in a workshop, I had to cover the topic of planning for component teams (vs. feature teams). And the hell of having to deal with all the dependencies just came back to me. It hit me like a hammer how hard this can be.
I had to deign a little exercise to give the participants the experience of having to do so (and I had little pity as I had to do so for years of my life). I don’t really know if this or a similar exercise actually exists and I can’t even claim it for me, as it was too easy to design. So, I don’t want to describe just how hard it can be to arrive at feature teams when you are coming from component or very specialised teams. (I know!) I also don’t want to discuss how many serious facts about your context can keep you from even trying. And I don’t want to discuss the lingering questions around the topic like “Will feature teams deliver the same quality?”, “Don’t we lose all our specialisations and special knowledge?” and everything around it – although all these are very valid questions. Even more as when you change things in your environment it is about your life and nit about mine or about theory.
Now, to the little, simple exercise:
We have four component teams or specialized teams, who go by the names of red, blue, green and yellow. In which red could stand for backend, database, payment API or anything like it, while blue could stand for business logic, testing, SAP integration or aynthing else. It does not matter. What matters is that to complete a feature we need some or all of the teams.
The teams think they can together deliver the features in the next coupe of weeks. They did something like a SAFe PPI planning and as a result we have the tasks needed to complete the features in the above chart ordered in the required sequence. Got it? The numbers on the tasks represent the days that were estimated by the teams.
Now, the simply task is to tell me, when will the four features be delivered? Conditions are: I wankt the tasks to be ready (or delivered) in the sequence of their prioritization, of course. If you can not only tell me when each feature will be ready but also give me a glimpse of how the teams will take on the tasks, that’ll be bonus points. Bonus points will just be given for the sake of understanding the difficulty, as ,by ideology, I completely trust the teams anyway. The nice thing about the exercise is: This is all lab conditions, days rather than story points, we have a clear sequence, we already established dependencies. Nothing is fluffy or complex about this. Ok? Shoot! I’ll give you, hmmm, 5 minutes.
Done?
No?
Not yet?
Well, you’re not alone: While obviously being quite simple, the task was not completed by any of the groups in the workshop. While in parts this is due to the effect that the groups first have to align on a strategy, it still surprised me just how hard this exercise was to complete in short time.
Are you top for another exercise, based on the same data? What about the situation that some of the estimates were simply not exact. Let’s consider the following (and if you want you can do the whole thing in baby steps!):
Exercise 2 – changing estimates
- feature 1: task 1, team red is actually faster and it only takes 2 rather than 5 days.
- feature 2: task 2, team green takes 4 rather than 3 days
- feature 3: task1, team red, takes 5 rather than 3 days.
The sum of net working days (by conincidence, really) remains the same. How long does it take until complete delivery now?
Exercise 3: Another – quite realistic – complication could be to change priorities: Feature 3 is now most important and feature 1 changes to third place – to make things simple again. What happens now? net work days are now, of course, identical. But when will we be ready? Why?
Exercise 3 – changing priorities
While thinking over this – really simple and simplistic – exercise, it really nearly killed me again and memories from the past came up on just how difficult it is to handle this in a life full of change around you. And all of a sudden I remembered just why I disliked the idea of specialised teams (while I full well know that in many environments they are required and to be there for years and years. I also do not condemn and judge that at all!) And it also reminded me on why I do prefer the principles of flow and forecasting and the simplicity of planning behind it.
A little note: I’ll soon start announcing my blog posts via my newsletter. If you’d like to be informed whenever a new blog post comes up, please subscribe here. It’d make me quite happy! 