Thursday, October 25, 2012

Getting Lean with Scrum


By Christine Hegarty

In working for the creator of Scrum, I have gained an appreciation for the influence of Lean thinking on the development of Scrum principles.  The concepts of continuous improvement, eliminating waste, limiting work in progress, etc. are intrinsic to culture at Scrum Inc., but at times I forget that the influence of Lean, specifically on the Sprint Retrospective, is not entirely intuitive. 

The purpose of the Retrospective is to a) inspect how the Sprint went, b) identify and order what went well and what didn’t and c) create a plan for implementing improvements.  The vision of this meeting was clearly influenced by a core Lean principle: continuous improvement.  However, like most aspects of Scrum, the process for implementing these improvements is not defined, and thus, sometimes is difficult for teams to conceptionalize.  And, once teams are up to speed on the Scrum process, fighting the urge to become comfortable becomes a challenge.  Asking questions and looking at things differently is hard and uncomfortable, especially when an organization or team feels that everything is going well.


One particular example comes to mind from a Capability Assessment we recently led at First Line Software in St. Petersburg, Russia.  From top to bottom, First Line has proven robust Scrum competency.  They have maintained a culture that embraces Scrum best practices, supports high quality development and fosters collaboration with clients to relevant increments each Sprint, a practice that earned them a Scrum Capability Rating this September.  They have proven themselves to be mature, disciplined Scrum teams.  In our experience, teams at this level fall into a rhythm of addressing the more topical impediments since they aren’t dealing with a major pain point.  The First Line teams were no different.

Through the Assessment, the Scrum Master recognized an opportunity to incorporate continuous improvement.  I worked with her to reinvigorate the Retrospective by using the Happiness Metric and the Lean concept of kaizen (Japanese for “improvement”).   Introducing this somewhat different angle helped her realize the power of putting a process around their Retrospective.

Regular readers of the blog will recall previous posts on the Happiness Metric.  From a 1-5 rating by each team member of “happiness” about the previous sprint and discussion about likes and dislikes, the team agrees on a single kaizen to be added to the Sprint backlog as a task, with a clear goal and criteria for “done.”  During the week, the team keeps focused on the agreed improvement while burning down backlog.

As a result, we saw that by applying this process and Lean principal, the team was able to facilitate a more rigorous retrospective, while connecting the impediment backlog with the Sprint Backlog.  The combination brings process improvement to the forefront, sharpening the focus on increased productivity and velocity.  Here’s to finding another Scrum team, ready to incorporate the Lean edge.

9 comments:

Neil Killick said...

The statement "sharpening the focus on increased productivity and velocity" interests me, and I have a couple of questions:

1. What does productivity look like in software development, and how/why would you want to increase it?
2. What leads you to believe that the focus of Scrum is to increase velocity?

Thanks.

Jeff Sutherland said...

Scrum was designed to give programmers a better life while achieving 5-10 times as much production with a corresponding increase in quality. Thus it also satisfies investors goals of producing a better product at 10-20% of the normal cost and time. Scrum is based on Lean Product Development teams observed by Nonaka and Takeuchi. For example, the Prius team needed to deliver twice the gas mileage in a production car in half the time.

Neil Killick said...

Hi Jeff,

I understand Scrum's roots in Lean and the organisational goals that can be achieved using Scrum. But in order to achieve such goals the organisation needs to take a broader approach to removing inefficiencies. Focusing purely on the Scrum team(s) producing more seems counter-productive.

Isn't Scrum more about building the best possible product(s) in a given timeframe? Having business goals like getting better at delivering quality software, being more predictable for the purposes of planning, getting to market more quickly, etc. are noble goals and surely what Scrum is more suited for? Putting the emphasis (i.e. pressure) on teams to increase velocity (which is a bogus measure of productivity) will cause both quality and predictability to suffer. Isn't constant, sustainable pace more important?

I don't see how productivity can be measured in a creative, unpredictable pursuit like software development. "Doing more" is not being more productive, because what does "more" actually mean in the context of iterative/incremental delivery? More story points? Story points are relative estimates of product increments with perhaps unconscious target-massaging involved, so surely not.

Plus what if the wrong thing is being built? Focusing too much on efficiency (over effectiveness) is the downfall of many teams (and no doubt a contributor to the high failure rate of Scrum).

Neil Killick said...

Hi Jeff,

I understand Scrum's roots in Lean and the organisational goals that can be achieved using Scrum. But in order to achieve such goals the organisation needs to take a broader approach to removing inefficiencies. Focusing purely on the Scrum team(s) producing more seems counter-productive.

Isn't Scrum more about building the best possible product(s) in a given timeframe? Having business goals like getting better at delivering quality software, being more predictable for the purposes of planning, getting to market more quickly, etc. are noble goals and surely what Scrum is more suited for? Putting the emphasis (i.e. pressure) on teams to increase velocity (which is a bogus measure of productivity) will cause both quality and predictability to suffer. Isn't constant, sustainable pace more important?

I don't see how productivity can be measured in a creative, unpredictable pursuit like software development. "Doing more" is not being more productive, because what does "more" actually mean in the context of iterative/incremental delivery? More story points? Story points are relative estimates of product increments with perhaps unconscious target-massaging involved, so surely not.

Plus what if the wrong thing is being built? Focusing too much on efficiency (over effectiveness) is the downfall of many teams (and no doubt a contributor to the high failure rate of Scrum).

Jeff Sutherland said...

In Scrum we only increase velocity by removing impediments. This increases quality. In a properly implemented Scrum, quality improvement drives velocity. Are you proposing we reduce quality?

Neil Killick said...

Not at all, I'm not sure how you gleaned that from my comments.

I'm very interested in what you're saying though. There is no mention of "velocity" in the Scrum Guide, and I agree fully with your sentiment about velocity increases. So my question remains - how do teams measure productivity in the context of developing software in order to determine quantitative gains, such as those cited by Nonaka and Takeuichi? With cars and car parts it is far easier (on the production line a spark plug for a Prius is the same as another Prius spark plug, and one Prius is the same as the next).

How do we measure working software in such terms?

Jeff Sutherland said...

The focus on Scrum is to build less, delivery early, and through customer feedback build a great product. Working with our investment group we now have investments in 20 Scrum companies. We focus the initial effort on implementing Scrum properly so the velocity will triple. We then spend 80% of our time working with the product owners to get the right product strategy. These usually forces us to work at the CEO level to clarify the business strategy and market before the product owner can function well. Our view is that slow teams are useless and their quality is terrible. Good Scrum will fix that immediately with three sprints (3-6 weeks). We don't tolerate sloppy Scrum.

Neil Killick said...

Right, so when you say the "velocity triples", what do you mean? How are you measuring velocity? With story point estimations?

This is what I'm trying to get you to answer - what is the measure of productivity/velocity that you are increasing, and how do you know that productivity has genuinely increased instead of, for example, story point inflation?

Jeff Sutherland said...

This is explained in the Hyperproductive Metrics paper that will be published at HICSS in January. It is on this site (click on Jeff's Sutherland's Papers on the right side of this page). It is also on the Agile 2012 site. Velocity is always based on story points. Story point inflation is avoided by proper estimation using good reference stories. For high performing teams, stories are small so inflation becomes very easy to control. A good product owner will scream if she sees inflation so that is the first line of defense.