Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development

DZone's Guide to

Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development

Is Agile just for software development teams? Given that it started in manufacturing, probably not. We look at how companies can spread Agile beyond their dev teams.

· Agile Zone ·
Free Resource

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Here’s where we are so far in this discussion of what it might mean to “scale” Agile approaches:

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 these tickets.

Let's take the example of a Kanban board for that helps to organize the flow of these tickets. The queue of tickets is all the way on the left. There are also 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 (sent to some other team/group/function), or 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 of 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.

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Topics:
agile ,agile teams ,retrospective ,planning practices

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}