5 Whys of Scrum

Why should you use Scrum?Over 32% of traditional projects fail to meet time and budget. Agile is an alternative approach to software delivery. In 2010, Forrester Research recognized that agile is now mainstream1 and Scrum is the leading universal agile framework.2 3 4

Scrum is...• Simple, a manager-friendly agile

development framework• Scalable, working for small start-ups and

large distributed enterprises• Widespread, used by over 50% of

companies that implement agile2 • Proven to improve quality and

productivity by 33% or more3

!"#

$!"#

%!"#

&!"#

'!"#

(!!"#

())*# ())&# ())'# $!!!# $!!$# $!!%# $!!)#

+,-./0# 12,../34/0# 5677//0/0#

Traditional IT project success rates. Standish Chaos Reports, 1995-20094

www.agile42.com/5whys

1 “Agile Software Development is Now Mainstream”, Jan 22, 2010, CIO Magazine2 “Agile by the numbers: Survey finds more adoption, but age-old problems remain”, Oct 27, 2009, SearchSoftwareQuality3 Percentage fewer failures in agile vs. traditional projects, 2010 IT Project Success Rates Survey Results, Ambysoft4 Success rates for IT projects taken from the Standish Chaos report (1995-2009)

http://www.agile42.com/5whys


What is Scrum?Agile Scrum teams focus on results not effort. Scrum is a principle-based framework for continuous learning that focuses on maximizing value delivery instead of effort.

The Scrum frameworkRequirements are taken from a prioritized Product Backlog and broken down into small features that can be delivered as working software during short development iterations, called Sprints.

Work is pulled from the Product Backlog into a Sprint Backlog for completion in the sprint by the Development Team. The outcome of a Sprint is a Deliverable that, ideally, can be released immediately after acceptance by the Product Owner at the Sprint Review meeting.

Why Scrum worksSelf-organizing teams in Scrum emerge because of core values:

•Full bandwidth communication

•Work commitment by selection•Delivering working

software•Actions guided by the big picture




What is Agile?1Agile drives continuous improvement by repeatedly inspecting and adapting the working process.

The Agile approach• Works Empirically: Agile is an empirical,

principle-based approach for delivering software in a complex technical and business environment

• Reduces Complexity: Today’s business and technical environment changes rapidly; complexity is growing exponentially

• Handles Change: Developers solve increasingly difficult problems in a technology environment that is undergoing rapid change

Defined, process-driven systems, like waterfall, are ill-equipped to manage the dependencies and uncertainty created by complexity and change.

The volume of code in everyday products is increasing exponentially1


1 “Why Dinosaurs Will Keep Running the Auto Industry”, Harvard Business Review, June 2010

!"

#"

$"

%"

&"

'!"

#!!(" #!!)" #!'!"

!"#$%&'$()*+',$"-$./('0$"-$1"2'$3*/../"(045$6$7,"89$-",$1"*7.'8/%95$/($

:",2$;'&/1.'0$&60$1&6(<'2$

!"#"

$!"$#"%!"

&'()*+",-,"./(012)*(/"

34(/0+("%!$!"5'/6""

704)+08'*"9:;<(1="%!!>"9?@20;;"A(/B(6(;"

!"#$%&'(")*"+*,-.*/".')0*1&.%#2').&3*%*4"&53*%)5*%*6"#$").),**

"+*,-.*7.&6.5.(*89!2%((**:#'22'")*2').(*"+*6"5.;*



How agile are you? • Do you use business value to prioritize

requirements? • Do you have cross-functional Development

Teams?• Do they deliver working software regularly?• Do you review the process at the end of

each iteration?• Are features small enough to be completed

in a short iteration?

What is Lean? Lean thinking is a principle-based approach with empirical inspect-and-adapt iterations instead of defined process steps. Since 2001 agile has been used to describe software development approaches based on the lean principles applied so effectively by Toyota.1 Agile is lean applied to software development.

Lean thinking• Muda - Waste: refers to any non-value adding

activity that a customer is unwilling to pay for. Lean companies passionately eliminate waste

• Muri - Process Overload: refers to the tendency to overload processes in the hope of achieving more. Lean thinking maximizes value creation over process utilization

• Mura - Uneven Flow: inconsistent flow can disrupt a system, creating inefficiencies and waste. Lean decreases lead time by smoothing flow through a system


1 Toyota used lean thinking in their manufacturing process to become the world’s largest car manufacturer



Why are there just 3 roles?The Scrum framework relies on three peer-level management roles, whose mutually exclusive responsibilities lead to positively-reinforcing behaviors that stabilize the process. Combining responsibilities eventually leads to contradictory drivers or conflicts of interest. The three distinct roles allow people to focus on defined responsibilities with different objectives driving behavior.

• The Product Owner (PO) maximizes the return-on-investment (ROI) of the product, measured from idea conception to delivery to the paying customer

• The Scrum Master continually improves the development process, coaching the Scrum team to become more productive, improve quality and self-organize

• The Development Team manage the technical quality of the product by nurturing practices that reinforce shared code ownership


ROI

Process

Quality



The Business Value Game1 is used to estimate relative value of high-level requirements:

• Prepare SMART2 requirements with support of stakeholders to focus discussion

• Convene a Product Board with all product stakeholders

• Estimate the relative value of each requirement by discussing and ranking them together

• Write user stories for requirements at the top of the backlog to deliver value as early as possible

The Product Owner - A value-driven role12The PO maximizes ROI by managing value delivered with fixed iteration lengths by a stable team. Value is managed by:• Product Vision: Combining a company’s

strategic goals with its customers’ needs to create a product vision•Prioritized Value: Creating high level requirements and prioritizing business needs by value with the help of the stakeholders•Groomed Backlog: Writing user stories to manage production risk•Release Planning: Predicting value earned per sprint and managing the

product backlog to maximize delivered value


1 agile42’s Business Value game for estimating relative value is described in full online2 SMART objectives are Specific, Measurable, Achievable, Relevant and Testable



Facilitating ceremoniesFocus on value: Timebox meetings, prioritize discussion, coach participants to communicate effectively

Oversee the process• Understand Value: What is being delivered?

Make both delivered value and waste visible• Understand Individuals: Expose inter-team

issues and help the Team to resolve the issues?• Understand Process: Visualize the process

and focus on removing single largest bottleneck

The Scrum Master - Leading without authorityThe Scrum Master has no authority in the Scrum team. Influence is earned.He or she is a servant leader, facilitating the ceremonies and overseeing the Scrum process.

It is a coaching role, analyzing progress to focus on incremental improvement over time and guiding the Teams to learn from experience through effective retrospection.

Stand behind the team, not in front




Striving for technical excellence• Share a common Definition of Done for maintainability• Use a Definition of Ready to prepare items in the backlog• Encourage collective code ownership• Build automated tests and integrate continuously• Make quality of your code transparent to the whole Team

Development Team - Writing working softwareAgile Development Teams measure progress through the delivery of working software.1 Effective agile Development Teams share three characteristics:

• They are cross-functional - all the skills required to build a complete production-ready product area represented in one Team

• They are small - from studies of team behavior, the optimum size for effective collaboration is 5-9 people; not too large so that communication becomes an issue, not so small that overhead is excessive

• They use an integrated development environment to create working, production-ready software within a Sprint, allowing merging and check-ins with automated tests on a regular basis


1 Agile Manifesto, Principle #7: Working software is the primary measure of progress



Owner Ceremony PurposeProduct Owner Sprint Planning Use value to prioritize next sprint by:

• Presenting just enough user stories for the next sprint (or 2)• Guiding the Team on the purpose of the next sprints• Estimating and selecting user stories for the sprint backlog

Scrum Master Daily Scrum Inspect & adapt progress towards sprint goal by:

• Minimizing number of open user stories• Delivering done user stories before taking next story• Maintaining balance between quality and value delivery

Development Team

Sprint Review & Retrospective

Inspect & adapt product and process by:

• Reviewing user stories by viewing working software• Continually reviewing product against vision and sprint goals • Improving process incrementally by small prioritized steps

Why are there 3 ceremonies in Scrum?To help Teams deliver working software at the end of a Sprint, there are three regular, time-boxed ceremonies, each with a single purpose and owner.




Sprint Planning Estimation & selection• The PO describes the sprint goal to give

context surrounding the stories• Each story is discussed with the Team, who

estimate relative effort• The Team select stories they will deliver within

a sprint

Task break down• Each story is broken down into the required

technical tasks by the Team


