Scrum Co-creator Jeff Sutherland on Innovating with Scrum

Last week we welcomed Dr. Jeff Sutherland, a forefather in modern application development methodology and a true visionary in the world of innovation, for a live webinar; Harnessing Your Organization’s Agile Potential. Dr. Sutherland gave an engaging presentation that balanced the broad applications of the Scrum methodology, its history, and the disruptive innovations that have followed. This post is a compilation of excerpts from his presentation.

“This movement in the industry has caused radical changes in the workforce … [Scrum jobs] are close to 10% of the total new job openings in the United States, so Scrum is really taking over the way of working, not only in IT, but it’s starting to spread outside of IT.”

– Dr. Jeff Sutherland, co-creator of Scrum

Happy Development Teams are More Productive Development Teams

“You could say that businesses want to be faster, more agile, deliver things better. But actually, Agile has been effective because developers find it a better way to work. It makes life better for developers. And one way to frame that is that it gives back developers a life; it gives them autonomy to do their work and it creates an environment where you can have happier development teams – and happier development teams are more productive development teams.”

Dr. Sutherland framed his presentation by beginning with the true Why behind Scrum project management. It was refreshing to hear the human connection that he made to speeding up product development. At the end of the day, engineers want to get their projects done faster so that they can spend more time with their families, not necessarily so the company can win more business or be more competitive. Development is a tremendously specialized skill, and it’s easy to see how traditional approaches to development would result in 80-hour work weeks and burned out team members. Even still, it turns out that this way of working stems not from the needs of developers, but from the world of robotics.

Scrum Beginnings in Complex Adaptive Systems Theory

“We began to do a lot of research, and that led us into Japanese manufacturing. We knew how they were operating, so we had some basic ground level ideas on how to work, but I told the team, it’s not going to be enough to do what we’ve been doing. We need to look at what the best teams in the world are doing, and then adopt their practices. We started by looking at 30 years of IBM systems journals. IBM thought the ‘Surgical Team’ was the best way to build software: one brilliant individual cuts every line of code and is surrounded by helpers; language experts, tool experts, documentation people and so forth. But we looked at our biggest customers like Ford Motor Company, who had a thousand IT workers using our tooling, and we didn’t think they had any surgeons, so we couldn’t implement that.

So we kept looking. I had helped iRobot as a startup in their very early days and I learned about how they made these intelligent multi-legged robots work, and how they cause the robot to exhibit goal seeking behavior, and understand how that was based on complex adaptive systems theory. So I thought that whatever we did needed to be based on inspecting and adapting in a complex systems way.”

A core component of Scrum is the feedback mechanism. As we saw during the four-minute Mendix demonstration (check out minute 5 in the recording) , a feedback button in the application allows end users (or any project stakeholders) to send the project team their feedback, idea, or question directly from within the application. This gives project managers the metadata and user commentary they need to accept the feedback and add it to their backlog.

It’s fascinating to learn that this concept came from the way robots sense and move through their environment. To continue the metaphor, that Mendix feedback button is akin to a robot’s sensors, and a feedback ticket makes up the information communicated back to the project team and their application (the robot), from which they develop new features and ‘direct’ the application towards an optimal end result (positive ROI). Applying this cyclical process to application delivery would become the next leap forward for Scrum.

Studying Innovation Processes around the World

“It started us down the road of looking at impossible projects. It led us to Professor Nonaka’s paper in the Harvard Business Review “The New New Product Development Game” and they had looked at best teams all over the world, and they described how they would take senior management teams from Tokyo around the world to see how people were doing projects. They brought the Fuji Xerox management team to NASA, and NASA described their traditional waterfall implementation that was used to build the space shuttle. Many years of analysis, a big document handed off to a design team, many years of design, then handing off another big document to testing and so forth. It was all big documents, many years, hand offs between siloes. Fuji Xerox management said that must be the best practice, so they went back to Japan and tried to implement it. As soon as they did, they had found out there was a 14% success rate.

