Rediscovering the Obvious

…stumbling in the footsteps of greatness

More on expand collapse pattern

without comments

There’s a thread on kanbandev today about the role of expand/collapse, and its value in helping to identify the BVI/MMF [1]. Chris’ post, linked above, talks effectively about the ability to discover work that doesn’t need done, as do a couple of Ron’s contributions in the same thread. Unfortunately, from my perspective the language there is still primarily about decomposition of scope, rather than focusing on the real nature of the work we do. The value I find in “expand / collapse” is very different. This learning and discovery is just one of several intertwining aspects important to understanding the nature of the work, but I believe that effective teams are focused on learning and discovery as a matter of course.

Focus the team

One major benefit of expand/collapse is that it focuses more of the team on related tasks. I often joke that at Inkubook we had an MMF WIP limit of 1.1, meaning that there would be one MMF that most of the team was focusing on and one that was just being finished up or just being started. We had a different limit (four most of the time, iirc) for the tasks we broke out of the MMF, and when there weren’t enough valuable tasks left for the MMF that was about to end, people would start on the next one (with the focus being on finishing, not on starting). From what I’ve seen, type of focus scales nicely across teams and planning horizons, allowing “team” and “set of related MMF’s” to be the next unit of abstraction outward. This effectively enables WIP limiting and goal focus at that level. If taken all the way, I should be able to see how my individual activity today rolls all the way up to my company’s True North [2]

Manage Learning in Progress

I spoke on this at the LeanSSC 2010 UK [3] and have been observing the concepts in practice since then. Teams are limited in how fast they can learn, primarily because learning takes research and conversation to achieve [4].  When you apply expand/collapse, keep an eye on the amount of stuff to “figure out” in each broken down item. The ones with lots of stuff to figure out will have the highest variability. I can’t say if you should concentrate it or balance it, or whether you should front-load it or back-load it, but be aware of it as you make your decisions and fit the breakdown to your context. If the process of breaking it out allows you a way to get a BVI without having to figure much out, then by all means defer the stuff that requires lots of figuring out.

Manage abstractions

As I mentioned above in the focus section, the levels of expand/collapse provide a very effective way of managing the abstractions inherent in the work. It’s far easier to have value and prioritization conversations about 5 large items than 50 (or 500) smaller items [5], especially if you’ve managed to effectively engage your senior management in the decision planning. On the other hand, asking a dev team to implement against a single large item taking over a month is pointless, they need the detail to effectively track and deliver against the goals. Visualization of progress against goals is also easier due to the aggregate data, enabling the use of goal-focused reports like a parking lot diagram.

Triggering conversation

The need to apply expand/collapse is also a trigger to figure a bunch of stuff out. The best way to figure things out is to have a conversation about what’s needed with the relevant people. The mere act of decomposition is a value add activity, and should not be done by a single individual. Scrum uses sprint planning and task estimation to drive these conversations, but dropping iterations doesn’t excuse you from the need to explore the meaning of work items and tasks as a group. The conversations need to happen, and the acceptance criteria need to be discovered: “Don’t start what you can’t finish” [6]

Enable Operational Languages

One very nice side-effect of the abstractions in use is that the language used at each level of abstraction can be made appropriate to the audience, and should be. I’ve often heard about deep misunderstandings between “development” and “the business” because the two are speaking completely different languages while using the same words. This is only made more complicated when you introduce other groups as valued stakeholders, such as legal, finance, compliance and operations. With effective expand/collapse and a good goal-oriented organization, the highest levels can be written in terms of markets and the organizational vision, middle levels in terms of the desired behaviors enacted in the market and the protections the organizations require, lower levels in terms of the features that enable those behaviors, and the development level in terms of the actions that need completed to create those features. This is not a problem, this is a positive step to communicate effectively across the organization! [7]

Finally, a perspective

At the lowest level, converting from the most detailed card (task/story/line item/whatever) to code (configuration/html/sql/whatever) is its own expand/collapse translation, and the conversation is one with your compiler and (hopefully) automated tests. There’s no expectation that you can clearly define what code you need when you pick up a task, you’re free to be a professional and add, remove, and modify the code until it solves the need at hand. The same logic should apply to the tasks to complete a story, the stories required to complete an epic, and any other expand/collapse relationship you may have in your particular environment. There are many effective patterns, practices, and guidelines, but the set of actual “rules” is fairly minimal. Do what makes sense, and always strive to be more effective in what you do.

[1]  Business Value Increment, which Chris renamed from Minimum Marketable Feature to clarify it as different than what’s talked about in Software by Numbers

[2] Or whatever you call your organization’s guiding vision for the year/quarter/decade


[4] Dan North tasks about this as removing ignorance in the context of Deliberate Discovery.

[5] I don’t think I’ve seen a Scrum training deck in years that doesn’t have a pyramid diagram for story size indicating the desired backlog composition

[6] Paraphrasing from Alan S, Dean L, and Don R among many others.

[7] I plan on writing shortly about the role of a BA as linguist in this exchange. The post is languishing as a half-finished draft.

Written by erwilleke

February 24th, 2011 at 8:44 pm

Posted in Uncategorized

Leave a Reply