Why Scrum was the original Model-T of Agile

This is the first in a series of articles:

1. Why Scrum was the original Model-T of Agile
2. Why Scrum’s success caused the challenges we now see with it
3. What’s been learned in the 3 decades since the creation of Scrum
4. Introducing Amplio Scrum
5. Introducing the Amplio Scrum Coach – going beyond the Scrum Master

The challenges rampant in the 90s

At the time, developers were burdened with excessive processes and were not organized into true teams. Rather, development was organized into projects with teams being formed around them.

A project manager would do some analysis with the help of a business analyst and create the requirements for what was to be done. Then a “team” would be formed to work off the requirements. Once the team was done a QA person would be brought in to see how the team did. Often, the team would go off to work on another project.

This classic waterfall approach is fraught with risk, waste, and multi-tasking.

These four responsibilities – identifying the requirements, building the functionality, validating the functionality, and managing the project – were done by different people – each with multiple projects going on

There was little conversation and much confusion.

Chaos reigned.

The main problems were:

• No continuity of the people working together
• Lack of understanding of what needed to be built
• Errors were discovered late, and by that time, the people who needed to fix them were off to another project
• The lack of a cross-functional team created a lot of confusion of what was needed as well as how it had been attempted to be created

Sometimes, teams would be organized as cross-functional teams by chance. These would typically be three times more effective than the ones I described. But the lack of understanding how development worked meant that no one noticed.

Then Scrum came along. It was a simple idea.

Create a team which has all of the skills required to create value. You’d need:

• A product owner who understood what was needed to be created
• A development team composed of both the skills to create this value as well as to validate it. There’d be no differentiation of developer Vs tester because the focus was on value – not on the steps to the value
• A Scrum Master could help the team with their challenges as well as be the liaison to management to remove impediments being caused by issues outside of the team.
• Work in short increments (30 days or less then was short) to both ensure you’re working on the right value in the right way and to deliver value quickly.?

The beauty of Scrum is its simplicity. People could learn it quickly – a good Scrum Master could guide them in the iterative steps required:

• Sprint plan based on a goal for the next sprint
• Daily Scrums to discuss challenges and pivot as needed
• End of sprint demos and retrospectives

Having well-defined, cross-functional teams that could self-manage meant those doing the work decided how to do the work. Having sprints enabled people outside of the team to coordinate with the team at regular intervals.

The results were spectacular. Jeff Sutherland, the initial creator of Scrum, talked about 30 times of improvement – which was no exaggeration.

Just organizing into cross-functional teams creates at least a 3 times improvement. Doing the work in the disciplined way Scrum suggests, empirically validating what you’ve done, eliminates a lot of waste and creates another 3 times improvement. Then, if you use good coding and design methods as suggested, you get even another 3 times. 3x3x3 is 27 – close enough to 30 to validate Jeff’s assertion.

There were only a few requirements for Scrum to work:

1. The work being done needed to be planned ahead in short cycles (30 days or less), with the team able to focus on the plan.
2. A cross-functional team needed to be created and somewhat stable so that people knew how to work together.
3. The team needed to have the skills and drive to create the required value
4. Management needed to let the team work in their own way without a lot of interruptions
5. The Scrum team had to continuously validate what they were doing and adjust as necessary.

Why Scrum worked

There are three main problems that afflict product development:

1. Building items of little value. It had been demonstrated by several studies that over 80% of the features created at the time were not being used. This was due to overplanning and presuming what was needed was known upfront.
2. There were delays in the flow of work which created a significant amount of waste. This was particularly due to the slow discovery of errors. Mistakes were made but people kept working on old, incorrect, understanding.
3. Multi-tasking was lowering everyone’s efficiency.

Scrum eliminated much of this waste. These were lowered by planning small increments with a focus on value, short development cycles to get feedback and avoiding multi-tasking by focusing on the completion of stories.

When looked through the eyes of Lean and value stream analysis we can see that Scrum was a partial implementation of these useful concepts.

Scrum’s focus on simplicity enabled it to be quickly adopted.

Its empirical approach enabled it to work in complex environments where we needed to inspect and adapt to the reality we were discovering. It was purposefully incomplete because it was recognized that no universal practices existed. Attempting to provide a full set of practices would be overwhelming. This also avoided prescribing practices on the teams that were not fit for purpose.

When teams used Scrum they had amazing success. Others noticed and the Scrum movement had started.

======

Please comment if you think anything I've written here is a misrepresentation of Scrum. Or if you think I've left something important out.

======

“It's easier to act your way into a new way of thinking, than think your way into a new way of acting.” Jerry Sternin

Thus, the task is, not so much to see what no one has seen yet; but to think what nobody has thought yet, about that what everybody sees. — Arthur Schopenhauer

?

?