How to Handle Shared Resources to Deliver With Less Delay

March 27, 2012 — Posted by Ken Pugh

Ideal world seldom plays out in reality world. In an ideal world, every person on a team can carry out any task; that way, people can simply swarm to the highest priority item until it is completed and then move onto the next one. In the real world, people are specialized. They have specialized training and experience. They work in unique contexts. They do not have effective skills in every technology from JSF to SQL. In the ideal world, people should only be focused on a single task within a single project or feature. In the real world, people with specialized skills are shared between different teams or features in order to fully utilize their specialties. Reality messes up planning and delivery.

What can you do in the real world?

Use a combination of Kanban boards to help schedule, track, and show progress: one for each feature and one for each specialized or shared individual. It works in the real world.

Terminology

In any world, it is a good idea to define terms to avoid confusion and semantic differences. The terms "feature" and "story" have diverse meanings in the Agile world. I use "feature" to describe an item that is independently releasable and "story" to describe a portion of a feature that is independently developable. It's assumed that all stories within a feature are required to release it (e.g. the feature is a minimum marketable feature). Stories may be required to be implemented in a particular sequence and they also may be broken down into sub-items (tasks or developer stories). These two issues will be addressed later.

Ideally development of stories that involve specialists (people with unique skills or shared resources) should be scheduled so there are no conflicts. But varying item size and varying needs for specialists usually do not make that practical. That's where the specialist Kanban boards come into play, as I describe below.

With multiple people working on multiple things, prioritization is the key. Without having clear priorities for each feature and a clear sequence for the stories within it, the delay in releasing features can be large.

Overall Kanban Board

Here is an overall Kanban board for a set of features. It shows what people in an organization are working on. The features may be from one project or multiple projects. The features have been prioritized by the business. For illustration simplicity, the number in the title is the priority. Feature 1 is the highest priority one.

Overall Feature Board

Input Queue

Working On

Done Awaiting Full Acceptance

Done

Feature 3

Feature 1

   

Feature 4

Feature 2

   

Feature 5

     

 

Ideally, features should be independently releasable. Often a feature requires an overall test that cannot be performed until other features are complete. This could be for any test that cannot be performed during the development period – e.g. extensive performance or security testing, focus group usability testing, and so forth. Features should not be considered complete until all these tests are performed, since there is a possibility that a feature may have to be re-worked. Leaving the "almost there" items up on the board reflects the possibility of more work to be done. This represents the "nagging suspicion" that the work is not quite over. Once the item has been approved for deployment, then it moves to the done column.

Feature Kanban Boards

Each of these features has its own Kanban board to track the progress of stories within it. Whether these small boards are just swim lanes within the large board or separate boards is up to you. Use the approach that works best for your particular environment.

Following is an example of two feature boards. Yours may have additional columns, representing stages within the development process.

Each board shows the stories for one feature. The stories should be sequenced. The sequence may be based on the order of development (e.g. doing the typical work flow first before doing the alternative workflows), inter-story dependencies(do all the stories for Feature 1 that require a particular resource first and all the stories for Feature 2 that require the same resource last), or any other developmental issues. The features in the overall board are sequenced by business value priority. The business value cannot be delivered until all stories are complete. So the stories are usually sequenced by development issues. This sequencing is important to help minimize delay in developing stories. For simplicity of illustration, the letters in the title represent the development sequence.

Feature 1

Input Queue

Working On

Done Awaiting Full

Acceptance

In Full Acceptance Test

Done

Story D

Story C

Story A

   

Story E

 

Story B

   

 

Feature 2

Input Queue

Working On

Done Awaiting Full Acceptance

In Full Acceptance Test

Done

Story B

Story A

     

Story C

       
Specialist Kanban Boards

Suppose you have two specialists – George for JSF and Sally for SQL. Their skills are needed for particular stories. George and Sally could represent two groups of developers, each of whom has the same skill set.

Here is what George's board looks like.

George's Board

Input Queue

Working On

Done Awaiting Full Acceptance

Done

Feature 2: Story A

Feature 1: Story C

Feature 1:

Story A

 

Feature 2: Story C

 

Feature 1:

Story B

 

 