Limit risk of failureIn order to effectively plan releases and meet customer needs in terms of delivery schedule and feature sets, the PO needs to be able to predict the productivity of the Team over time.

These practices that help the PO to manage risk:

• Sizing stories so 6-10 stories fit into a sprint• Pulling, not pushing, stories from the backlog• Keeping a steady cadence or rhythm to sprint

length• Only accepting working, tested software• Working with a visible and shared Definition of

Done, what it means to complete a user story• Defining non-functional requirements implicit to

customer acceptance of the product



Daily ScrumThe Team inform one another about what is working and what is not, and agree on how to

address issues that threaten to slow progress against the sprint goal.

A Daily Scrum uses 15 minutes in which each team member answers three simple questions:

1.What did you do yesterday?

2.What will you do today?

3.What is stopping you from delivering (more)?

The Daily Scrum is not a status report for a PO or stakeholder,

but is a forum for the Team to work more closely together.

Active participation is limited to the Team, with the Scrum Master facilitating;

others may observe and contribute only if asked to by the Team.

The Daily Scrum highlights things to watch for, and keeps the Team accountable to the sprint goal.


The Daily Scrum• Is short, time-boxed at 15 minutes• Is held around the task board to keep focus • Lets the Team inspect & adapt the plan for

the sprint• Exposes issues that may need the Team to

swarm around and solve



Sprint Review & RetrospectiveThe last principle of the agile manifesto says “at regular intervals, the Team reflect on how to become more effective, then tune and adjust their behavior accordingly.” The Sprint Review is the ‘inspect’ part of the inspect & adapt process, in which the Team look at running software; the Retrospective is the ‘adapt’ part of the process, in which the Team make small changes to incrementally improve the product and the process.

Product improvementAs well as a product demonstration, the Team inspect & adapt the product as a whole, adapting practices and the product backlog as a result.

Based on current results, progress can be assessed and further investment planned.

Process improvementAfter a Sprint Review, the Scrum team inspect & adapt the process through a retrospective, allowing an agile team to incrementally improve the development process.


Running a RetrospectiveA Retrospective can be a challenging discussion. To keep focussed and effective:

• Gather individual feedback on post-its in short time boxes

• Balance positive and negative feedback from everyone

• Separate idea generation from evaluation• Prioritize ideas and select a few of the best

actions



Why are there just 3 artifacts?The Scrum framework has developed over time, and through the incremental improvement central to all agile methods, waste has been stripped away.

The result? Just 3 core artifacts or tools necessary to govern Scrum:

• Product Backlog, with items prioritized by value; owned by the PO

• Sprint Backlog, sub-set of product backlog protected from change; owned by the Team

• Burndown Chart, visualization of work to be completed; owned by the Scrum Master




Definition of ReadyUsed to determine when a user story or work item is ready to present to the Team, for example:

• Stories follow the INVEST mnemonic1

• Small enough that one Team can select 6-10 stories in a sprint

• At least 3-4 Acceptance Criteria

The PO’s Product Backlog1

The product backlog contains items, or business requirements, prioritized by relative business value.

The backlog consists of the Why (requirement) and the What (user stories). The How, the

technical tasks, is determined by the

Development Team.

Flexibility is maintained by using a just-in-time approach to breaking down the requirements. Requirements near

the top of the backlog are broken down into multiple user stories, with the goal of having enough prepared user stories for just the next 1-2 sprints.


1 User stories that are Independent, Negotiable, Valuable, Estimable, Small, Testable



The Team’s Sprint Backlog 1The Sprint Backlog contains stories that will not change during the sprint, allowing the Team to focus on delivering the selected stories. Outside the Sprint Backlog, the PO can re-prioritize stories if needed.

A good Sprint Backlog contains:

• 6-10 stories the Team selected for the sprint• Just enough small tasks for the next few days

(to limit risk of waste)

The Scrum board• Visualizes the current activity in the Team• Helps Team limit open and incomplete stories • Highlights dependencies between tasks• Shows time committed to tasks outside the

sprint goal• Keeps focus, with ideally one activity or story

open at a time

Tools like Agilo1 help manage agile teams online, ideal for distributed teams


1 Agilo is an open-source agile management tool, ideal for distributed teams



The Scrum Master’s Burndown Chart1The Burndown Chart shows work that still needs to be done, allowing the Scrum- Master to manage the Scrum framework.

