Monday, January 21, 2013

Another Waterfall Disaster: Steve Denning for Forbes

Reconciling Innovation With Control: The Air Force's $1.3 Billion Lesson In Agile
What are we to make of the news that the Air Force recently canceled a six-year-old software modernization effort that had consumed $1.3 billion and produced nothing of value? Note, that’s $1.3 billion, not $1.3 million. And it’s not that the project produced less benefit than expected. It produced absolutely no benefits at all. The whole project has been canned.
The fiasco is described in the New York Times in an article by Randall Stross which notes that the Air Force’s effort began the project in 2006. It was “supposed to manage logistics using software from Oracle [ORCL].”
The Air Force awarded the $628 million contract to the Computer SciencesCorporation [CSC] to serve as lead system integrator; its job would be to “configure, deploy and conduct training and change management activities” before the launch.
The project had been “restructured” a number of times. When the Air Force realized that it would cost still another $1 billion just to achieve one-quarter of the capabilities originally planned that wouldn’t meet even minimal requirements—and that even then the system would not be ready before 2020—it gave up on the project entirely.

Scrum and Lean: Building Cars

As we prepare for the joint Joe Justice/WikiSpeed Certified Scrum training in Redmond on 4-5 February, I'm reviewing the connection between Scrum and Lean.

We continue to meet with key staff of the Lean Enterprise Institute to discuss opportunities to work together. John Shook, LEI CEO, started the first Toyota plant in the United States. He and Steve Bell gave me the best book on Lean Product and Process Development and we agree that Takeuchi and Nonaka were looking at lean product development teams when they coined the term Scrum.

So it is interesting to look at the first lean product development team started by Taiichi Ohno, the inventor of the Toyota Product System. In his book, The Machine That Changed the World, Professor Womack tells the story:

Ohno, who visited Detroit repeatedly just after the war, thought this whole system was rife with muda, the Japanese term for waste than encompasses wasted effort, materials, and time. he reasoned that none of the specialists beyond the assembly worker was actually adding any value to the car. What's more, Ohno thought that assembly workers could probably do most of the functions of the specialists and do them much better because of their direct acquaintance with conditions of the line...

Back at Toyota City, Ohno began to experiment. The first step was to group workers into teams with a team leader rather than a foreman. The teams were given a set of assembly steps, their piece of the line, and told to work together on how best to perform the necessary operations. The team leader would do assembly tasks as well as coordinate the team, and , in particular, would fill in for any absent worker--concepts unheard of in mass -production plants.

Ohn next gave the team the job of housekeeping, minor tool repair, and quality-checking. Finally, as the last step, after the teams were running smoothly, he set time aside periodically for the team to suggest ways collectively to improve the process... This continuous, incremental improvement process, kaizen in Japanese, took place in collaboration with the industrial engineers, who still existed but in much smaller numbers.

Similar Scrum teams are used by Joe Justice for weekly builds of cars. It is clear that we have not only taken Scrum from the Japanese, but by testing it in thousands of software teams have added incremental value with the concept of weekly sprints, pair programming, test driven development, and other practices that allow production of new car prototypes faster than Toyota with globally distributed volunteer teams. In a couple of weeks we will watch the weekly car assembly at WikiSpeed in Redmond.

Saturday, January 19, 2013

WIKISPEED, Scrum Inc, and Solutions IQ Team Up

Here at Scrum Inc. we are really excited about this new class we're doing with Joe Justice on taking Scrum beyond just software.

Dear Agilistas,

Are you enjoying what Scrum Project Management is doing for your software delivery teams? How about sharing some of that awesome with your sales, marketing, and Public Relations staff! Your HR group! Your legal and finance teams! Especially hardware development and manufacturing managers!

Learn all about how the entire company can achieve 5-10x velocities with Jeff Sutherland, the co-creator of Scrum, and Joe Justice, the founder of Team WIKISPEED. February 4th, 5th, and 6th in Redmond, WA!

Perfect for portfolio managers, managers, and members of the high performing team we will launch with you February 6th! Jeff and Joe work with manufacturing, food service, merger and acquisition groups, legal teams, design groups, software delivery and testing groups, health care and government groups. 

Jeff Sutherland is the co-creator of Scrum, the project management methods that now dominate fast-moving software companies. Joe Justice's Team WIKISPEED used Scrum to develop a 100 mpg car in just 3 months and now delivers social good initiatives world-wide.

Learn all about how it works on February 4th and 5th, then Launch your new high performing team with us February 6th!

Joe Justice and Jeff Sutherland
Scrum Inc and SolutionsIQ

is built by a distributed team of engineers, researchers, enthusiasts, and passionate supporters. We aim to deliver a mass-production, ultra-efficient, Comfortable Commuter Car, the C3. To finance the development of that car, we are looking for ten lucky homes for clones of our X Prize race car. These ultra-efficient, safe, durable cars are delivered with our Roadster aeroshell body module for stunning looks along with stunning fuel efficiency. These cars are not for everyone. They are road legal, but comfort and convenience stop there. Developed for the ultimate in speed and efficiency, they skip every amenity except an iPhone dock in the dash panel. They do not have a lockable trunk, roof, or cup holders. Step over the side crush structures and fixed door panels then sit down inside like a pure race car for the ultimate in light-weight and simplicity. Help us organically finance our ultra-efficient mass-production vehicles by bringing home one of our ten prototypes, and make the world a better place for everyone who follows.

