Tag Archive: multi-tasking


Too Much Work in Process?

credit: Richard Smith via Flickr

Creative Commons  Credit: Richard Smith via Flickr

Does your team’s burndown chart look like one below, where a small number of stories accepted during the first part of the Sprint and then acceptance rate hockey sticks towards the end of the Sprint?  In the graph, you can see that acceptance rate is less than 10 story points (the green bar) for the first 14 days of a 21 days Sprint.  And then it gradually rises to 20 and rockets up in the last 3 days.  This graph  is for a Scrum team that follows a 3-week Sprint duration.

 

Iteration Burndown Chart

Iteration Burndown Chart

 

 

Or represented a different way, here is team’s cumulative flow diagram from the same Sprint.  Note, the team, within first 3 days of a 3-week Sprint, has put 46 out of 66 story points in play?

Cumulative Flow

Cumulative Flow

Does your team see any ill-effects with taking on too much work in process?  Does the testers on the team get squeezed trying to jam through 40-60 hours work effort into the last 1-2  Sprint days?  Are they compelled to make risk-based testing decisions?  Does your team, despite its best intention end up cutting corners by writing crappy code, carrying over defects and accumulating technical debt?

Does your team put in overtime to complete all the in-flight stories during the end of the Sprint?  During your story demonstrations, does your team leave your Product Owner disappointed, because it can’t accomodate simplest changes and force her to write new stories in the backlog to cover minor changes?

If your team activity resembles these charts, or encounters some of these symptoms, it is possible that it is taking on too much work in process (WiP).

 

Little’s Law and Queuing Theory

Let’s do a quick review of queuing theory and something called Little’s Law as formulated by John Little.  Little’s Law is expressed using a simple formula:

L = λW

Here,

L =average number of items in the queuing system,

W = average waiting time in the system for an item, and

λ =average number of items arriving per unit time

 

Sometimes, Little’s Law is also restated as: CT = WIP/TH.

Where, CT = λ = cycle time, for the average time when an item enters a system to the time it exists a system; WIP = L = work in process, the number of items in a queue and TH = W = throughput or the average output of a process.

It follows from this that the size of your queue is directly proportional to your throughput.

So, if you are trying to improve your cycle time, like how fast a story is accepted, then you have two options:

a)     Improve the throughput of your process/system

b)    Decrease the average number of stories you work on simultaneously (the WIP in the equation – the queue)

Typically, throughput is a measure of productivity and may largely depend on a team’s skillset or on the system the team operates in.  To make productivity or structural changes take time.  For example, a team might realize they can get more efficient by putting in place test automation and save time as compared to manual testing.  However, a team may not have anyone on the team with test automation skills.  So, it will need to acquire those skills, which means, a team member will need training, and then learn to implement test automation.  These activities take time.

Or say, your team needs to promote code to the staging environment as a part of your story acceptance criteria.  But, to promote code you need a deployment resource from the release team.  And if this resource is shared between few teams, as is typical, it would mean systemic wait time, till the resoruce is available to complete the task.  You can decrease this wait time by: 1) get a deployment resource dedicated to your team, who can do code promotion; 2) have a team member acquire those skills; or, 3) if you have someone with those skills on the team, lobby for changes to department policy that requires that only a deployment engineer can do deployments to staging environment.  To implement any of these  options will take some time to put in place.

So the best lever a team has, to decrease cycle time, is to decrease the average number of stories they work on at any given time.

 

 Why is Less WiP Better?

Queues are all around us: traffic during morning and evening commute, waiting for a restroom at a ballpark during half-time, a doctor’s office, waiting at a grocery checkout counter, and many more.  In lean terms, queues are considered inventory and inventory represents waste.  And I am sure when impateintly wait in a line, we can attest that it is a waste of time.

With Scrum, you are already working in delivering working software more frequently compared to traditional methods.  So, many Scrum teams may not even care that within the Sprint boundary, there is too much WiP.  Besides, Agile principle only states, “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”.  But, nowhere does it say, reduce your WiP even further.

Or it could also be that teams prefer higher WiP to provide them with that extra impetus to complete their work as the  Sprint-end deadline approaches.  Or a team doesn’t mind putting in extra overtime during the last week or last few days of the Sprint.

But, I suspect many teams and team members want to achieve realistic and sustainable pace in meeting their Sprint goals.  They are motivated in getting constant feedback with their business partners or POa by showing working software, early and often.  And they don’t want to systematically sucuumb to bad quality or crappy code.

As a matter of fact, Rally Software (Disclosure: I am Rally user), which conducted empirical analysis on teams and summarized their findings in The Impact of Agile Quantified (Note the paper is behind an free access wall).  They found that teams that aggressively control WiP, cut their time in process in half.  And those that control their WiP, have 4 times better quality compare to teams with the highest WiP.  So if faster feedback (or faster time to market) or higher quality is desired, it pays to lower your WiP.

But, note that there is an optimal WiP for your team.  If you push your WiP too low, you can lower your productivity.  It was found that teams with very low WiP (0-2 WiP) had lower throughput.  So there is certainly a balance that needs to be struck between too much and too little WiP.

 

Ways to Decrease WiP.

