Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance.
In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream: take in the tickets, work on the “most important” one first, see if you need to escalate and finish it. Everyone works towards the same goal.
What about if you work in a workgroup that has several streams of work? I’ll use HR as an example because HR often has these streams:
- Benefits administration: retirement plans, health care, that kind of thing
- Recruiting and hiring: how to find people and bring them into the organization
- “Performance Management”: how to manage and improve the performance of the people in the organization. Don’t get me started on the value of this work. I have other drafts to address this wrong-headed assumption especially in an agile organization.
In that case, the workgroup rarely collaborates on the work. It’s possible that Customer Support collaborates on their work. However, the different people in HR do not tend to collaborate. It’s the same in Finance: Accounts Payable and Accounts Receivable are not the same thing. Depending on where Purchasing sits, they might be a different stream, also.
If the group wants a big picture of their work, this kind of a kanban board might help. Note that there are no WIP limits because the group does not collaborate. There is no interdependent work.
Each of these people might want their own board to show the details of their work, but that’s not this board.
There is no reason for—and it would not be helpful—for this group to have a standup. That would be a serial status meeting. They might want to monitor decisions to see if other people change their minds about what’s going on in their group. They might want to retrospect on how often they have Waiting work and what to do about it.
There is a difference between product development agile approaches and workgroup approaches. I have found that visualizing the work is the key for unlocking lower WIP limits and faster cycle time.
Yes, I have this board as an example in Create Your Successful Agile Project.
In a Marketing department, the product managers had their work and Marketing Communications had their work. MarComm had to produce videos of customer case studies, white papers, and testimonials. MarComm actually looked more like a product development feature team than the product managers did. The product managers had to continue to think about the product direction and how often they could replan. They each had their own boards (product management and MarComm). And, they put together a board much like the one for HR with streams on the bottom so other people could see bottlenecks.
If you work in a workgroup, you might need a board that shows the flow of work in your stream, and a different board that shows the overall group’s work at a higher level. There is no right answer.
Here are the posts so far:
- Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams
- Defining “Scaling” Agile, Part 2: Program Management for Product Development
- Defining “Scaling” Agile, Part 3: Creating Agile Product Development Capabilities
- Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development (That post and this one are how you might share agility outside of product development)
I think I need another part about agile management and then I can talk about an agile business. I’m enjoying the rigor of my thinking. I hope you do, too.
| Reference: | Defining “Scaling” Agile, Part 4A: Sharing Agile Outside of Product Development from our JCG partner Johanna Rothman at the Managing Product Development blog. |
