HBR Ideacast Review: Agile & Scrum
mrfamo01
agile-scrum-emoon-2018SPR1.pdf
AGILE & SCRUM
TOPICS
The origin of Agile The secret history of agile innovation
Agile principles Agile principles & Complex Adaptive Systems (CAS)
Plan-driven vs. Agile principles
The right conditions for Agile
An agile approach: Scrum What is Scrum?
How to organize Scrum?
Three roles in Scrum
Scrum Artifacts
Waterfall vs. Scrum
Scrum beyond IT
2
THE SECRET HISTORY OF AGILE INNOVATION (RIGBY ET AL., 2016A)
Agile’s roots extend far beyond Information Technology
Some trace agile methods back to a Plan-Do-Check-Act (PDCA) cycle, which the physicist and statistician of Bell Labs began applying, in 1930s
Some development is planned and done, the results are inspected, and adaptations are made to improve the process to solve any problems that have arisen.
3
THE SECRET HISTORY OF AGILE INNOVATION (RIGBY ET AL., 2016A)
In 1986, Takeuchi & Nonaka published an article in HBR called “The New New Product Development Game.”
The authors studied (hardware) manufactures that were releasing successful innovations far faster than competitors. The authors identified a team-oriented approach at Fuji-Xerox, Honda, and Canon.
Rather than following conventional “relay race” methods of product development those companies were using what the authors called a “rugby” approach, where a team tries to go the whole distance as a unit, passing the ball back and forth.
4
THE SECRET HISTORY OF AGILE INNOVATION (RIGBY ET AL., 2016A)
Sutherland discovered Takuchi and Nonaka’s rugby approach in 1993, even though it focused on manufacturing rather than software.
Sutherland created a new way of developing software; honoring the rugby imagery, he dubbed his approach “scrum.”
5
AGILE PRINCIPLES • Agile principles & Complex
Adaptive Systems (CAS)
• Plan-driven vs. Agile principles
• The right conditions for Agile
6
AGILE PRINCIPLES & COMPLEX ADAPTIVE SYSTEMS (CAS)
Agile principles are inspired by concepts from Complex Adaptive Systems (CAS) (Fitzgerald et al., 2013).
Did you ever wonder when birds take off, they have a “manager bird,” with a flipchart, down at my pond that calls a meeting to instruct the birds on how to flock?
7
From Figure 11.3 (Rubin, 2012)
AGILE PRINCIPLES & COMPLEX ADAPTIVE SYSTEMS (CAS)
Like the flocking birds, a development team has no top-down command-and-control authority that tells the team how to do its work.
Instead, a cross-functionally diverse team of people organize themselves in the most appropriate way to get work done (i.e., self- organizing).
The self-managing team can experiment and adapt, while still remaining enough structure so as not to fall into disarray.
8
From Figure 11.3 (Rubin, 2012)
AGILE MANIFESTO
Agile methodologies were created based on the Agile Manifesto which identifies four fundamental value propositions for agile as:
Individual and interactions over Processes and tools.
Working software over Comprehensive documentation.
Customer collaboration over Contract negotiation.
Responding to change over Following a plan.
While the agile advocates acknowledge the statements on the right as having value, they valued the statements on the left more.
9 https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide
COMPARISON SUMMARY OF PLAN-DRIVEN & AGILE PRINCIPLES
10
Plan-Driven Principle Agile Principle
Process structure Development is phase-based and
sequential.
Development should be iterative and
incremental.
Change/emergence Change is disruptive to plans and
expensive, so it should be avoided.
Embrace change in an economically sensible
way.
Predictive vs. Adaptive The process is highly predictive. Balance predictive up-front work with
adaptive just-in-time work.
Batch size (how much
work is completed
before the next activity
can start)
Batches are large, frequently 100%--all
before any. Economies of scale should
apply.
Use smaller, economically sensible batch
sizes.
When we get high
quality
Quality comes at the end, after an
extensive test-and-fix phase.
Build quality in from the beginning.
Source: Rubin, 2012: pp.59 - 60
THE RIGHT CONDITIONS FOR AGILE (RIGBY ET AL., 2016B)
11
Conditions Favorable Unfavorable
Market environment Customer preferences and solution options change frequently.
Market conditions are stable and predictable.
Customer
involvement
Close collaboration and rapid feedback are feasible.
Customers know better what they want as the process
progresses.
Requirements are clear at the outset and will remain
stable.
Customers are unavailable for constant collaboration.
Innovation type Problems are complex, solutions are unknown, and the scope isn’t clearly defined. Product specifications may
change. Creative breakthroughs and time to market
are important.
Similar work has been done before, and innovators
believe the solutions are clear. Detailed specifications
and work plans can be forecast with confidence and
should be adhered to. Problems can be solved
sequentially in functional silos.
Modularity of work Incremental developments have value, and customers can use them. Work can be broken into parts and
conducted in rapid, iterative cycles.
Late changes are manageable.
Customers cannot start testing parts of the product until
everything is complete.
Late changes are expensive or impossible.
Impact of interim
mistakes
They provide valuable learning. They may be catastrophic.
AN AGILE APPROACH: SCRUM Scrum is one of the most popular
and widely adopted agile
methods.
12
WHAT IS SCRUM?
Agile comes in many different methods, such as Scrum, eXtreme Programming (XP), and Crystal.
Scrum is one of the most popular and widely adopted agile methods.
Definition of Scrum
A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value (Sutherland & Schwaber).
13
HOW TO ORGANIZE SCRUM? How to organize Scrum? Scrum organizes work in iterations or cycles of up to a calendar month called sprints.
Sprints are timeboxed, have a short and consistent duration, have a goal that shouldn’t be altered once started, and must reach the end state specified by the team’s definition of done.
A misuse of the sprint concept Focus each sprint on just one type of work—for instance sprint 1 (analysis), sprint 2 (design), sprint 3 (coding), and sprint 4 (testing). Such an approach attempts to overlay Scrum with a waterfall-style work structure. This is often referred to as “WaterScrum” or “Scrummerfall.” (Rubin, 2014: p.34)
Why?—because in Scrum, we work on a feature at a time, not on a phase at a time.
14
THREE ROLES IN SCRUM (1/3)
The scrum team consists of:
Product Owner
Scrum Master
Development Team
A product owner is responsible for:
What will be developed in what order
Maximizing the value of the product and the work of the Development Team.
15
From Figure 2.2 (Rubin, 2012)
THREE ROLES IN SCRUM (2/3)
A scrum master helps everyone involved understand and embrace the Scrum values, principles, and practices.
The scrum master acts as a coach, providing process leadership and helping the scrum team and the rest of the organization develop their own high performance, organization-specific Scrum approach.
The scrum master has no authority to exert control over the team. This role is not the same as the traditional role of project manager or development manager. The scrum master functions as a leader, not a command-and-control authority.
16
From Figure 2.2 (Rubin, 2012)
THREE ROLES IN SCRUM (3/3)
The development team self-organizes to determine the best way to accomplish the goal set out by the product owner.
Development Teams have the following characteristics:
They are self-organizing
Development teams are cross-functional, with all of the skills as a team necessary to create a product increment.
17
From Figure 2.2 (Rubin, 2012)
SCRUM ARTIFACTS
Product Backlog:
An ordered list of everything that might be needed in the product.
The single source of requirements for any changes to be made to the product.
The product owner is responsible for the Product Backlog.
Sprint Backlog:
The set of Product Backlog items selected for the Sprint, plus a plan for delivering the product increment and realizing the Sprint Goal.
The Development Team modifies the Sprint Backlog throughout the Sprint
The Sprint Backlog emerges during the Sprint.
18
At Easel, I [Jeff Sutherland] knew the [traditional] Waterfall
methodology would put us months if not years past our deadline. We
had to come up with a completely different way of doing things. I
went to the CEO and told him we were scrapping the Gantt Chart.
He was shocked and demanded to know why.
“How many Gantt charts have you seen in your career?” I asked.
“Hundreds,” he replied.
“How many of them were right?”
He paused. “None.”
—Jeff Sutherland
19
WATERFALL VS. SCRUM
This comparison is not to make the case that plan-driven, sequential development (Waterfall) is not great, and that Scrum (Agile) is good.
It is important to understand when to use which approach.
Let’s move on to the next slides to see how each one is different from one another!
20
WATERFALL VS. SCRUM Traditional Waterfall approach works well if you are applying it to problems that are well defined, predictable, and unlikely to undergo any significant change.
However, as you may have experienced, developing a product rarely goes as planned in reality.
The key is that the problem is not with the execution of this approach, but that waterfall approach is based on a set of beliefs that do not match the uncertainty inherent in most product development efforts.
21
WATERFALL VS. SCRUM
In contrast, Scrum is based on iterative and incremental development. Iterative development enables development teams to use multiple passes to improve what they are building.
e.g., Start by creating a prototype, and then, create a revised version that is something better, which might, in turn, be followed by a pretty good version.
Incremental development is based on the age-old principle of “Build some of it before you build all of it.”
It avoids one large, big-bang-style event at the end of development where all the pieces come together and the entire product is delivered.
22
WATERFALL VS. SCRUM
Scrum leverages the benefit of both iterative and incremental development.
Scrum does this by using both ideas in adaptive series of timeboxed iterations, which is called “sprints.” (see Figure above)
23
SCRUM BEYOND IT (SUTHERLAND & SUTHERLAND, 2014)
Scrum is not limited to IT department.
Scrum works well for any complex, innovative scope of work.
Diverse businesses are using Scrum, for instance, building rocket ships to managing payroll to expanding human resources (HR), from finance to investment, from entertainment to journalism.
Agile’s branches will continue to spread to improve innovation processes in nearly every function of every industry.
24
REFERENCES
Fitzgerald, B., Stol, K. J., O'Sullivan, R., & O'Brien, D. (2013, May). Scaling agile methods to regulated environments: An industry case study. In Software Engineering (ICSE), 2013 35th International Conference on (pp. 863-872). IEEE.
Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016a). The secret history of agile innovation. Harvard Business Review.
Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016b). Embracing agile. Harvard Business Review, 94(5), 40- 50.
Rubin, K. S. (2012). Essential Scrum: A practical guide to the most popular Agile process. Addison-Wesley.
Sutherland, J., & Schwaber, K. (2013). The scrum guide. The Definitive Guide to Scrum: The Rules of the Game. Scrum. org.
Sutherland, J., & Sutherland, J. J. (2014). Scrum: the art of doing twice the work in half the time. Crown Business.
Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review,
25