Sunday, January 13, 2013

Richard Hackman and Scrum

A guest post from Jens Meydam (@jmeydam) on the death of Richard Hackman. 

A few days ago, on January 8, a man passed away who may be considered one of the patron saints of Scrum, even though he had never heard of Scrum and few in the Scrum community know his name.

Richard Hackman
Richard Hackman was quite simply the most eminent and influential scholar of teamwork. Where others were content to publish plausible-sounding ideas and anecdotes, Hackman, whose first degree was in mathematics, conducted rigorous research for what seems like decades before writing his masterpiece, Leading Teams.

As one of his former students remembers:

"He took his task very seriously and he showed us all how important it was to be both rigorous and practical in the pursuit of knowledge that could affect how well groups perform and how they can uplift people's lives."

I first came across his name in a tweet by Bas Vodde, who seemed enthusiastic about Hackman's work. Since then I have read Leading Teams twice, as well as two sequels, one on senior management teams and one on intelligence teams (Hackman was advisor to the CIA). There is so much to learn from his work.

After the jump, I will just quote a few passages from Leading Teams. I encourage you to read the book; a few quotes are in no way a substitute. If you are familiar with Scrum you may agree that the parallels between how Hackman describes the role of team leaders and how we see the Scrum Master and the Product Owner role are striking. Hackman can also help us understand some of the deeper benefits of working in sprints. I have described this book to others as "Scrum, the Missing Manual". While Scrum is not the only way to create the enabling conditions Hackman writes about, it is certainly one way. I regret that I didn't try to get in touch with him. Now, sadly, it is too late.

Tuesday, January 08, 2013

Requirements for Product Owner: Common Pitfalls

Recently during a leadership workshop an engineering manager complained that his Scrum teams deliver the product and that it was not what the customer wanted. He thought this was a problem with Scrum.

I pointed out that the Product Owner determines what is DONE at the end of a sprint and if it is not what the customer wants, the Product Owner should declare it NOT DONE. I suggested he might have a Product Owner problem. Scrum doesn't magically make your problems go away, it makes them clear and you know immediately where to look for responsibility.

The engineering manager confessed that they had underinvested in the Product Owner function. The Product Owners are not fully dedicated and are not doing the job. It only took about 5 seconds to diagnose the problems with his Scrum.

The majority of Scrum teams worldwide (and I survey multiple times every month in multiple countries) do not have good Product Backlog Items entering the sprint. In addition to cutting velocity at least in half (a minimum loss of about $75K per month per team), it leads to the customer not getting what they want. At OpenView Venture Partners we think we can hire a new manager and a new Product Owner for $75K a month, but I digress ...

An adequate Product Owner needs to meet these minimal requirements:

1. Knowledgeability
2. Availability
3. Decidability
4. Accountability


If the Product Owner does not know the market, the customer, the product, and the competition, the team will lose confidence in their leadership. This will lead to slow down and disagreement over priorities. It is not possible for a new Product Owner to know everything. They need help from management and the team to ramp up their capability. This needs to be built into their job description.


The best Chief Product Owner is often a business leader (like Steve Jobs). The Product Owner spends half the time working with the customer and the market and the other half working closely with the team. If the business leader has to be part-time, she or he needs a full-time Product Owner to do the day-to-day work. Failing to do this will lead to problems like the one described above. The customer will not like the result, and more work will need to be done. It is cheaper to hire a Product Owner than deal with the damage later.


The Product Owner owns the final decision on the ordering of the Product Backlog. Failure to do this will cause priority conflicts and cut team velocity in half. It is cheaper to hire a new Product Owner than to let this happen.

This means the Product Owner needs the confidence of the stakeholders (and the team). If they don't have it, they can't do the job.


The Product Owner owns the business plan and is accountable for driving revenue (or whatever value your organization is producing). It is not helpful for a hyperproductive team to deliver many features if the revenue per point is minimal. The Product Owner should be measured on revenue per point and how much the revenue per point is increasing over time.

The Scrum Inc. Product Owner regularly monitors metrics like revenue per point to better order the Product Backlog.

Very few Product Owners know their revenue per point. For this reason, at Scrum Inc. we have developed a management dashboard that shows sprint to sprint revenue per point. Just as the Scrum Master needs to know velocity sprint to sprint, the Product Owner needs to know revenue sprint to sprint. We will hold a webinar on this topic in February with a demo of our management dashboard.

Meanwhile, I strongly encourage all organizations with Product Owner issues to send their key people to our Certified Product Owner workshops in Boston at our venture group headquarters. At a minimum you might save $75K per team per month. The upside revenue would likely be much more than that.

This page has been translated to Serbo-Croatian by Anja Skrba