Generally, if your team uses some Agile Management software, they probably have a built in report that can show your team’s Cycle/Lead Time.  Once you know the Cycle/Lead time, you can start setting up targets to decrease the WiP.  So for example, if your team’s cycle time is 10 days, and your Sprint backlog is 10 stories.  Your team might decide to set a target of starting with only 5 stories, get them designed, analyzed, developed and tested.  Review the stories with the PO, get feedback, and get them accepted and move on to next set of stories.  This is the basic concept of Scrumban, melding the Kanban practice of controlling WiP within the Scrum framework.

In order to lower your WiP, each team will have to experiment to see what works best.  Here are some potential things to try:

  • Work with the PO to de-construct features into smaller stories during Backlog Refinement meetings so that they can be potentially completed within a week.
  • Set a team agreement on having only X number of stories in-progress.
  • Set general guidelines on how to “swarm” when team WiP limit is met.  For example, if WiP limits are met, an idle team member could: 1) help take up task on existing WiP story 2) pair up with someone to learn skills of a constraint skillset 3) Refactor code or test automation code 4) Swat down defects, 5) improve autoamted test coverage.  Have team members “swarm” on a few stories, instead of trying to put all work in play.

As you try to limit WiP, even with the above swarming guidelines, you will find that some team members might idle.  And it will feel counter-intutive.  But, you are not trying to achieve optimal efficiency at an individual level, but at a team level.  If you manage to lower WiP, the team will see that it cycle time is improved, quality is better, feedback loops are tighther,  there is less risk in meeting Sprint goals, and potentially a team will acheive more sustainable pace, experience less volatile team velocity.

Reduced to soundbites the lower WiP mantras are:

Don’t WiP it, Ship it.

Stop Starting, Start Finishing.

 

References:

Paper on Little’s Law with few examples:  http://web.mit.edu/sgraves/www/papers/Little’s%20Law-Published.pdf

Poppendieck, Tom and Mary, 2007, Implementing Lean Software Development: From Concept to Cash,  Addison-Wesley Professional.

 

Recently, I was in a leadership training program – Northwest Regional Leadership Forum.  One of my assignments for the class was to facilitate the book Brain Rules by John Medina.  To illustrate one of the concept in the book, I designed a simple exercise:

  1. Team-up 2 people
  2. Have each person connect the dot  on a picture containing 100 or more dots.  Record their activity time.
  3. Have each person do simple addition and subtraction sums (I used a handful of sums using a worksheet generated from a site like this one – Math Worksheets).  Record their activity time.  Add time from step 2.
  4. Second part of exercise, I had one person start another connect the dot worksheet, while simultaneously his partner ask him to do simple math sums.  Record the time.
  5. Compare the combined time (from step 2 and step 3) to the time from step 4.

What do you think the results were? What took longer – the time spent connecting the dots and the math sums, when done serially; or, the time it took  to do them simultaneously?  Before starting the exercise, I asked this question, and almost all my classmates thought, it would be when we multi-task.  After all, we were all managers and we were masters at multi-tasking, right?  Well, it didn’t quite work out that way.  Everyone took more time to complete the exercise when trying to multi-task compared to when they focused on doing each activity serially.  (I should add there was one person, who was an exception – so either he is a freak or he cheated!).

So what’s going on?  John Medina says research show that, we humans cannot multi-task.  What we do instead is task-switch.  So for my classmates, the sequence went something like this: start connecting the dots; got an interruption in asking him to do a math sum; stop connecting the dots; do the sum and then go back to connecting the dots.  What was more interesting is that some people got so distracted that at the end of the exercise, they didn’t have the dots connected properly or made mistakes on their math sums.  And this is precisely what Medina says to expect: “a person who is interrupted takes 50 percent longer to accomplish a task.  Not only that, he or she makes up to 50 percent more errors.”

Similar studies of multi-tasking while driving (especially talking on the cell phone) shows that it impairs a driver to such a degree, that it is almost like driving under the influence.

Mary and Tom Poppendieck in their book Lean Software Development: An Agile Toolkit, list task-switching as one of the sources of waste.  And a very common way, we ask our team members to engage in task-switch by design, is by putting them on more than one agile teams.

What’s more, we also have to battle with constant interruption from phones, emails, IMs, streams of social media, and walk-ins.  How do we manage to get any work done?

So how can we support our teams to minimize distractions?   Well, we can transition them to work on a single agile team.

We can create common space for co-located teams.  So that it allows team members to be available to answer questions, collaborate, to problem solve, or be around to soak in information from the ambient conversations.  And we can create  hotel cubes, which allows people to get away for a while and attend to private matters, and this way, they don’t clutter the team space with unwanted noise.

We can shutoff our collection of communication tools even if it for few hours, when we really have to focus on tasks.  I have seen some team members do this very effectively by putting specific messages on their emails or IMs that they are unavailable during certain time period.

We can cull the lists of in-flight projects and try a no standing meeting day.  Both of these last items are getting tried at my work.  And it will be interesting to see what improvements we will see.

We humans still haven’t evolved to effectively multi-task, unlike hindu goddesses, who have multiple limbs and heads and can slay multiple demons at the same time!

So it is best to heed the advise of a zen master: “When washing dishes, wash dishes!”

 

%d bloggers like this: