This week we had a learning moment and we thought it was worth sharing. We’ve been helping a team transition to Kanban to manage the flow of upstream business and analysis work that has a high degree of variation. Before we dive right in…a little background is in order:
- The team has been using a Scrum-ish process
- External dependencies are a persistent risk
- Upstream work was hampering downstream development flow
After a day of Lean Kanban training, we embarked on discovering how they tackled work. We mapped out their standard workflow on a kanban board. After talking through limiting WIP, pulling work, and managing flow via metrics we kicked them off and scheduled some followup meetings.
Upon returning, a pattern had emerged. It seemed that their kanban board had turned into a BUFD board. The work steps had not changed, but what was flowing through each work step was big, really big. It struck us at that moment, that what this team really needed was a deeper understanding of business decomposition. Typically this is a Product Owner responsibility, however in reality this team was handling some of these responsibilities.
Understanding how to break down large value streams into releasable chunks, features, and user stories seems easy, however the lack of mature software business practices was a clear gap on this team. It makes sense, this is an engineering team…not a product management team.
The lesson learned? Business practices matter. Wrapping a highly optimized workflow tool(Kanban) around work will not increase agility if the right sized work is not flowing through the system. This seems obvious but this was a great reminder that reinforcing the basics during any change initiative is worth while and adequate business practices are not common.
