Tuesday, February 28, 2012

Force Yourself To Be Better: Strengthen Your Sprint Retrospective

Here at Scrum Inc. we've been thinking a lot about two things: impediments and the Sprint Retrospective. These are really where the rubber meets the road in terms of improving productivity. We'll have a later post on impediments, but I wanted to share this excerpt from Jeff's and Ken Schwaber's forthcoming book "Software in 30 Days," which comes out May 1st. We emailed it around our team yesterday after our retrospective just didn't feel strong enough. It is a good reminder that the Sprint Retrospective can be one of the more difficult things to do in Scrum, but also one of the most powerful.

Every member of the Scrum team strives to improve, Sprint by Sprint. The Sprint Retrospective is where the improvements are formulated. This meeting should be a natural break between Sprints, the Sprint Retrospective is when the Scrum team sits back, reviews what happened during the last prior Sprint, and formulates ways to improve their work and the way the work is conducted. The discussion might include:

  • Whether or not the team members worked together well or not and why.
  • Whether the team did more or less than it forecast and why.
  • Whether the team has all the skills and facilities it needs to do the job.
  • Whether or not the developers understood the requirements and why.
  • Whether the team was able to complete the Sprint in line with the requirements, and, if not, why not?
  • What could be improved or dropped in the next increment of functionality.

Next, the team identifies several things to do differently in the upcoming Sprint that will increase creativity, effectiveness, and productivity. In general, Scrum Teams continually improve. This is the Scrum Team’s chance to make its work and life better. New requirements often arise during the Sprint; new opportunities and challenges also arise. Often, just seeing the increment of functionality evokes new ideas.

Friday, February 24, 2012

The Dangers of Not Being Done, Or Ready For That Matter

On March 8, Jeff will be giving a webinar hosted by SmartBear software. As we put together the presentation, one of the re-current themes of good Scrum came up. Getting stories ready, and getting things done. We've also been working on a new book we're calling "The Scrum Handbook: Everything You Need To Know To Get Started With Scrum," and we thought we'd share a bit of Chapter 4 that focuses on being ready, and getting to done. 
Ready, Ready to Done, Done

I want to re-iterate is the importance of being ready and getting to done. When stories are developed and groomed they need to be ready to implement before the Sprint begins. The Product Owner should work with the team ahead of time to make sure that the stories are ready to be implemented by the team. They should be clear, concise, and most importantly actionable. A good Product Owner should have enough stories in that state to fill up the next two sprints. Both the Team and the Product Owner should spend 5-10% of their time in preparing stories for future Sprints.

Here’s what happens if stories aren’t ready. The Team is estimating and forecasting that they can finish vague and incomplete stories. They waste time and energy trying to get clarity from the Product Owner on exactly what the story means. People get frustrated and annoyed and run around in circles rather than getting down to work. Or that one vague story actually turns out to be five real stories once the work is actually begun. Or they work on the wrong thing, or the right thing in the wrong way, forcing the work to be re-done. The stories at the top of the ordered Product Backlog, the stories the Team will be pulling into the next Sprint, have to be ready. Some companies actually require a detailed checklist to determine whether a story is “ready ready” not just kind of ready, or sort of ready. Simply getting your stories ready will have immediate, dramatic impact on the Team’s productivity. But notice, while the Product Owner is responsible for putting the features and stories in the backlog, the Team must work with the Product Owner to help him or her to get the stories into actionable shape. Because only then will the Team be able to estimate how much work any one story will take, and how many stories they can take into a Sprint.

The Dangers of Not Being Done

And that leads me to what done is. I wrote extensively in the last chapter about the importance of a definition of done. I want to re-emphasize it here. If some people think the work is done at the end of the Sprint, but it really isn’t done, people are going to have to go back and re-do that work. We know that if you have to do the re-work it will take you at least twice as long to do it, and we’ve seen it take as much as twenty-four times as long. This type of waste is called technical debt in the software business. It’s the stuff that isn’t done that has to be done before you can ship your product. If you don’t get it done in the first place, when you were working on it to begin with, it will pile up and pile up, until there is no way the team can get that amount of work done before the planned release date. Managers force people to go on death marches, the quality of the software slips, people get sick and depressed from the pressure, the date slips, the product that is eventually released is bad, and the customers are irate. This leads to the company failing and you losing your job, your children going hungry and a destructive spiral into the darkest depths of the human condition. Don’t do it, get stuff done.
Remember Jeff's latest book, "The Power of Scrum," is available in hardcover and electronically at Amazon.com. 

Tuesday, February 14, 2012

The Maxwell Curve: Getting more production by working less!

Recently I was coaching teams at OpenView Venture Partners and Scott Maxwell, the founding partner, jumped up and said, “Jeff, I want to show you the Maxwell Curve! Here is what we have learned by running Scrum internally with teams of venture capitalists making investments.”

“As venture capitalists we used to want people to work harder and harder to get more productivity, certainly more than 40 hours a week. We would push them and push them until they started to burn out, get demoralized, and threaten to quit.”

“Now it is different with Scrum. In order to double our productivity we need to work less, certainly no more than 40 hours a week. Scrum is intense and you cannot work extra hours at that pace without losing productivity.”