Now, they had been trained by W. Edwards Demming after WWII to do route-cause analysis of why things were not working, and what they discovered is that the root cause of the failure is big documents handed off between siloed departments. So they banned the big documents, and they insisted that the teams work face-to-face, so they had a slicing style overlapping work with teams working face-to-face all the way through. That shortened the cycle and increased the success rate. But the very best teams – the team that we wanted – Tacheuchi and Nonaka saw at places like Honda, 3M, and later Toyota. These teams that were totally cross-functional were delivering in short iterations, production prototypes and watching that production prototype grow like a plant into a product. Tacheuchi and Nonaka said these teams reminded them of rugby teams, particularly the Scrum formation in rugby, so they called these types of projects “Scrum Project Management.” So we said: “We’re going to implement Scrum Project Management in our tooling and we’re going to train our customers to use Scrum Project Management.”

When we think about application development project success rates, the majority of these projects fail. Dr. Sutherland began his presentation with a slide with two pie charts (a graphic from his latest book, Software in 30 Days) representing success rates of Agile vs. Waterfall projects. Knowing how our project teams and how our customer’s project teams work, it’s incredible to see that only 14% and 42% of Waterfall and Agile projects, respectively, succeed. Dr. Sutherland attributed this to the fact that many teams are still practicing ‘bad Agile’ and advised the audience to be critical and dedicated to the Scrum processes that they’re using.

Knowing that Mendix project success rates are significantly better, a platform that enforces diligent Scrum processes (among other key features like Enterprise Integration and 1-Click deployment) adds value for even the most experienced Scrum team.

The marginal utility of building and maintaining meticulous Scrum processes is significant. Where even ‘bad Agile’ can result in faster project completion, diligent Agile teams are able to truly innovate. As Dr. Sutherland comments on one slide, customer’s used to love Nokia cell phones – until they tried the iPhone. In other words, users often don’t know what they want until they get it. It’s up to a well-trained team to continuously prioritize features that add value to the user.

A Word about Incremental Innovation

“There’s a bunch of myths about innovation. A lot of innovation, even radical innovation, is caused by small steps. That’s the way Toyota builds a new car, in small incremental steps. And the good news if you’re implementing Scrum, is that’s exactly how Scrum works. In fact, Scrum is based on what Tacheuchi and Nonaka saw at Toyota and Honda and other lean companies. Scrum in product development will help you innovate faster, better, and cheaper. There’s some good data from Inc showing the distribution of funding that companies put into innovation; you don’t need to put too much into radical innovations to make significant steps forward. For example, in Silicon Valley, Apple only spends a little over 2% of its revenue in new innovation. That’s not a lot, but they clearly have disrupted the environment.”

Dr. Sutherland’s comparison to Apple adds color to oft-overlooked notion that dollars-spent and business-results-achieved do not have a linear relationship. Throwing dollars at a business problem, just like adding more developers to a lagging project, won’t actually move the project along any faster or generate better results.

In a recent Forbes profile, our CEO, Derek Roos, shared a particular customer success story illustrating this. “He provides the example of a large bank now working with Mendix that had a team of 150 people developing an application and they were struggling to get the development finished over a three year period. The Mendix application tool helped them get back on track in a matter of weeks and reduce inefficiencies in the process.” In this particular instance, hundreds of millions of dollars were burned before the company realized that their process had to be altered. The discouraging part is that this is happening at large enterprises regularly.

This ‘big company disease’ as Rod Willmott, Fast Track Innovation Director at LV= Insurance puts it, can hold back not only innovation, but even basic competitive differentiation. If big companies aren’t able to be agile and continuously generate value, they’ll go extinct – as we’ll see with GM and Nokia Mobile.

Innovation is Essential to Survive in Competitive Markets