The units used for the Burndown chart provide different information and levels of granularity:

• Completed User Stories, burning down User Story points, may show no change for days at a time• Completed tasks, burning down ideal hours, should change daily, but can also burn up if additional tasks

are uncovered and added to the backlog

Tools like Agilo1 can automate chart creation

Reading the Burndown Chart• Visualizes work to be completed (y-axis)• New tasks/stories move line up• Trend line shows ideal task/story burndown• Used by Scrum Master to focus Daily Scrum • Sudden gradient drop hints at possible

technical debt


1 Agilo is an open-source agile management tool, ideal for distributed teams



Agile development principles• Eliminate waste: Automate any repetitive

task, like acceptance testing or product build• Regular, rapid feedback: make small

changes and test/integrate/build immediately• Integrate early: difficulty of integrating new

code grows exponentially with size of change• Code ownership: the Team develop code.

Work together, agree common standards • Emerge design: avoid over-engineering -

only design and build what is required today

Why do agile engineering practices help?The Scrum framework is a simple framework with 9 prescriptions: 3 roles, 3 ceremonies and 3 artifacts. These prescriptions help streamline the product definition and value creation, with a focus on the work definition and management practices; there are no technical practices.

Experience shows that effective Scrum teams need software engineering practices aligned with these management practices; short iterations delivering working software are not possible using traditional, big up-front design followed by long develop and test cycles.

Other agile methodologies have focussed more on the technical practices, and many successful Scrum teams adopt agile development practices like those described as part of the XP1 framework.


1 eXtreme Programming describes development practices such as pair programming, refactoring and continuous integration



Building code ownershipSigns that a Team is building a culture of shared code ownership include:

• Knowledge sharing tasks on the task board not directly related to delivering a new feature

• Design and architecture decisions made with non-architects or designers in the Team

• Common use of pair programming to share knowledge

• Shared, visible and continually updating Definition of Done for user stories

• Selection of user stories outside area of expertise of a Team (and successful delivery)

Encouraging code ownershipCode ownership is the principle by which the Team take responsibility for the technical quality of the product. It means that the whole Team share responsibility for the code across the whole system.

Shared code ownership builds in redundancy, increases general knowledge of the system without sacrificing specialist expertise, increases quality and reduces time wasted chasing bugs.

Code ownership means:

• A common understanding of coding standards and expectations

• Open communication between developers• Building and sharing knowledge • Practices that support rebuilding and emerging

design




Increase quality by regular, rapid feedbackThe cost of debugging increases exponentially with the length of time after a bug is introduced; the earlier a bug is found, the cheaper and easier it is to solve. An underlying principle of agile development is to get feedback quickly and often to uncover defects early. Many agile development practices focus

on decreasing the time taken to get feedback. This helps eliminate waste and build quality in.

Agile practices focus on regular, rapid feedback.

• Test-driven development builds a test framework before the code is written

• Pair programming provides feedback as the code is written

• Automated function or acceptance testing feeds back as the features grow

• Continuous integration ensures functioning builds and tests integration

Regular, rapid feedback increases code quality by:

• Encouraging small, incremental code changes

• Discouraging the ‘works on my machine’ mentality

• Making merging easier• Visualizing code quality and shared coding

standards• Focusing Team on writing working software• Validating that the product is shippable




Refactoring legacy applicationsYou don’t need 90% coverage to refactor:

• Build tests as you code• Preferably write tests before you code• Write code that does only what you need it to • When you use legacy code, only test legacy

functionality exposed for the new feature• Start with specific cases, and refactor to add

generalization or modularity

Continually improve the designDefining architecture upfront seems to be a good idea. The architect must think through the design, and can design for future growth.

But this misunderstands the purpose of architecture; it is a service to those that develop the product, maximizing the Team’s ability to develop while meeting the business needs for the product in terms of non-functional requirements like performance under load or number of concurrent users.

Better to only design for what is right in front of you. Provide a service to the Development Team that makes development smooth, quick and efficient. When this is not enough, extend or modify the architecture.

This serves two purposes. Obviously, it reduces waste. Only the architecture that

is needed is built. But it also creates a continually improving environment in which the architecture can be modified and optimized to its current purpose, rather than stretched and squeezed to meet unplanned needs.




5 Whys of Scrum

Technology

Transcript of 5 Whys of Scrum