On this board, George has finished stories: Feature 1: Story A and Feature 1: Story B. They are in the "Done Awaiting Full Acceptance" column to show that the possibility that these stories may require more work based on the results of the full test. This assumes that George is the best choice to fix any issues, since he has the context. Even if George paired with another person, the item would still appear in this column. If an issue arose, then whichever (or both) of the pair would work on it.

When George is done with Feature 1: Story C, he updates his own board and the Feature 1 board.

Here is Sally's board:

Sally's Board

Input Queue

Working On

Done Awaiting Full Acceptance

Done

Feature 1: Story D

Feature 1: Story C

   

Feature 2: Story C

     

 

Sally and George are both currently working on Feature 1: Story C. Once they have completed this, they start work on the top item in their input queue.

Now suppose it is suddenly discovered that Feature 1: Story E requires both Sally's and George's expertise. The story goes above any stories from Feature 2. Feature 1 has been declared the highest business value priority, so any stories within it go to the top of the queue. Within a feature, stories earlier in the sequence take precedence over stories latter in the order.

Issues

If an individual working on an story in Feature 2 needs help from a specialist, he or she puts their request in the Input Queue for the specialist at the appropriate point.

We know that there are issues that can be solved in a few minutes. If so, it's up to the explicit policies for the team as to how long an unscheduled interruption can last. Although there is an issue with context switching, if it takes one minute for a specialist to help unblock a Feature 2 story, then it seems appropriate to do that. If it takes a long time (long depends on your viewpoint and context – an hour to a week), then the issue should be scheduled. If not, the highest priority feature may have a long delay in completion.

Using this technique, you will be able to schedule specialist resources to ensure minimum delay for the highest priority items. When a potential interruption occurs that is not on the board, the specialist can point to the board and say "Is what you want more important than what is already in the queue or being worked on?" If the answer is yes, then the new item's priority has been implicitly defined. The prioritization should be agreed to by the same people who did the original prioritization of features.

What if there is no feature prioritization? Suppose Sally is working on Feature 1: Story D and Sam is working on Feature 2: Story A. Sally finishes her work. The whole of Feature 1 is now tested and an issue discovered. Without prioritization, the issue goes to the bottom of George's Input Queue. He may not get around to working on it for a few or several days. Feature 1 completion is delayed. This situation also applies if there is no story sequencing.

Expansion

The same sequencing can be applied higher up to containers of features (e.g. projects) and breakdowns of stories (e.g. sub-stories and tasks). An overall board's input queue would contain prioritized projects. Each project could be prioritized as a whole (e.g. all of Project Alpha's features are more important than Project Beta's features). Alternatively, the individual features could be prioritized (Features 1 and 2 of Project Alpha are more important than Feature 1 of Project Beta).

On the other side, the lowest level input queue could contain tasks. The tasks would be sequenced in the same order of the stories. Thus tasks from Story A would be placed in the Input Queue before tasks from Story B.

Sometimes individuals or groups who are not specialists are assigned to multiple projects or features (not ideal, but done for various reasons). Individual Kanban boards can work for every individual or group, even if they are not a shared resource. These boards work about the same way as the specialist boards. They make transparent the work each individual or group is performing. Additional items can be added to the Input Queue by people with appropriate responsibilities.

Summary

With shared resources and multiple features competing for these shared resources, specialist Kanban boards, clear prioritization and sequencing can help deliver the most important items with the least delay.

 

Author: 

Share this:

About the author | Ken Pugh

Ken Pugh is a fellow consultant with Net Objectives (www.netobjectives.com). He helps companies transform into lean-agility through training and coaching. His particular interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly. He also trains, mentors, and testifies on technology topics ranging from object-oriented design to Linux/Unix. He has written several programming books, including the 2006 Jolt Award winner, Prefactoring. His latest books are Lean-Agile Acceptance Test Driven Development: Better Software Through Collaboration. and Essential Skills For The Agile Developer. He has helped clients from London to Boston to Sydney to Beijing to Hyderabad. When not computing, he enjoys snowboarding, windsurfing, biking, and hiking the Appalachian Trail.



        

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean-Agile, Kanban, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile