IT Delivery Efficiency: It’s the In-Between Stuff

I’ve seen a commercial for a candy bar recently where an actor describes the best part as “the in-between stuff”. Since I rarely eat candy bars I didn’t pay attention to what was being advertized. But that phrase stood out to me. It got me thinking about software development and how it has gotten so fragmented these days.

Passing work between specialty skill silos is the norm these days. Analysts hand off work to developers who most often do the work along application architecure boundaries. There is front-end work, back-end work, database work, and likely separate testing. While the work batches have reduced in size from traditional project management many other waterfall-like aspects remain.

Even teams who leverage frameworks like Scrum often operate in the traditional sense. User Stories pass from specialty to specialty, sometimes modeled as separate workflow states or hidden within a single “In Development” state. The process more resembles an assembly line than a team effort.

Handoffs Create Queues, Queues Create Delay

When work passes from skill to skill it’s very unusual the downstream skill has immediate availability to accept the work item. Far more often the work item needs to wait for availability. Thus, a list, or queue, of work to do is necessary.

Some of these queues are visible, modeled as “Dev Done” Or “Ready to Test” workflow states. You may have heard of these called buffer states.

Here’s the thing about handoffs though, the other person/team is already busy. They won’t be able to start that work immediately. So what will they do? They will “put it on the list”, meaning they will add it to a backlog. Backlogs are queues, things waiting to be done. If you’re lucky, or negotiate well, it might even get done soon. But perhaps not. It’s your priority work, not theirs.

Work sitting in a queue adds delay. It’s inventory. It’s something we’ve spent time on but is not yet usable. The customer gains no benefit. Work sitting in queues, also thought of as work at rest, increases delay. It’s blowing out your metrics and thus reducing your predictability (adding tails).

All handoffs go into a queue, all queues add an unpredictable amount of delay. That’s something to remember.

Expose All Queues

Any time you discover a handoff, or queue, you should visualize it on your board. There are several ways to do this:

  • Add a state, or column, where handoffs happen in the flow. Don’t use a generic “blocked” or “dependency” column which can cause work to move back & forth on the Kanban board. Work going back and forth will screw up your metrics and likely wreak havoc with your WIP Limits when things become “unstuck”.
  • Use a decorator on the cards such as a tag. Make sure you note the date and external person or team as well. This will help you understand how long these take to be resolved for the various external groups.

Something you should do with all queues: set WIP Limits on them and measure delay. By respecting WIP Limits on handoffs you will cause extra attention on resolving them when too much becomes blocked and nothing new can be pulled into the overloaded states.

Hidden Handoffs

Handoffs are not discovered, or revealed, by looking at metrics and dashboards. Not all are modeled on a workflow visualization board such as a Kanban Board. Some are not so obvious. Careful observation and asking questions are necessary to uncover these handoffs. They are hiding in the structure and timing of work items.

The two most common are:

  • Component work items, also known as horizontally sliced stories. While not handoffs in the traditional sense, value isn’t delivered until the team completes multiple work items. In these situations there will often be front end, back end, database, and other specialty work items.
  • Feature dependencies between teams hidden across Product Increment (PI) boundaries (SAFe). These happen when teams don’t plan Features that depend on other Features during the same Product Increment. The downstream Feature will be planned in the next PI. This can happen within a single team or across teams in an ART (Agile Release Train). It’s harder to detect when it’s across teams.

What these have in common is that they increase risk. Integration of work (code) happens far later. Errors in coding and getting feedback on value delivered happens weeks or months after developing the code.

Create vertical, or full-stack, work items. Value is delivered within a single work item and the team creates code for the entire technical stack within that single work item. Move away from creating technical, task level work items per specialty skill to work items representing business value. This takes practice.

Teams that hide handoffs across PI boundaries are likely doing so due to metrics. One such metric is measuring, and rewarding, Feature Completion vs Features Planned. Teams are less likely to “take a chance” of planning dependent Features in the same PI if they are rewarded for not taking the chance.

Another hidden handoff can occur when teams are directed to lower the amount of “red yarn” (dependencies) within a PI. Hiding the dependency across PI boundaries eliminates one piece of red yarn without any change in how teams and ARTs operate.

These two practices significantly slow delivery of value, often by several months. These dysfunctions are not easy to uncover.

The In-between Stuff – Agile Interactions

Agile has permeated much of the software development space but it’s uncommon to find teams who are effectively leveraging Agile principles. It’s rare to find ensemble programming, or mobbing, where the entire team comes together on a single, or two to three, work items at most.

Go to most any organization and examine their IT change efforts. Largely they will target “teams going faster”. They will spend an inordinate amount of time and money to find ways for people to increase their “productivity”.

It will likely be also true that these change efforts will yield some positive results, at least initially. But not earth shattering. Often such results create a “we’re different, Agile doesn’t work here” type response in management. The juice wasn’t worth the squeeze.

But they are missing a huge opportunity. The major slowdowns are in the system, not in how the people perform their jobs.

Too much effort on “Agile” is spent teaching teams different frameworks, tools and practices. Far too little effort focuses on the “in-between” stuff, the interactions between people and teams. This should be your focus, especially if you are in management. You can cause change in the system, likely the teams cannot.

Examine what your data is showing you. Go spend meainingful time with people/teams and understand what is causing them grief, discover where the delays are happening.

How many handoffs are in the system because of the way teams are formed, or how the system is architected? How many skill silo component teams, or shared service teams, do you have? What delays are being caused due to that? Is that design making work easier to manage or easier to do?

Use a practice such as Blocker Clustering to capture all the relevant information about handoffs, blockers and defects. This is a powerful tool to bring about change and begin resolving dependencies rather than only tracking them.

Thinking back to far younger days, double-stuff Oreos were the bomb (to use an old phrase too). They understood that it was the in-between stuff that made a cookie legendary. They used the idea, similar to eXtreme Programming, that if a little is good, more must be better. They doubled down on the in-between stuff. Perhaps your Agile change efforts should as well.

Until next time!

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Prev
Scrum and Shu Ha Ri

Scrum and Shu Ha Ri

Being the best team ever at performing Scrum is not the goal

Next
On Changing the Sprint Goal – A Scrum Tale

On Changing the Sprint Goal – A Scrum Tale

I was free to adapt the work items but drinking wine was not one of them

You May Also Like
Total
0
Share