Tag Archive: coaching


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.

 

Advertisements

Just One More Level

TaeKwonDo Practitioners (© Aashish Vaidya)

As transition goes, shedding the old ways and adopting new ones are fraught with doubt and confusion.  This is true of any large organization transition effort as it is for scaling agile practices across the enterprise.  One of the challenges for enterprise transition community leading this change effort is figuring out how to move people with different understanding and different needs from novices to experts.

Many times, a model or a construct of learning helps us classify how to approach people with different levels of understanding and teach them new techniques.  Alistair Cockburn introduced the concept of Shu-Ha-Ri to software development.  Shu-Ha-Ri is borrowed from the martial art practice of Aikido.

Here is how Martin Fowler describes it:

Shu-Ha-Ri is a way of thinking about how you learn a technique. The name comes from Aikido, and Alistair Cockburn introduced it as a way of thinking about learning techniques and methodologies for software development.

The idea is that a person passes through three stages of gaining knowledge:

  • Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
  • Ha: At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
  • Ri: Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

One of the common refrain you hear from many people who have learned some basics about agile methodologies is to say, ” see we understand the agile practices, but how are we going to do this differently here?”  The questioners, here might presuppose that certain practices just won’t work in their environments and want to start tailoring things right out the gate.  Especially, when they have learned that agile is all about adaptability and change.  So there is this predisposition to jump to the Ri stage.  But, agile practices are supposed to be an experiential process.  You do things, reflect on what worked and what didn’t , in short you inspect and then you adapt.

But, many balk at directive practices in the Shu state as it run contrary to the agile manifesto, itself.  Here is Rachel Davies, co-author of Agile Coaching who takes on other agilists, in a post  called Shu-Ha-Ri Considered Harmful:

I’m uncomfortable with approaches that force students to follow agile practices without questioning. These approaches seem to violate the first value of the Agile Manifesto “Individuals and interactions over processes and tools.” I question whether introducing agile software development techniques to people is anything like martial arts training. Software development is knowledge work and our aim is to build a team of reflective practitioners. To do this we need to engage with how people think about their work. Are techniques from physical arts that build muscle-memory really applicable here?

For me, agile Boot Camps and Shock Therapy approaches lack basic respect for the team’s unique context and the experience of people on the team. Agile software development is a much looser discipline than a martial art like Aikido. Organizational culture and nature of the product being built are major factors in what agile techniques the team will benefit from most. If we establish a sensei-novice model, we’re not fostering the independent thinking and reflection that will take the team beyond the Shu level.

To some extend this is a valid argument.  You have to respect the individuality of the team members and allow them to question the practices they are supposed to be following.  And invariably boot camps and shock therapy approaches will only have an ephemeral effect like a motivational speech would.  You are pumped up for a while and get a boost of energy, but the sugar high wears off quickly.

But at another level, this is a very shallow read of martial arts and the sensei-novice model.  Even cursory look at history of martial arts would suggest that they are not merely about physical activity, but means to develop deeper connection to moral and spiritual dimensions.  Just as you wouldn’t confuse the practice of yoga to be only about physical well-being.  That is just an aspect called hatha yoga , but in larger context yoga has much more to do with “knowledge work” than building simple muscle memory.  Albeit, the knowledge is different, not software development variety.

The issue isn’t necessarily with the Shu-Ha-Ri construct, but how it might be used within the context, and it is more about its understanding and its implementation.  Further on in the post, Davies calls out the real peril:

Installing a basic set of agile practices by force can be done quickly so the organization starts getting benefits from new ways of working faster. Teams are superficially at the Shu level in the space of a few weeks. Often, the management team considers the agile rollout is now complete. It’s assumed that teams will continue to apply what they’ve learned. But without any experts around to enforce agile practice, pretty soon a team falls back to their old ways or sometimes worse carries on with agile practices that don’t make sense for their project.

I was pleased to see “cargo-cult agile” called out in the new book “Practices for Scaling Lean & Agile Development” by Craig Larman and Bas Vodde. They say “Avoid forcing–When coaching we encourage: volunteering; do not force any agile or lean approach onto people; people should be left the choice to think and experiment…with concentrated long-term, high quality support. The best, the most sticky adoptions we have seen had this approach.”

In a large organization, there is rare chance that you will encounter people who do not fall into all three categories of learning: the complete novice, who just wants to be told what should he do next; the intermediate, who knows agile practices well enough to start digging into deeper underlying theory and principles; and experts, who are adept at reading the context and tailoring their own practices to continually achieve business goals.  For enterprise transition community leading adoption of agile in their enterprise, the goal is obviously to encourage people to think critically, experiment and continuously learn, and deftly deal with people at all 3 levels.  Anders Ericsson, a cognitive psychologist, who developed the popular “ten thousand hours” theory of mastery has a second prerequisite for expertise – “the notion of deliberate practice, which describes the constant sense of self-evaluation and a consistent focus on one’s weaknesses rather than playing on one’s strengths (ref Maria Popova’s blog post).  This notion is something the enterprise transition community and agile coaches need to be aware of, and one which our software brethren who design video games understand real well:

[The “zone of proximal development” is] the idea that learning works best when the student tackles something that is just beyond his or her current reach, neither too hard nor too easy. In classroom situations, for example, one team of researchers estimated that its’ best to arrange things so that children succeed roughly 80 percent of the time; more than that, and kids tend to get bored; less, and they tend to get frustrated. The same is surely true of adults, too, which is why video game manufacturers have been known to invest millions in play testing to make sure that the level of challenge always lies in that sweet spot of neither too easy nor too hard.”

The challenge, then is to figure out a mix of practices that you know the teams will be able to take on, and add that 20% “stretch” practices, which allow the teams to flex and get to another “level”.  And hopefully soon, they will internalize what gamers who are hooked – they beg for that 5 extra minute to complete one more level!

Rachel Davies continues:

Learning new ways of working takes time.  As Ron Jeffries once said “They’re called practices for a reason.  You have to have done them. Practice makes perfect.” If you base an agile adoption on Shu-Ha-Ri model, the trick is to remember the goal is beyond the first-level. Your teams need more than training. Allow plenty of time and on-going coaching support for teams to get them into the Ha phase and beyond.

The constant care and feeding of agile teams will be needed at least till the organization moves through the Ha stage.  After all, you come across many agile teams, who have practiced agile for years, but are stunted in their growth.  These teams are upper bound to their organization’s proficiency in new techniques and inextricably linked to its culture, its inertia and change aversion, which doesn’t allow continuous improvements to take place.  So then the Shu-Ha-Ri model can still be useful model, provided that the community understands that you have to look beyond the rollout of initial agile training and project kickoffs.

PS: A parting note, though this was much before my time, if you want to see Ri practitioners in action, then watch the video of these two cats, who delivered a 90% improvised piece, but still based on an underlying musical framework.  They are still grounded in the principles and theory of their craft, but their uniquely tailored performance fits the context, and with their virtuosity, they transcend the rules to create a masterpiece – in essence, they make their own rules.

%d bloggers like this: