Rediscovering the Obvious

…stumbling in the footsteps of greatness

Archive for February, 2011

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

Away with “Active”

with 3 comments

I dusted off my personal kanban about 45 days ago when I started at Rally, and it’s been a very interesting path since then. When I first rebuilt and updated the contents, the columns were Eventually, Midterm, Nowterm, Active, and Done, and they were essentially prioritization buckets so that I didn’t have to mess around sorting each of the individual items. Roughly mapped to Must Have, Should Have, and Could Have [1].

Last weekend, that changed. I was getting frustrated because I kept having to prioritize things I didn’t really _care_ about, but that I needed to do. It bothered me a lot that I couldn’t get to the stuff I care about, so I updated my columns again. My columns became Options [2], Proactive, Reactive, Active, and Acted. Suddenly I felt much better about things, because I could prioritize the things in Proactive in order of how much I care about them, how engaged I would be, and how distant the payback on my investment of time would be. Reactive, I prioritize based on a combination of ease and cost of delay.

It’s been working, but a pattern quickly emerged that bothered me. Either my active column was empty, or my active column contained the top item moved over my my reactive column. It didn’t tell me anything useful, it didn’t help me prioritize, it was just… there, taking up screen real estate without providing any value. So I zapped it. I don’t have an active column anymore, I just know I’m focused on the top item of one of the two columns that’s in the view. If I’m full of energy and wanting to engage, I hit the top of proactive. If I’m dragging a bit and just want to get some things done, but not pour energy in, I hit the reactive column. When they’re done, they’re dropped into Acted and left to languish with all their finished friends.

[1] Why bother with Won’t have?

[2] Options represents ideas that I don’t want to forget, but don’t have any desire to prioritize or work on now. Approximately weekly I skim that column to see if anything inspires me, but they’re roughly the “transient” class of service.

Written by erwilleke

February 15th, 2011 at 9:46 am

Posted in Uncategorized