Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches:
- Part 1: Creating Cross-Functional Feature Teams (Teams that can produce features on a regular basis)
- Part 2: Programs of Cross-Functional Feature Teams (Programs (multiple teams working together) that deliver features on a regular basis)
- Part 3: Agile Product Development (Adaptive and continual planning for all of product development, products and the project portfolio, not just projects)
This is Part 4, where other functions want to use agile approaches. I’m calling this “sharing” agile. If these people are part of a program or a project, the product development team(s) have asked them to participate in an agile way. This part is about embedding (I’m not sure that’s the right word) agile approaches into other functions.
Some functions are workgroups where the people work mostly alone but might collaborate. Think of Customer Support for example. Customer Support has a single-function workstream. Other functional workgroups have multiple workstreams.
In Support, people take tickets (the incoming queue of work) often alone. They work their tickets until they resolve the ticket.
Here is a possible kanban board for what might happen as a flow for these tickets. The queue of tickets is all the way on the left. Notice that there are two possible Ready columns: Ready for ranking and Ready to Start.
Customer support teams might rank and rerank their work several times during a day. Certainly, they do so during the week. They rank some work so it’s Ready to Start. It’s possible that they have work In Progress, Escalated to some other team/group/function, in Test. Depending on what the product is, they might need a Deploy column and then the work is Done.
Customer support often discovers they have “inconsistent” cycle time. That is, some work takes very little time (as in hours), some work takes forever (as in weeks), and some is in the middle somewhere, in the form of days. In my experience, those cycle time ranges depend on what the Product Development teams released.
How could a Customer Support group use agile approaches? They don’t work together. They can’t possibly plan for the next week, never mind two weeks. (A Tier 3 support group might be able to plan for more time, but I doubt it.) There’s not much value in that much planning. There’s no value in standups although there might be value in walking the board to see if anything is stuck after some time period. I would walk the board for escalations, and sometimes, the escalations are the Support manager’s job.)
A Customer Support group can find much more value in managing WIP (Work in Progress), and managing escalations (their wait states and potential bottlenecks). And, there is tremendous value in retrospectives with root cause analysis. While the Support people might find problems in what Product Development released, they often discover that their processes need tweaking. Customer Support can take advantage of double-loop learning with their retrospectives.
When I ran a Tier 3 support group many years ago, I asked my staff if we could retrospect on a one-week cadence. For some huge problems, that was too often. But, it mostly worked. I checked the state of the escalations with the people who had escalated. I didn’t do this as a group because the problems were so different. That would have wasted everyone’s time. We did do once-a-week learning as a team. I was not smart enough back then to use a paper board. I used a spreadsheet.
Even I, with my love of paper boards, am not suggesting that all Support groups use paper boards. Support often requires electronic tools to be most effective. I do recommend that the group add enough columns to see their flow. Sometimes, Support groups take the escalations out and put them on a paper board for tracking, because the work cycles between different people and teams in those columns.
Agile approaches for workgroups are different than for teams. Teams have interdependent work. Groups have (mostly) independent work.
I’ll do another post about agile for workgroups with multiple streams. And yes, I have a chapter about agile approaches for workgroups in Create Your Successful Agile Project.
| Reference: | Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development from our JCG partner Johanna Rothman at the Managing Product Development blog. |