The VCs proved to themselves that sustainable pace works. The maximum productivity point is no more than 40 hours a week with Scrum.

The head of OpenView Labs that supports our investment portfolio companies recently told me he was concerned. Productivity had stayed about the same when they cut their 60 hour weeks to 40 hour weeks. He felt guilty they hadn’t doubled productivity although he was happy with a major improvement in lifestyle for him and his team.

He asked me to do a retrospective with his team to see what they could do to improve. I found out that the number of story points was up 20% by moving the work week to a sustainable pace. However, 25-35% of the stories they used to work on were eliminated by prioritizing the Scrum Product Backlog (they were considered “junk” stories). This meant that they used to have to do about 160 story points to achieve the 120 story points per week they do today.

So their velocity is 160% higher by working a shorter work week. The big question for them is, “Would velocity increase if they worked less?”

Friday, February 10, 2012

Scrum Assessment Checklist

Several people have asked me for the Scrum Checklist we have used for years, created by Henrik Kniberg at Crisp in Stockholm. The earlier version was a mindmap. The current version is a checklist.

I've used it for assessment in OpenView Venture Partners portfolio companies by asking teams to evaluate themselves on each item on a scale of 1 to 10. I've found that our teams are very honest about their current capabilities and the results very useful.

We will be talking about this at the Certified ScrumMaster course in Los Angeles.

Friday, February 03, 2012

Release Duration and Enterprise Agility

You ever wonder why your cellphone Apps seem like they have a new version every day or two? Dan Greening doesn't have to wonder, he knows why, they make better products, faster. - jj

Short release duration—the time from starting development on a feature set until it is tested for value, for example when customers pay for an upgrade—is an implied goal of agile methods and lean product management. Short release durations help companies test market theories to maximize profit, identify and mitigate deployment and usability problems, exercise the entire value chain of internal processes, and diagnose accumulating technical debt.

Attempting to reduce release duration may help drive agile behavior through a company. Shorter release durations motivate automated testing, high-availability architectures and streamlined configuration and deployment.

As an added bonus, release duration can be easy to compute: Finance departments often collect relevant data to satisfy capitalization and depreciation rules.
Citrix Online release duration history

The Importance of the Product Owner

Scrum Inc.'s Christine Hegarty wrote this today, just before she went on vacation, of course, so I'm posting it for her - jj

Here at Scrum Inc. we've been thinking a lot about the role of Product Owner recently. It's something that we see a lot of companies struggle with. It’s common knowledge in the Scrum world that a good Product Owner will increase revenue by keeping the backlog ordered so that we are producing the higher value sooner.  But just how they accomplish that isn't always clear. So we decided to offer the definitive Product Owner classes to help educate Product Owners on how they can increase business value and revenue. I've been working with Catherine Louis, CST, to launch our first Boston-area CSPO this month. At the beginning of March, Jeff will be teaching the Product Owner course he has developed in Los Angeles. 

In building the class, Catherine and I have spent a lot of time discussing the importance of the role to a great Scrum implementation. The following passages reflect some of our conversations about the role of the Product Owner and I thought they would be interesting for the community to talk about.
Q:  What is it that makes the Product Owner (PO) role particularly challenging?
A:  The PO is the person who can answer this question: "Is this the right thing to do for the customer?"  That's a tough job!  The PO is someone who is market facing: he's able to craft and relay a vision. The PO is someone very close to the customer; the PO is the owner of a Product Backlog and focused on bringing value (and "delight!") back to the customer. He is also responsible for keeping a Product Backlog ordered such that the items at the top of the backlog are sized appropriately for the team to begin working on, and are ready to be taken in for the first Sprint.
This is a role that can't be done alone: the PO is considered part of the team, and may need to have many stakeholders assisting in ordering the backlog, making sure we're taking into consideration the Pareto factor: i.e., the top 20% of the backlog should contain the highest value.

Q:  What are some of the key pitfalls?
A:  Typically we meet new POs moving from a culture of traditional batch/phased development, dealing with larger and specialized teams, with a goal of upfront perfection and "requirements sign-off".

Thursday, February 02, 2012

The Power of Scrum

The Power of Scrum

Please read before ScrumMaster and Product Owner courses in Los Angeles and Boston in February.

Book Description

The Power of Scrum tells the inspiring story of Mark Resting, CTO of a software company struggling with a major client and a project with more problems than solutions and a marriage in crisis. But, when he meets Jerry, a West-coast expert in Scrum, light at the end of the tunnel begins to appear, Mark begins to reluctantly hope things will work out. The road is bumpy, but Jerry skillfully brings Mark’s developers from a world of project crisis into a revolutionary approach that can save the day. Authors Jeff Sutherland, Rini van Solinger, and Eelco Rustenburg have written a fictional narrative that masterfully weaves a compelling human story around the teaching moments of a software, project management how-to, and in the process tell an engaging story of personal growth and triumph, while demonstrating the power of a revolutionary and mission-critical approach to project management. The Power of Scrum is a must read for project managers, software developers, and product developers, as well as for anyone who loves a great story well told. More ...