“It really is a revolutionary phenomenon. If you don’t innovate, you can wind up like General Motors. In fact, I tried to mention in a paper that General Motors was going to be bankrupt in 20 years. I tried to publish that in 1993, and the publisher made me take the statement about General Motors out of the paper. But it was clear at that time that the way they were operating they couldn’t compete. So they actually went bankrupt in less than 20 years; it only took them 17 years. So pulling out of bankruptcy after being bailed out by the government (after the government changed a lot of the management), they began to innovate. The Volt is a great innovation. If you watch The Revenge of the Electric Cars, you’ll see how the General Motors guys that pushed the Volt into production looked at Tesla. The guys at Silicon Valley put out the Tesla Roadster, the first electric production car, and at General Motors they said ‘Hey you know, we killed our electric car but now there’s a startup in Silicon Valley doing it. We better get back on the road to getting an electric car on the road.’ They were forced to innovate.

Sometimes it’s too late. Nokia was at the top of the pile for regular phones but all of the sudden with the iPhone, it changed the dynamics, and as the smartphone market share increased rapidly and dramatically, Nokia couldn’t keep up. If you read on the web what people are saying about Nokia, in the early days they were very innovative; if somebody had a great idea, a single manager could get it going. By the end of the 1990’s, the management hierarchy was so large and rigid, to get anything done, you had to get signatures from 20 managers. That was the kiss of death, and so Nokia Mobile is gone, and now Microsoft has bought them.

Now what is Microsoft doing? A few months ago Steve Ballmer said ‘we’re reorganizing the whole company.’ Why? ‘We’ve got to be faster, we have to be agile, we have to deliver new product much faster than we’re doing right now.’ They already had 3,000 people, all their development tooling, using Scrum, and they not only cut their bugs from 30,000 to 3,000 and shortened their delivery time. They were actually deploying a new release of software every three weeks coming into this summer. They already had 3,000 people working – the problem was the other 20,000 developers at Microsoft, particularly the windows developers. At an Agile conference last month, a Microsoft leader described how they’re going to convert the rest of the 20,000 developers to Scrum. That’s a big job, but it’s essential for Microsoft to innovate and be competitive in the market.”

It’s remarkable that Microsoft, the company that inspired – if not started – it all, is in a position where the sheer size of their development team is one of their biggest strategic weaknesses. Enterprises that have adopted Agile as more than a development environment – a philosophy – are now leading the pack because they’re able to adapt in unpredictable market environments. In a nutshell, that means they’re able to maintain their capacity to deliver value to their customers. The final excerpt I’ve selected from Dr. Sutherland’s presentation explains the Pareto principle in terms of application delivery projects, wherein roughly 80% of the effects come from 20% of the causes.

Delivering Highest Value Pieces First

“One of the things that we’ve been talking about a lot, is that using Scrum, you really should always deliver early. What we do in Agile is deliver the highest value pieces first, so as a project moves forward the features coming online have less and less value. So a really good strategy is to deliver the product before the curve flat-lines. So then you can deliver a new product with 20% of the features. When you do that, you’ll get a lot of feedback from customers that will cause you to change the features that you thought were going to be implemented that don’t have much value. The customers will come up with new features that add even more value. Then you can get on the next value curve, and a really good product owner can do that and ship three times with the same budget that a traditional project manager can deliver one release.”

This excerpt speaks to the efficiency of diligent Agile teams, and the innovation and differentiation that those teams enable for their companies. By prioritizing features and creating a feedback cycle, an Agile development methodology allows you start building with only high-level requirements, and curb any features deemed unnecessary by end users – those responsible for weaving value from a product, whether it be an automobile or an enterprise application.

Dr. Sutherland’s presentation continues with more interesting concepts like “Scrumming the Scrum” and the problems inherent to traditional organizational structures where hierarchies get in the way of productivity and innovation, like we saw at Nokia Mobile. He ended his presentation by saying the ‘happiness metric’ is the most important factor in enabling hyper-productive teams, a novel idea that positions the true motive for Scrum (and Mendix) very well in my opinion.


Share to Social Media