Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
2014
Accelinnova.com
7/15/2014
Agile and Lean Handbook
Agile and Lean Handbook Page 2 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Table of Contents
Overview........................................................................... 6
Starting Model Development Process .................................... 6
Enabling Overall effectiveness........................................... 6
Defining Requirements ..................................................... 6
Business Decision Making ................................................. 6
Enabling Development Effectiveness .................................. 7
Overall Project Management ............................................. 7
Section 1. Agile and Lean Workshop ..................................... 8
Agile and Lean Introduction ................................................. 8
What is Agile? ................................................................. 8
Why Agile? ..................................................................... 8
How Does Agile Work? ..................................................... 9
What role does Lean play?................................................ 9
Business Issues Today ..................................................... 9
How does Agile achieve this? .......................................... 10
Agile Defined ................................................................ 12
Lean ............................................................................ 14
Ownership .................................................................... 14
Business Value Decision Making ......................................... 15
The Business Value Model .............................................. 15
Business Value Decision Making Flow ............................... 18
Dive Into Scrum ............................................................... 19
Roles ........................................................................... 19
Demonstrate Ownership / Build Trust .............................. 21
Whole Team & Delivery Team ......................................... 22
Key Agile Artefacts ........................................................... 23
Release Themes ............................................................ 23
Product Epics ................................................................ 23
User Stories ................................................................. 24
Agile Estimating and Planning ............................................ 27
The Agile Plan ............................................................... 27
Planning Process ........................................................... 27
Estimating Approach ...................................................... 28
Planning Poker .............................................................. 28
Agile and Lean Handbook Page 3 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Using Velocity ............................................................... 29
Information Radiators .................................................... 30
For Every Sprint ............................................................ 30
Scrum Process Summary ............................................... 33
Lean Software Development .............................................. 34
Lean Tools that Work ..................................................... 34
Learn to See and Eliminate Waste ................................... 35
Common Wasted Effort .................................................. 35
Common Wasted Time ................................................... 36
Wasted Effort and Time.................................................. 37
Value Stream Mapping ................................................... 38
Error Proofing: Build Quality In .......................................... 39
Quality is Everyone’s Responsibility, Not Just Test’s. .......... 39
Drive Down Technical Debt ............................................. 40
Quality Tools ................................................................ 41
Defer Commitment ........................................................... 42
Deliver Fast ..................................................................... 43
Tools ........................................................................... 44
Focus on Learning ............................................................ 44
Actively Enable Product Learning ..................................... 44
Actively Enable Process Learning ..................................... 44
Capture Knowledge Concisely ......................................... 44
Optimise the Whole .......................................................... 47
Tools ........................................................................... 47
Lean Summary ................................................................ 47
Section 2. Focus and Best Practice ..................................... 48
Why Agile Works .............................................................. 48
Agile Methodologies .......................................................... 49
XP Practices.................................................................. 49
Scrum ......................................................................... 49
Lean ............................................................................ 49
RUP/OpenUp ................................................................ 49
Agile Discipline ............................................................. 50
PatientKeeper = Done, Done, Done, Done ........................ 50
Self Directed Teams ...................................................... 50
Working with Stakeholders ................................................ 50
Agile and Lean Handbook Page 4 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Stakeholder Goals Document .......................................... 51
Effective Reflections ......................................................... 51
Kaizen ......................................................................... 52
How should the standard be created? .............................. 52
Reflection Approach ....................................................... 52
Test Driven Development .................................................. 52
The Foundation ............................................................. 52
Continuous Testing Checklist .......................................... 53
The Process .................................................................. 53
Measuring Agile Progress .................................................. 53
Be Aware ..................................................................... 53
Validate Your Metrics ..................................................... 53
Key Lessons ................................................................. 54
Technical Debt ................................................................. 55
Done, Done, Done ......................................................... 55
Iterations Complete ....................................................... 55
Agile Governance ............................................................. 55
Agile Enhances Project Governance ................................. 56
Agile Governance – Simple Understandable Concise .......... 56
Iteration Records .......................................................... 57
Business Process Changes .............................................. 57
Contracts and Documents of Understanding ..................... 57
Key Process Definitions/Revisions Needed ........................ 58
Agile Governance Summary............................................ 58
Agile for IP Lawyers .......................................................... 60
Agile for Contract Lawyers ................................................. 61
Key Elements ............................................................... 62
Agile Infrastructure .......................................................... 64
Assess the Organisational Infrastructure .......................... 64
Challenging Infrastructure Areas ..................................... 64
The Infrastructure Can Help ........................................... 64
The Leader’s Role .......................................................... 65
Agile Behaviours .............................................................. 66
Stakeholder and Business Leader Example ....................... 66
Multi-Site Development ..................................................... 67
Distributed Teams ......................................................... 67
Agile and Lean Handbook Page 5 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Large Scale Agile .............................................................. 69
Large Projects ............................................................... 69
Agile Works for Large Projects ........................................ 69
Challenges to Address ................................................... 70
Effective Mitigations ...................................................... 70
Leading Agile Teams ......................................................... 70
Leader’s Role ................................................................ 70
Collaborative Leadership Model ....................................... 70
Collaboration Process ..................................................... 71
Leading Collaborative Teams .......................................... 71
Agile Project Management .............................................. 71
How Can the Leader Help? ............................................. 71
Step by Step ................................................................ 72
Remember ................................................................... 73
The Agile Development Manager ........................................ 74
Getting Started ................................................................ 76
Considerations .............................................................. 76
Before Sprints Begin ...................................................... 76
Section 3. References ....................................................... 77
What is Agile and Why It Works ...................................... 77
Agile In General ............................................................ 77
Dive Into Scrum ............................................................ 79
User Stories ................................................................. 79
Agile Estimating and Planning ......................................... 79
Business Value Model .................................................... 80
Agile Best Practices ....................................................... 80
Leading Agile ................................................................ 80
Lean Approaches ........................................................... 81
Error Proofing: Build Quality In ....................................... 81
Agile and Lean Handbook Page 6 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Overview
This handbook is to provide a hard copy of the materials
covered in the Accelinnova course and to provide references
and details for the any best practice principles that are
mentioned but not gone into depth.
There are three sections:
Section 1. Agile and Lean Workshop covering all the sections
in the course.
Section 2. Focus Areas and Best Practice which includes
topics such as Test Driven Development, Governance, and
Distributed Agile Teams.
Section 3. References, both quick reads and deep dives are
listed.
We have left a wide right hand margin for your notes.
For more information, contact Accelinnova at Accelinnova.com.
Starting Model Development
Process
We expect all teams to own and adjust their own development
process. To help teams get going quickly we recommend the
following as a starting point for tailoring.
Enabling Overall effectiveness Collaboration: Whole Team responsibility.
High ownership and trust.
Last responsible moment decision making.
Lean lightweight documentation.
Investment in tools and automation.
Focus on speed: Value Streams.
Optimize the Whole: Measure UP.
Sustainable pace.
Continuous learning: Reflections.
Defining Requirements User Stories.
Continuous refinement using customer and stakeholder
feedback.
Business Decision Making Defer decisions: Last responsible moment decision
making.
Business Value Model for requirements prioritization.
Continuous reprioritization using customer and
stakeholder feedback.
Agile and Lean Handbook Page 7 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Enabling Development Effectiveness Agile: Iterate with 2 week time-boxed iterations.
Lean: Focus on working code and low waste.
XP practices for discipline.
Lower Technical Debt:
Continuous integration and regression
testing.
Test automation.
Continuous testing: Done, Done, Done.
Pair Programming, effective Unit testing,
TDD.
Demos with customer and stakeholder feedback.
Reflections and process adjustment every iteration.
Overall Project Management Agile Release Planning.
Story Points for estimating and tracking progress.
Information Radiators.
Agile and Lean Handbook Page 8 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Section 1. Agile and Lean Workshop
In the course, we cover the following topics:
1. Agile and Lean Introduction
2. Decision Making based on Business Value
3. Dive into Scrum
4. Agile Estimating and Planning
5. Lean
Agile and Lean Introduction
What is Agile?
A set of Effective Principles Recognize an Uncertainty & Change
Ownership
Learning
Collaboration
Disciplined Delivery
A set of Practices that help implement those principles
Delivers business value in “chunks”.
Continuous on stakeholder and customer feedback.
Embraces change.
Continuous learning.
Practice Excellence
Continuous High Quality
Must remove the 4.2 defects / hour that
programmers introduce
No accumulation of technical debt.
Anything that makes code difficult to change.
Cost of getting out of debt is compounded over
time.
Why Agile?
Faster and better results!
Drive Efficiencies Improve delivery: time to market and throughput of
schedules.
Improve velocity and agility to deal with change, risk
and uncertainty.
Taking “systems” view to drive out further cost and
waste in product development lifecycle.
Become More Effective Become an enabler of business strategy.
Make sure we are delivering the right business value.
Agile and Lean Handbook Page 9 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Facing of market and technical uncertainty, agile methods:
Improve delivery.
Decrease time-to-market.
Reduce rework.
How Does Agile Work? Breaks work into chunks.
Prioritize chucks by business value.
Builds highest value chunks in a time-boxed iteration
called a Sprint.
Delivered chunks are working, ready to be deployed
software.
Deployed when stakeholder says there is enough
Business value to go to market.
What role does Lean play?
By reducing waste, lean creates excess capacity that we can
allocate to high priority tasks.
Agile Examples 1 year projects reduced to 5 months with better quality
(custom systems).
Past: 3 months to develop 2 year roadmap Present: 3
days.
Financial: 50% time cut; 60% cost reduction.
Business Issues Today
Must consistently deliver business value:
In a dynamic environment
With constrained resources.
Business Dynamics Innovation to differentiate and capture new value.
Heighten responsiveness to customers/users.
Tighter linkage to customers.
Improve time to value; faster delivery of capabilities.
Operational Dynamics Improve predictability of schedule.
Improve quality and cost of ownership.
Making better use of resources to be more productive.
Improve project development cycle times.
Business Challenges
65% of projects challenged or fail
improving due to:
Better Tools
Better Project Managers
Adaptive Methods
Breaking projects into small chunks
Agile and Lean Handbook Page 10 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Delivering pieces faster for user feedback
But …. 64% of features rarely or never used.
Overall Business Needs Lead in the marketplace.
Deliver the right product.
Meet customer’s changing needs.
Deliver to rapidly moving market windows.
Innovate on both sides of your business model.
Get more done by doing less.
How does Agile achieve this?
Innovate to Differentiate and Embrace Change Go in search of change.
Help your customers lead in
their marketplace.
Understand your customer’s
success factors.
Assess market changes and
needs continuously.
Improve Time to Market Build the highest value first.
Don’t build what we don’t need.
Agile does this by… Breaks work into chunks.
Prioritize chucks by business value.
Being flexible.
Can be stopped or restructured without losing all value
Delivers in chunks (working, ready to be deployed
software).
Agile and Lean Handbook Page 11 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Business Driven
Responsive to Market Changes Continuous stakeholder feedback.
Stakeholders participate in:
User story development.
Prioritizing chunks.
Giving feedback on delivery of working chunks.
Quantifying Market Feedback
Net Promoter Score (NPS)
How likely are you on a scale of 1 to 10 to refer this
product to a peer?
(# of 9’s and 10’s) – (# of 1’s through 6’s)
Total number of responses
Transparency to Avoid Surprises Time box iterations (sprints).
Shows progress clearly.
Demonstrates working code with high quality at the end
of each sprint.
More finished state.
No technical debt accumulating.
Burn-Up chart clearly shows progress.
Mitigates Risk Discovering risks early through continuous short
iterations.
Addressing risks early and often.
Testing risk mitigation solutions.
Closing risks.
Realistically addressing uncertainty.
Dealing with Uncertainty We don’t know what we don’t know.
Honestly identifying what we don’t know.
Enabling mid-course corrections.
Only 5% of projects go as planned.
Delivering Quality Development discipline.
Agile and Lean Handbook Page 12 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Early validation.
Low Technical Debt.
TDD: Test cases are written first, before anything is
developed.
Go/no-go decisions reached early and often.
Development Process Choices Waterfall or Modified Waterfall: Characterised by
comprehensive detailed planning and plan following.
Iterative or Incremental: Characterised by incremental
delivery of agreed function.
Agile and Lean: Characterised as Iterative plus a strong
focus on efficiency and dynamic learning about
requirements and process.
Cowboy: Characterised by “We don’t do …. “
There is much confusion and misunderstanding about Agile and
Lean Development approaches. Many equate Agile with Cowboy
development.
Agile Defined
The Agile Principles Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
Deliver working software frequently,
from a couple of weeks to a couple
of months, with a preference to the
shorter timescale.
Business people and developers
must work together daily throughout
the project.
Build projects around motivated
individuals. Give them the
environment and support they need, and trust them to
get the job done.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive docs Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Agile and Lean Handbook Page 13 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
The most efficient and effective method of conveying
information to and within a development team is face-
to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
Continuous attention to technical excellence and good
design enhances agility.
Simplicity--the art of maximizing the amount of work
not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly.
Key Characteristics of Successful Projects Stable, Time-Boxed, Short Iterations.
Stakeholder Feedback.
Self-Directed Teams.
Sustainable Pace.
Agile Key Elements Iterative and incremental to deliver working software.
Highly Disciplined
Agile development necessitates greater discipline
than traditional methods.
“Quality” and “Consumability” must be real, not
platitudes.
Light-Weight. Barely sufficient” artefacts, methodology,
and documentation.
Practice Excellence
Requires self-discipline to improved quality.
Relies on the team to practice technical excellence
instead of imposing discipline.
Continuous Reflection and Improvement.
Retrospectives.
Continuous improvement.
Adaptive planning.
Agile and Lean Handbook Page 14 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Lean
Delivering value to the customer and removing wasted time
and effort.
Recognize and remove
waste:
Effort
Time
Poor quality
Focus on customer time
to value:
Continuously
optimize processes
Focus on flexibility
and pace
Ownership
Agile and Lean Handbook Page 15 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Business Value Decision Making
Agile approaches suggest prioritization based on Business
Value, but we need a framework to help us.
Most approaches to defining Business Value are seriously
flawed. Existing experience suggests that we invest large
amounts of resource on features which have little or no value.
The Business Value Model
The Business Value Model is a tool for improving our
assessments of Business Value
Purpose Based Alignment Model
Agile and Lean Handbook Page 16 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
The Model gives guidance about where the team should be
investing and how to get maximum Business Value from that
investment.
Differentiating Rules Rules How?
Always Be the Market Leader Innovate now and? forever
Focus Have 1-3 specific things you do better than anyone else
Own Differentiating You cannot outsource your innovation
Parity Rules Rules How?
Fill Any Gaps
Because Gaps Kill
Adopt Best Practices – adopt the
innovation of market leaders
Eliminate Risks
Because Risks Kill Simplify – complexity increases risks
and reduces agility
Create Capacity To Focus Resources on Innovation
Standardize – there is only downside to exception handling of Parity activities
Our strategy needs to deliver sustainable competitive
advantage and this must align with our market differentiation.
What is Differentiating?
If you do not have access to a defined Business Strategy use
these 4 questions to guide you:
1. Who do we serve?
2. What do they want and need most?
3. What do we provide to help them?
4. What is the best way to provide this?
Billboard Test
Often interested parties will claim that every their
“requirement” is differentiating. Test this with a Virtual
Billboard:
What will we put on our billboard to attract customers?
Start the billboard with: “Buy our product because….”
Decision Filters
A simple set of questions that we can propagate throughout the
organization for aligned decision making without continually
referring back to management.
Exceptions are investments that are strategically aligned but
do not make business sense. Handle them in more cost
effective ways.
Caveats
Parity is mission critical.
Treat exceptions as exceptions.
Differentiating changes over time.
Differentiation requires continuous innovation.
Agile and Lean Handbook Page 17 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Business Value Model – Considerations
There are often inputs that affect our decisions but are factors
that we cannot quantify as a cost or benefit. For example, what
is the market window and how does hitting or missing that
market window affect our decisions? How mature is our project
team? How much are we depending on the business process to
change?
Examples of considerations
Risks
Flexibility
Time to market
Dependencies
Team size and experience
Market uncertainty
Domain knowledge
Team capacity
Technical uncertainty
Costs and Benefits
Include these in the model but honestly recognise the
uncertainly in the numbers. Avoid over detailed estimating and
spurious accuracy which misinform. Recognise the cost of
delay.
Examples
Tangibles (Cost Savings/Additional Revenue)
ROI
IRR
Cash flow
NPV
Time to Self-Fund
Payback Time
Intangibles (Additional Revenue)
Customer Satisfaction
Customer Loyalty
Customer Ease of Use
Prioritize and Cycle It’s a conversation – not a formula
See all viewpoints
Resolve difference (using collaboration tools)
Group into chunks:
What can you defer?
What do you need to add to make a better
decision?
Higher Business Value first.
Risk user stories.
High development risk.
Agile and Lean Handbook Page 18 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Installation for effectiveness.
Migration difficult and critical.
Business Value Decision Making Flow
Delivering Value
Now that you have used the Value Model to frame your
decision, explore ways to deliver incremental business value. It
is likely that you can implement your project or product in
“chunks” that allow you to deliver the highest value faster.
Taking this approach, you get the key players together and
group your deliverable into intermediate deliverables. The
intermediate deliverables not only deliver the high value
sooner, they can also fill in knowledge gaps and reduce future
uncertainty.
Agile and Lean Handbook Page 19 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Dive Into Scrum
Scrum is a team based software
development project management
model developed by Jeff
Southerland. Learn more at
scrumalliance.org.
Roles Product
Owner
Scrum
Master Team Stakeholders
Artefacts Product
Backlog
Release
Backlog
Sprint
Backlog
Blocks
List
Information
Radiator
Meetings
Release
Planning
Meeting
Spring
Planning
Meeting
Daily
Scrum
Sprint Review
Meeting
Roles Stakeholders: gives input as to the product business
objectives.
Product owner: facilitating prioritizing based on
business value.
Scrum Master: ensures that the team is functional and
productive.
Team: self-organizes to get the work done.
Stakeholders
Anyone who can give input to the business objectives of the
product.
Principals Stakeholders who champion the need for your software and have the
authority to acquire and deploy it.
End Users Stakeholders who personally interact with your software.
Partners Stakeholders who make your product work in real life, such as operations
teams and also business partners and system integrators.
Insiders Stakeholders within your own organization; such as developers, support
engineers, sales, architecture, and marketing teams.
Product Owner
Builds roadmap and prioritizes user stories in collaboration
with:
Business Leaders
Stakeholders
Scrum Master
Functional representatives from team
Agile and Lean Handbook Page 20 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Get inside your customer’s mind. Use Outside-In
Development:
Understand your Stakeholders.
Align with Stakeholder’s goals.
Define success in your Stakeholders’ terms.
Understand organizational context.
Make products consumable.
Scrum Master Removes barriers between development and customer
so customer directly drives development.
Facilitates creativity and empowerment.
Improves productivity of development team in any way
possible.
Improves engineering practices and tools so each sprint
is ready to deploy.
Is not a project manager.
Team manages itself.
Does not have authority over the team.
Team makes decisions.
Always asks the question:
“How are the Product Owner and Team doing?”
Challenges the organization, key-role in the change.
Self-Directed or Self Organizing Teams
The concepts of leadership, management, and team
involvement are prospectively very different.
Encouraging a collaborative environment.
All roles support one another.
Whole Team is Jointly Responsible Stakeholders
Marketing
Sales
Line of business
Development
Architecture
Testing
Support
And anyone else who can impact success.
Agile and Lean Handbook Page 21 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Trust and Ownership Model
When problems occur leaders do not take ownership away
from the team but help them find new solutions by asking
questions.
Trusted Environment
Leaders View Individual in the Team
The team won't let me
down.
We understand the vision and the
need.
They understand what we
need.
We are jointly committed to
meeting our goals.
They will do the right
thing.
We stand or fall together.
They will tell me if they
need help.
We have ownership.
Demonstrate Ownership / Build Trust
The Team Step Up
Make & Meet Commitments
Deliver Real Value
Actively Improve
Support Other Teams
Ask for Help when you need it
Individuals within the Team Take Active Part
o Planning ( Release & Sprint )
o Scrum Meeting
o Demo
o Reflection
Be Honest Open Straightforward Respectful
Agile and Lean Handbook Page 22 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Step Up
Make & Meet Commitments to Each Other
Hold Each Other Accountable
Help Each Other
Coach / Challenge Loafers
Whole Team & Delivery Team
The Whole Team Involved but not personally committed to delivery
May be involved in planning &
retrospectives
May observe daily standups
The Delivery Team Committed to delivery
Active participants in planning &
retrospective
Active participant in daily
standup
Delivery Team Actions Takes ownership of delivery
Identifies and removes obstacles
Estimates the “bigness” of the user stories
Decides what stories should be completed in the sprint
Delivers “done, done, done” stories
Keeps technical debt low
Helps each other succeed
Holds each other accountable
Improves their process
Discovery Team
Responsible for continuous innovation during the release.
Consists of:
Product Owner
Architect
UX Developer
Where needed, works an iteration ahead of the Delivery Team
to prepare the way and ensure there are no design blocks.
Agile and Lean Handbook Page 23 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Key Agile Artefacts Product Backlog: Current view of things to be
delivered, made up of product epics.
Release Backlog: Items to be completed in this
release, made up of user stories.
Sprint Backlog: Items yet to be completed in this
iteration, made up of estimated user stories and tasks.
Blocks List: Items getting in the way of delivery.
Information Radiator: Current view of progress.
Themes, Epics and User Stories
Defining requirements in terms of Themes, User Stories and
Epics ensures that we stay focussed on the User’s needs and
not the details of the implementation that we create to solve
their problems.
Release Themes
Embody the highest priority needs of the project and provides a
decision filter for the team. Helps determine which user stories
fit into the release.
Release themes are based on business objectives.
Themes should embody highest business value needs of
the stakeholders and the product.
A well-known release theme provides a vision to team
Focus on stakeholder success.
Focus on product welfare: reduce technical debt,
increase maintainability, etc.
Provide a common goal for the “whole team”.
Prioritize and de-prioritize work.
Product Epics
Product Epics capture stakeholder goals for release themes.
They fit into product releases
Will not likely fit in an iteration
Team has an idea of how large the effort is
Create Product Epics with Stakeholders
All the Product Epics form the product backlog
Epic User Story and User Story Format
A concise, written description of a piece of functionality that will
be valuable to a stakeholder.
A User Story or Epic takes the form of:
As a <Role>
I want <Goal>
so that <Business value>.
Agile and Lean Handbook Page 24 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Epic User Stories
Capture stakeholder goals for releases.
Epic User Stories fit into releases.
Will not likely fit in an iteration.
Team has an idea of how large the effort is.
Create Epic User Stories with Stakeholders.
All the Epics form the product backlog.
Epic Goals Goal is “what the role can do”.
Valuable to a stakeholder.
Doesn't say “how”, but “what.
Epic Roles Avoid “the user” as different stakeholders have different
needs.
Use roles so that you do not “miss” stories.
Teams may develop a set of user roles to help define
relevant stories (personas).
Creating User Stories involves all the key people on your
team. Make sure that all Stakeholders and disciplines
are represented.
Principals Stakeholders who champion the need for your software and have the
authority to acquire and deploy it.
End Users Stakeholders who personally interact with your software.
Partners Stakeholders who make your product work in real life, such as operations
teams and also business partners and system integrators.
Insiders Stakeholders within your own organization; such as developers, support
engineers, sales, architecture, and marketing teams.
Epic Business Value Justifies the value of the story.
Clarifies why a story/feature is useful.
Can influence how a story/feature should function.
Helps prioritize the story in the backlog.
Can lead to other useful features that support
stakeholder’s goals.
User Stories Breakdown of Epics into smaller stories.
Fit into a Sprint (iteration).
User Stories form the Release Backlog and Sprint
Backlog.
Agile and Lean Handbook Page 25 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
A User Story example for an Insider:
As a database administrator, I can back up a database, so
that the data can be recovered if a failure occurs.
Break Stories into Smaller Stories Epic User Stories decompose into smaller User Stories.
Break epics one release at a time.
User Stories by definition fit into an iteration.
User Stories form the Release Backlog.
Avoid user stories that are too small:
When documenting the story takes longer
than implementing it.
Bugs, user interface tweaks, etc.
User Story Tips You can split Epics:
On operational boundaries.
Create - Read - Update – Delete.
Do not maintain a hierarchy of stories under an epic.
Easier to manage a flat list of user stories.
Hierarchical stories overcomplicate the backlog
and are hard to complete.
The epic is not complete just because the stories
are complete.
Good User Story Attributes
From Mike Cohn.
Testable
Format:
Given <Precondition>
When <Action>
Then <Result>
Example:
Given: User account exists in system
When: User enters existing user name and incorrect
password
Agile and Lean Handbook Page 26 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Then: System displays: “You provided an incorrect
password”
Agile and Lean Handbook Page 27 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Agile Estimating and Planning
Special thanks goes to Mike Cohn for
giving us permission to use his slides for
this course. Read more about Mike’s
company at mountaingoatsoftware.com
Much estimating activity is based on unreliable assumptions:
Task independence.
Local safety is used last.
Multitasking improves efficiency.
Good Plans Support reliable decision making.
Represent the current view only.
Are flexible, dynamic, and not over-detailed.
Avoid spurious accuracy.
Recognise That a Plan is Not a Commitment If plans are commitments, then we are committing to
decisions made when we were the most ignorant
(recall the cone of uncertainty, 5%).
Measuring conformance to plan is measuring the wrong
thing because the plan will change.
What Makes Planning Agile? More focused on planning than the plan.
Encourages change.
Plans are easily changed.
Plan changes made throughout the project.
The Agile Plan
An Agile plan exists in the form of three backlogs:
1. Product Backlog = Epics and Themes for product
Epics may be sized in “Epic” Story points.
2. Release Backlog = Release Theme and User Stories
User Stories sized in story points during Release
Planning.
3. Sprint Backlog = User Stories and tasks planned for
the Sprint (iteration)
Task sized as part of Sprint Planning.
Planning Process
Product Planning
Stakeholders, Business and Delivery Team build the Product
Backlog. They
Develop Epic User Stories.
Prioritize based on Business Value.
Define Release Themes.
Agile and Lean Handbook Page 28 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Place Epics into releases.
Release Planning
Stakeholders, Business and Delivery Team build the Release
Backlog.
Select Epics & Release Themes for this Release
Create Decision Filters and Billboards as required
Develop User Stories for one release.
Prioritize based on Business Value.
Delivery Team sizes the release content. Estimate the
Story Points for each story in the Release Backlog.
Sprint Planning
In preparation the Product Owner (PO) should select some User
Stories with the highest value from the Release Backlog. PO
should select more than can be delivered in the next iteration
to give the development team some flexibility to optimise their
resources.
Planning Session
Held at the beginning of a new Sprint.
Chaired by the Scrum Master.
Attended by all including Key Stakeholders.
Update the Product Backlog with new User Stories.
ONLY the Delivery Team selects User Stories from
highest priority items in the backlog based on Business
Value and optimisation of team resources for the Sprint.
To complete this activity it is likely that the team will need to
do some architectural work during Sprint Planning. Team
defines and agrees Done, Done, Done (see below) for the
Sprint.
Estimating Approach
Accept uncertainty in requirement detail, size/effort and in
likely delivery velocity.
Size effort in consistent units (Story Points).
Recognise that Story Points cannot reliably be translated
into effort until the development is in progress and
Velocity established for this team and this project.
Estimate just enough to make planning effective.
Planning Poker
An iterative approach to planning:
Team members use planning poker cards to make an
estimate.
Product owner reads and discusses a story.
Each team member selects a card that’s her estimate,
placing it face down.
When all cards are face down, turn them over.
Agile and Lean Handbook Page 29 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Outliers are discussed.
Continue estimating and discussing until consensus
reached.
Using Velocity
Velocity is the average number of Story Points delivered in each
Sprint by this team on this project. Velocity cannot be
compared across teams.
Allows prediction of likely end of the project.
Or how much can be delivered by the target end date.
Where velocity is not acceptable, enables early initiation
of recover actions.
Tracking Progress
As long as stories are really complete (see Done, Done, Done
below) then the project will be complete when all applicable
stories are complete. Since we have Story Point estimates of
the size if the stories we can easily track progress towards the
goal.
Burn Up tracks progress against the total release backlog:
By tracking the burn up in this way we can see what our future
options are.
Done, Done, Done No Severity 1s or Severity 2s.
No Severity 3s or Severity 4s the team has not agreed
to.
Code is unit tested, function tested, system tested,
performance tested, tested end-to-end, and included in
appropriate green threads.
A meaningful stakeholder review has been conducted.
Agile and Lean Handbook Page 30 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Done, Done, Done, Done
Same as Done, Done, Done but in pilot production.
Information Radiators
Use to share and track progress across the team. Typically
contains:
Release Backlog
Sprint Backlog on Sticky Notes
Work in Progress
Work Completed
Current Burn Down or Burn Up Charts
Current Blocks List
Status and Outlook are visible to all.
For Every Sprint
Sprint Containment
Never blow up the sprint. If new stories arise, add them to the
release backlog and consider them in the next sprint planning
cycle.
Daily Stand Up Daily 15 minute status meeting: Time Boxed.
Same place and time every day.
Chaired by Scrum Master.
Attended by entire sprint team.
Others can attend.
Chickens and pigs (only the deliverers speak).
Each team member answers:
Agile and Lean Handbook Page 31 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
What did you do yesterday?
What are you doing today?
What are your blocking issues?
No problem solving! Must stop after 15 minutes to ensure
discipline else meetings will expand to hours.
Scrum Master Records Sprint Backlog up to date.
Scrum Master updates the blocks list.
Information Radiator updated.
Sprint Review Meeting Held the last day of the sprint.
Attended by team.
Team demos “done” user stories to stakeholders.
Requests feedback.
Team holds retrospective. Updates the process for the
next sprint.
Demonstration Only Done, Done, Done working user stories.
Ask for attendance from the following:
Executives
Internal users
Stakeholders
Customers
Early iterations may be unsuitable for customers.
Add or update stories on the Release Backlog.
Retrospective What process steps should we Keep? Drop? Add?
What surprised us?
What was supposed to happen?
What actually happened?
Why were there differences?
What one or two process changes should we make for
the next iteration?
Decision Filters for Process Changes from the
reflection. Does this
o Enable us to deliver more value with our
resources?
o Keep ownership in the team?
o Encourage collaboration & communication?
o Enable us to handle change quickly?
o Build flexibility and enable last responsible
moment decision making?
o Reduce technical debt?
o Help us deliver faster with shorter cycles?
Agile and Lean Handbook Page 32 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
o Remove non-value work?
o Help get more feedback from Customers and
Stakeholders?
o Clearly show honest progress?
o Help us learn more?
The team owns the learning from the retrospective. They do not
have to share it with the rest of the organization.
Agile Highlights Make decisions together to avoid handoffs.
Delivery Team decides how – nothing technical in user
stories.
Cover all types of stakeholders.
It’s all about learning.
Pace yourselves.
Don’t accumulate technical debt.
Beware of chicken subversion.
Getting Started Expect the teams to overestimate in the first few
sprints.
It will take about 5-8 sprints to develop a cadence and
velocity.
Teams may take on too much after some time.
Watch out for anti-bodies.
Things to Consider Management support.
Strong and experienced leader(s).
Picking the right project as a proof point.
Providing the right education, tooling and governance.
Ability to allow change to occur.
Keep it simple.
Agile and Lean Handbook Page 33 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Scrum Process Summary
Product Planning Input Actions Who Output
SOW Develop Release Themes and Epic User
Stories; identify risks and develop risk
mitigation stories
Whole
Team
Product Road Map;
Product Backlog
(includes risks)
Release Planning
Product
Road Map and Backlog
For first release only, develop user
stories with BV; prioritize user stories based on BV (high, medium, low) included on user story
Whole
Team
Prioritized Release
Backlog
Release Backlog
Breakdown user stories to tasks if needed; estimate user stories using
story points, included on user story
Delivery Team
Estimated Release Backlog
Sprint Planning
Prioritized Release
Backlog
Commit to what can be completed in the sprint; define ‘done, done,
done’; identify if an architectural spike is needed
Delivery Team
Sprint Backlog; architectural sprint
backlog (optional); Definition of DONE;
Information Radiator
Sprints
Sprint
Back Log; Def. of DONE; IR
Write test and then code; hold
daily stand ups; update information radiator; continuously integrate code, refactor as
required; remove tech debt
Delivery
Team
User stories that
meet DONE criteria and are ready to be deployed
Demonstration
DONE User
Stories
Demonstrate DONE user stories; get feedback from stakeholders
Whole Team and
Stakeholders
Working software; not DONE user
stories added to Release Backlog
Retrospective
Discuss process changes for next
sprint
Delivery
Team
Changes team
makes to next sprint process
Release Backlog
Re-prioritize backlog based on BV Whole Team
Prioritized Release Backlog
Agile and Lean Handbook Page 34 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Lean Software Development
What is Lean?
A journey, not a destination. A mind
set of continuous focus on:
Deliver continually increasing
customer value.
Expending continually
decreasing effort.
Shortest possible timeframe.
Highest possible quality.
Foundation Principles/Business Goals
Focus all our efforts and resources on creating customer
value by:
Identifying waste, which is anything we do that does not
directly create value.
Eliminating the waste.
The simple test of customer value is whether your customer or
client be willing to pay for it? Anything else is waste.
Continuously remove waste and optimize processes to improve:
Flexibility
Time to Market
Lean is NOT:
Working harder
Working faster
Blaming people
Lean Tools that Work
Agile and Lean Handbook Page 35 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Using the scientific approach and a set of proven tools to
systematically unleash capacity:
Many of our processes contain dormant capacity.
How do we unleash this capacity? By reducing process
waste.
Lean tools identify and reduce process waste. We then
apply this newly unleashed capacity to increase
competitive advantage.
Learn to See and Eliminate Waste
Look at all activities from the Customer Viewpoint. Would
the customer value, and pay for, the artefacts that you are
creating?
Internal paperwork.
Backlog which really only means delivery delay.
Wait Time which is just lost dollars for Client and
Business.
Red tape and Change Control if overly bureaucratic.
Defects.
Extra features.
Product complexity.
Many existing waterfall development processes are actually
counter-productive. The Standish Survey of 2002 showed that
64% of features created in the average solution are rarely
or never used. This represents a huge waste in the
development engine.
Common Wasted Effort
Partially done work
Gets lost: Never used.
Grows obsolete: Never used or has to be reworked.
Hides quality issues: Has not been tested.
Value is unknown.
Churn
Requirements churn: 30-50% waste.
Requirements elaborated long before
development begins (they will change).
Test-and-fix churn: 50% of development effort.
Agile and Lean Handbook Page 36 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Testing long after development.
Delayed integration.
Multiple concurrent API changes.
Over Processing
Making features better than they have to be.
Extra Features
Extra cost
Extra work
Extra cost to maintain
Extra testing
Extra documentation
Extra training
Extra support
Delayed delivery
Common Wasted Time
Wasted time of any sort prevent the customer and the business
from getting value when they want it.
Rework… Due to
False starts
Mistakes
Bugs
Too much detail
Relearning
Make the same mistake again and again.
Excess Movement and Handoffs
Handoffs between process steps, departments and individuals:
Lose key information.
Agile and Lean Handbook Page 37 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Incomplete information available for decisions.
Task Switching
Basically inefficient plus delays delivery.
20-30% time increase to do each task.
Greater loss on complex tasks.
Delays
Waiting for input and decisions.
Not delivering value.
More opportunity for change/rework.
Wasted Effort and Time
Defects
Cost = Impact x time undetected.
Compounded debug complexity.
Extra Processes
Unnecessary paperwork.
Long and complex status reporting.
Poor communication.
Endless meeting paralysis.
“Management” Activities
Staff work.
Can you just look at this?
Agile and Lean Handbook Page 38 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Results in:
Wasted effort
Lost focus
What is the value to customer?
Value Stream Mapping
A simple way to find waste, especially of time in your process
is by drawing value streams.
Value Steams
Make process waste visible.
Replace process emotion with process data.
Show where customer value is created.
Help reduce delivery time to the customer and to the
business.
Process Efficiency = Value added time / Total Cycle
time.
Remember to start and end with the Customer.
Where do we waste the time?
Focus on the Essentials
Cover the BIG picture.
Include steps that deliver value…even if outside your
team’s domain.
One team’s view may not find the best overall
solution and can lead to sub-optimization.
Don’t get bogged down in the detail.
Most typical scenario – avoid outliers.
“Staple yourself” to the process.
Map what happens.
Focus on parts to improve.
Agile and Lean Handbook Page 39 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Value Stream Anti-Patterns
Error Proofing: Build Quality In
Agile and Lean software development is a very rigorous
activity. It is actually impossible to deliver demonstrable
working code on short iterations without effective development
discipline across the team.
Quality is Everyone’s Responsibility, Not Just Test’s.
Keep defect queues and handoffs to a minimum.
Don’t allow defects to occur.
Catch and fix defects immediately after they occur.
No need for defect queue.
Two Kinds of Inspection
1. Inspection to find defects – WASTE.
2. Inspection to prevent defects – Essential.
The Role of QA
Not to swat mosquitos.
Put up screens.
A quality process builds quality into the code. If you routinely
find defects during verification, your process is defective.
Agile and Lean Handbook Page 40 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
4.2 Defects per hour!
Coders introduce bugs at the rate of 4.2 defects per
hour of programming.1
One mistake for every seven to ten lines of code!
Almost one-fifth of those errors are typos.
If you crack the whip and force people to move more
quickly things get even worse.
Foundational Development Disciplines Coding standards
Configuration management
One click build
Continuous integration
Automated testing
Nested synchronization
No partial credit
Foundational Deployment Disciplines Production-hardy code.
Automated release packages.
Automated installation.
4th “Done” means the code is running live in production.
Test Early and Often – Fix Immediately
Every Moment Pair Programming
Auto Tools
Every Few Minutes Unit Tests
Every Day Acceptance Tests
Every Build Submission Unit Tests
Every Week System Tests
Every Iteration Full Regression
Beta Tests
At Each Step of the Process I don’t take junk.
I don’t make junk.
I don’t pass junk on.
Drive Down Technical Debt
Technical Debt: Anything that makes code difficult to change.
1Watts Humphrey, a Fellow of the Software Engineering
Institute, http://www.cs.albany.edu/~csi418/.
Agile and Lean Handbook Page 41 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Complexity
The cost of complexity is exponential.
Regression Deficit
Every time you add new capabilities without tests.
Unsynchronized Code Branches
The longer two code branches remain apart, the
more difficult merging will be.
Quality Debt
The number of unfixed defects in the code making
enhancement difficult.
Quality Tools
Done, Done, Done
Build a quality mindset.
Agree your definition of Done, Done, Done as part of
Sprint Planning.
Suggestion:
o Every User Story is fully developed and fully
tested
o The Sprint has low Technical Debt
No Severity 1s or 2s
Few lower severity defects
Few known design issues
Quality Tool Effectiveness
Continuous Integration
Automating the integration and inspection of software
continuously.
Detect problems early.
Fix errors sooner.
Saves cost.
Agile and Lean Handbook Page 42 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Validates quality.
Continuous Integration Checklist:
Are you builds regular (hourly, nightly, weekly)?
How often is EVERYONE’S code integrated?
How much automated testing is run?
Do you measure coverage?
Are the results posted?
Pair Programming
The most cost effective way of creating clean code.
Can show up to 5% improvement in development time.
Research shows leads to 8-15% less defects.
Keeps programmers focused.
Helps when programmers get stuck.
Avoids mistakes.
Produces better code.
Best way to learn a new code base.
More fun.
But NOT for everyone.
Refactoring
Don’t be afraid to rework existing code when needed.
Keep code base simple.
Avoid and remove code duplications.
Simplicity.
Clarity.
Suitable for use.
No repetition.
No extra features.
Refactoring is not rework!
Outcome of learning.
Cornerstone of improvement.
Builds in the capacity to change.
Doesn’t cost, it pays.
Defer Commitment
Deferring commitment sounds strange but the intent is to
make decisions with the maximum amount of information. It is
important to continue to focus on maximum value for the
business and the customer rather than on meeting an outline
plan. Note that this is not an excuse to fail to meet overarching
Agile and Lean Handbook Page 43 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
business goals. It is essential to enable prioritisation within a
fixed time and resource envelope.
First decide when the decision will be made: i.e.,
“decision height” for pilots.
Don’t make the decision until that time.
That is when you have the most information.
Don’t make the decision after that time.
Because you cannot – it’s too late.
Maintain your options. You don’t know everything yet so
Keep your options open.
Business
Technical
Make decisions reversible where possible.
Get the maximum information possible before making
irreversible decisions.
Make irreversible decisions at the last possible moment.
Deferring commitment requires maintaining options and a
set and team based approach to decisions. Maintain options
wherever change is likely to occur.
Real Options
From Chris Matts.
Real Options have value.
Options expire.
Never commit early unless you know why.
Don’t rush to decision. There are 3 options not 2.
1. The answer is Yes.
2. The answer is No.
3. It is too early to decide.
Define the criteria for making the decision.
A date.
A set of conditions which will tell us when the decision
must be made.
The last responsible moment.
Plans are not commitments. Measuring against the plan drives
the wrong behaviour.
Deliver Fast
Focusing on the speed of delivery of completed elements
delivers maximum results and eliminates wasteful batching.
Focussing on Time will highlight inefficiencies in many parts of
the development process.
This is NOT hack and release.
Must build quality in.
Need engaged people you can trust to make decisions
and help each other.
Agile and Lean Handbook Page 44 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Repeatedly and reliably respond to customer faster than
competitors.
Tools Use the Business Value Model for Release and Sprint
Planning.
Use the Agile practices for rapid, high quality delivery.
Focus on Learning
Agile processes integrate continuous learning both for product
and process. The team must have ownership of its process or
you have given them a get out of jail free card.
No ‘one best way’.
Every process can be improved.
Let the team decide on standards that work for best to
deliver high quality.
Actively Enable Product Learning Early sales
Stakeholder demo
Beta programs
Customer councils
On-site customer
Developer forums
Re-Assess the Plan after Each Iteration What new needs have surfaced?
What technical ideas/issues have we discovered?
What is the feedback from the Demo?
What is the feedback from the early users?
How have our priorities changed?
Actively Enable Process Learning Conduct an effective Reflection.
Look for themes in the Blocks List.
Ask for infrastructure issues.
Experiment with the process.
No sacred cows. Be completely honest.
Re-Assess the Process after Each Iteration Modify the approach or process.
Team feedback that honours the relationship.
Capture Knowledge Concisely
Focus documentation on the user and not the creator.
Use as few words as possible.
A picture is worth a thousand words.
If it doesn’t fit, condense it to smaller sheet!
Dynamic working documents.
Agile and Lean Handbook Page 45 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Obtain feedback and update
Get “Users” to create it.
If it needs continuous update it is at the wrong level.
Write for a well-intentioned knowledgeable person.
Use the 5 Whys
To systematically improve the process and find root causes. Ask
“why” 5 times.
Standardize Work
How? Consistently use the best known practices.
Define and document the best known method.
Make this “the way”.
Make it visual (for example, on the information
radiator).
Revise via reflections and change the standard.
Examples:
Coding standards.
Method for unit testing.
Effective meetings.
Agenda for reflections.
Standard checklist for backlog prioritization.
Standard tools for configuration management.
How It Works Collaboratively define the best, current way to do things.
Do things this way until you define a better, current way
to do things.
Make the standardized work visible.
Use Visual Controls and Information Radiators I can “tell the status by looking”.
The information is current.
The information is meaningful and helps me do my
work.
The information is useful and helps me make better
decisions.
Includes standards.
Focus on Principles Not Detail
Be aware of the need to learn throughout the development
process and work to make that learning effective. Beware of
the temptation to over-document everything. Focus on
principles rather than detail and use page limits to ensure
documentation is at the right level.
Get stakeholder feedback each iteration.
Review the process each iteration and improve it.
Agile and Lean Handbook Page 46 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Process Standards must be continually updated and
changed.
Where problems occur get to the root cause.
Keep documentation simple.
Self-Assessment
Current
Practice
Score
1) How do development
team members know what
customers really want?
# Handoffs
2) How do they get
technical questions
answered?
# Handoffs
3) How do team members
know what to work on
next?
Self-
Direction
1-5
4) How do they know what
defects to work on next?
Self-
Direction
1-5
5) How do development
team members know that
tests are passing?
Easy/Difficult
1-5
6) How do people know
their progress toward
meeting the overall goal of
their work?
Easy/Difficult
1-5
Detailed Documents of Understanding (DOUs) and
contracts are evidence of a lack of trust between parties. This
rarely provides the intended security and reduces the
opportunities for cross-optimisation.
Agile and Lean Handbook Page 47 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Optimise the Whole
Optimising a process across departments and organisations is
challenging. It can only be done if all parties continually focus
on delivering maximum real value to the business.
Tools
Common Sense
Use common sense to remove bottlenecks.
Focus on End to End
Cash flow, not pure cost.
Flexibility for improving effectiveness.
Continuous learning and reflecting.
Move measures UP to avoid sub-optimisation.
Individual department measures cause problems.
Sub optimization.
Conflict between teams.
Recommended Systems Measures Average Cycle Time. Just pick one. For example:
From product concept to first release
From capability request to capability deployment
From defect to patch
Customer satisfaction using Net Promoter Score.
Good both for external customers and for internal
service providers.
Overall Business Value/Cash Flow.
Profit and loss.
Return on investment.
Time to Break Even.
Lean Summary
Theme Takeaway
Eliminate Waste
Defer Commitment
Deliver Fast
See the Whole
Profit = revenue – cost.
Decide as late as possible.
Respond quickly to changes’
The whole is bigger than the sum of
the parts.
and
Build Quality In
Focus on Learning
Stop the line.
Lessons learned and applied.
Agile and Lean Handbook Page 48 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Section 2. Focus and Best Practice
There are many areas to focus on and implement good practice
for Agile. Here we include topics covered in more depth and
practices that teams and leaders may find useful as the
adoption progresses and teams become familiar with the basic
scrum process.
Why Agile Works
Focus on delivery of value above all.
Recognise that each individual and team only works on one
thing at a time; either creating customer value or doing
something else.
Agile and Lean approaches recognize
Flexibility is more important than meeting the original
plan.
Delaying projects is very expensive.
Removing waste allows us to break the triple constraint.
Agile and Lean Handbook Page 49 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Agile Methodologies
XP, Scrum, Lean, RUP, DSDM: A Toolbox NOT a prescription.
Many similar ideas appear in the different approaches.
XP Practices Small releases
Refactoring
Testing/Test-driven
Development
Pair programming
Sustainable pace: 40-hour
week
Team code ownership
Coding standards and
conventions
Simple design
Planning game
Continuous integration/ build
On-site customer
Story Cards Summarize
Requirements
Prototype UIs and UI
navigation
Stand-Up meetings
Workspace environment
Iteration completeness
Architectural spike
Automation
Metaphor (e.g., chalkboard
app)
Scrum
Roles Product
Owner
Scrum
Master Team Stakeholders
Artifacts Product
Backlog
Sprint
Goal
Sprint
Backlog Blocks Increment
Meetings Spring Planning
Meeting Daily Scrum
Sprint Review
Meeting
Lean Eliminate Waste
Build Quality In
Defer Commitment
Deliver Fast
Focus on Learning
Respect People
Optimise the Whole
Agile and Lean are very complementary.
RUP/OpenUp
Agile and Lean Handbook Page 50 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Agile Discipline
In order to rapidly deliver and demonstrate working code
Agile development necessitates greater discipline than
traditional methods.
“Quality” and “Consumability” must be real, not
platitudes.
PatientKeeper = Done, Done, Done, Done It is fully developed.
It is fully tested.
It has no Severity 1s or 2s.
It has been deployed before a release in a client
environment.
They ship
A major release every 3 months.
A minor release every month.
And minor updates once a week.
Self Directed Teams
“When you're in a ‘trusted’ environment, teams tend to
innovate better, more quickly and overall transaction costs are
much lower.”
- Sue McKinney, former VP of Development
The TEAM, not the Manager or PM, owns the delivery.
Individuals on the team select work to do and hold
themselves accountable to the TEAM.
Trust and Ownership Model
Create a culture of trust and help your teams and individuals
take ownership. Be sure that teams are aligned with the goals
of the business. Always deal honestly with ambiguity.
Working with Stakeholders
Many projects fail because of the difficulty in defining project
goals. Stakeholders themselves may be unclear and the
market needs continually change.
Agile approaches insist on continuous re-appraisal of needs
and goals and we need to work to get the best understanding
of stakeholder needs. Here are some techniques:
The demo.
Customer feedback from early programs (Alpha/Beta).
General customer partnerships.
Transplant testing: Use customer data and scenarios in
development.
Reverse transplant: Have developers visit customer and
test there.
Agile and Lean Handbook Page 51 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Stakeholder Goals Document Project overview
Project non-goals
Principals: As-Is Situation, To-Be Goals, Satisfiers
Users: As-Is Situation, To-Be Goals, Satisfiers
Partners: As-Is Situation, To-Be Goals, Satisfiers
Insiders: As-Is Situation, To-Be Goals, Satisfiers
You can weight and prioritise goals using the delivery matrix to
weight Gain and Pain.
Effective Reflections “If you believe that standards are writ in stone, you will fail.
You have to believe that standards are there to be changed”
- Yoshio Shima, Director Toyoda Machine Works
Agile and Lean Handbook Page 52 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Kaizen Create a standard
Follow it.
Find a better way.
How should the standard be created? Clarity
Collaboration and consensus
Establish a best practice.
Document the standard (make it visual if you can).
Train to the method.
Continually refined through reflections
Reflection Approach Owned by the team: data must not be used to
“punish”.
Review the last iteration.
Assess your current chosen process.
Get everyone’s independent input.
Identify just one or two actions to be implemented in
the next iteration.
Carry them out!
Test Driven Development
- Scott Ambler
The Foundation
A commitment to early defect removal. Good testing practices:
An effective Test Automation Framework ideally built
into your IDE.
Good Unit Test coverage.
Daily build regression.
Agile and Lean Handbook Page 53 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Continuous Testing Checklist
1 Nearly every time you compile
Run one minute’s worth of tests
2 Before you check in Run 10 minutes worth
3 Nightly build Run a larger set
4 Before writing any code
Write a failing test, then write the code that makes it work
The Process Write the test case first.
Run the test. It fails.
Write just enough code to pass the test. Then STOP.
Integrate tests and code into system as often as
possible.
Stop the line when build breaks.
Run larger tests overnight.
Run comprehensive tests over the weekend.
Measuring Agile Progress
Be Aware Your instincts are not always a reliable indicator:
always use data.
Green Shift of product status as you move up the
management levels:
We are in deep fertilizer.
The ground is fertile.
There are green shoots.
The garden is blooming.
Understand your stakeholders and your team’s needs.
Validate Your Metrics Select measurements which enable action but do not burden
the team.
Vanity Metrics? Are they actionable?
Are they fully aligned with business needs or are they
potentially misleading?
Can they be gamed or are they truly objective?
Using Metrics Understand how you will use them.
How will action be taken?
Who will take action?
Agile and Lean Handbook Page 54 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Metric Impacts Understand the Impact of using these metrics.
Cost of Collection
Distraction of the team
Misuse
Primary Measure
Remember: Working software is the primary measure of
progress.
Team Metrics Manager Metrics Exec Metrics Sprint burn down Completed User Stories Working software Quality
Sev 1 and Sev 2’s
UT/FT coverage
Successful tests
Technical Debt Deferred User Stories Sprint Velocity Reflection feedback
Release burn up Stakeholder success Actions from Reflections Timely Iteration
completion
Use Information Radiators and simple charts.
Challenges
Work with the team, managers and Execs to address/avoid
these (and similar) challenges:
Basic non-action: “We don’t have time.” or “I have real
work to do.”
Measuring too much or the wrong things.
Satisfying varying needs and goals.
“Done” vs. “Made progress on”.
Ownership confusion: Who is supposed to do what?
Integration with existing solutions.
Measures too complicated or metrics themselves hard to
understand.
Teams without tools.
Key Lessons Implement measures that matter to the team.
Enable their ownership.
Focus on the provision of usable, actionable data.
Metrics without action are pointless.
Good metrics build stakeholder trust and confidence.
If you gather metrics, you must take action otherwise you
are wasting development resources. Be sure that the action is
worth the cost.
Agile and Lean Handbook Page 55 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Technical Debt
Technical Debt is anything in your code that makes it difficult to
make future changes. If you don’t clear technical debt it will
grow each iteration just like a waterfall project.
Done, Done, Done User Stories are complete or not. No partial credit.
No high or medium impact defects.
Minimal known low impact defects.
Any defect deferrals must be agreed to by the whole
team.
All deferrals must be fixed in next iteration (eliminate
Technical Debt).
Expected code reviews should be completed (Fagan,
pair-programming, reviewer/committer model, tools that
reveal differences, etc.).
Expected test automation should be written and
successfully executed.
Necessary manual testing should be completed.
Product documentation should be completed.
The story should be demonstrable and potentially
shippable.
Iterations Complete Test automation coverage targets should be met
Lab provisioning targets should be met
Patent/intellectual property reviews should be completed
Open Source/Certificate of Originality/Non-disclosure
Agreement reviews and requirements should be
completed
Information Radiator (or other tool) should be updated,
and burn down or burn up charts should be completed.
Check progress against quality and business
commitments.
And don’t forget the reflection.
Agile Governance 1. Know that you and your team are in control.
2. Be able to demonstrate that control to someone else.
How Can Audit Help? Help the team understand their governance
responsibilities.
Help the team deliver maximum value with their
resources.
Maximize value delivered.
Minimize their “cost of governance”.
Who Requires Governance Proof? External law, e.g. Safety requirements, IP, COO.
Agile and Lean Handbook Page 56 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Company instructions, e.g. essential records.
Organizational requirements, e.g. corporate mandates or
instructions.
Customer "expectations”/sales requirements, e.g.
documented Design reviews "expected" by 21CFR11
external auditors. It's vitally important to remember
that these are not hard requirements.
Auditor assessments of business impacts and needs. No
defined scope beyond the above.
Agile Enhances Project Governance
What makes good governance?
NOT “Following the Plan”.
A process that demonstrates active control:
Continuous optimisation.
Key records that demonstrate that the process has been
followed: Minimum necessary.
Agile Governance – Simple Understandable
Concise
Requirements Whole Release defined in Epics.
High Level, Stable
Clear focus on Customer Goals – not implementation
details.
Continuous customer feedback and update.
Plan Fixed end date, resources, cost.
Product, Release, and Sprint Backlogs.
Content revisited and agreed each iteration.
Agile and Lean Handbook Page 57 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Progress Each Iteration (2 Weeks) Concrete, visible and demonstrated.
Quality measures (Technical Debt and test progress).
Velocity measured (for team only).
Projection and outlook.
Iteration Records
At Start of Iteration Development Process to be used (one page).
Current candidate list.
At Start of Coding List of prioritized and selected User
Stories/Features to be delivered this iteration.
Latest architecture/model design documents (not
maintained, frozen point in time, NOT auditable).
At End of Iteration Delivered code
Test cases
Reflection/Status
List of User Stories/Features
actually delivered (complete
and tested).
User Stories/Features not delivered
(input to reflection).
Revised development process for
next iteration.
Business Process Changes
Common business processes do not explicitly prohibit flexible
agile approaches, but many have an underlying “waterfall”
assumption.
To move to a fully agile approach we need:
Business processes to encourage or require Agile
A culture shift towards flexibility and agility
Executive behavior changes
Infrastructure modernization
Contracts and Documents of Understanding
Conventional Wisdom Companies and teams inevitably look out for their own
interests.
Contracts and Documents of Understanding are needed
to limit opportunistic behavior.
The Lean Approach Create a partnership.
Agile and Lean Handbook Page 58 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Assume other party will act in good faith.
Let the relationship limit opportunism.
Sometimes is called a Relational Contract.
Align the best interests of each party with the
best interests of the joint venture.
Eliminate conflicts of interest!
Key Process Definitions/Revisions Needed
Revision to Plan Templates.
Remove line item definitions and replace with “Business
Scenarios/User Stories”.
Include committed and candidate items to allow
flexibility.
Define Requirements at a level which is not subject to
detail change.
No Line Items.
Agile Governance Summary
Real Governance Is Enhanced
Validation and Refocus at each iteration leads to:
Delivering maximum customer value within the
project.
Improved quality.
Improved profitability.
Quality Certification is much easier.
TDD and/or Comprehensive Testing
Test Driven Development makes traceability and quality
validation completely automatic.
Detailed Design Documents Detailed design docs are not updated after coding. Code
is the documentation.
Only updated when necessary for a later iteration.
Simple high level Architecture documents at a level that
does not change.
Traditional Audits (e.g. 21CFR11, ISO, etc.) Up to date design docs are an issue [PERIOD] -- both
Waterfall and Agile.
Most teams update design docs after
development.
Focus is on COUNTING things and consistency.
The Bottom Line
Agile ideas have highlighted weaknesses in existing processes
which must be addressed. Agile development does not cause
Agile and Lean Handbook Page 59 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
governance issues it enhances real governance. Existing
Business Processes assume Waterfall but do not prevent Agile
development.
There are infrastructural issues with implementing Agile
development. They can be overcome.
Agile and Lean Handbook Page 60 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Agile for IP Lawyers
Agility requires continuous customer feedback and
demonstrations of working code every few weeks.
In the USA you have one year to register your IP after it is
demonstrated but this is not true in Europe. In Europe the IP is
potentially lost as soon as it is demonstrated.
In the traditional Waterfall IP Processes we have plenty of time
to initiate IP protection before we start the Beta programmes
but this will not work in an Agile project.
IP Lawyers must partner with the delivery team to assess
invention and to initiate protection before any demonstration.
Value stream maps are a useful tool for identifying and
implementing an effective process.
In many teams the scrum master takes the responsibility of
identifying new IP during sprint planning and working with the
IP lawyer to get the protection in place.
Agile and Lean Handbook Page 61 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Agile for Contract Lawyers
Every member of the organisation, including legal
professionals, must work together to deliver a successful
project. Everyone must strive to reduce local optimisations, silo
mentality, and wastes.
The structural and legal aspects of Agile project contracts are
the same as waterfall contracts. However, agile contracts must
employ an understanding of agile delivery in approaches.
Agile approaches reduced client risks compared to what full.
But we must recognise that contracting is an inherently
complicated process.
While the lawyer’s responsibility is to provide a framework to
deal with worst-case outcomes were trust deteriorates, this is
not more important than the overall project success. It does
not imply that the other party is untrustworthy.
In agile projects collaboration is the dominant practice. This
collaboration should be expected in the behaviour of both
parties. It should be incorporated into project assumptions and
expressed in the contract. For example
No fixed, up front “Contract of Requirements”
No “Sign Off” risk transfer
Continuous Learning
Systems Thinking
It is also interesting that the overall goal of the project does not
commonly appear in the top 10 contract terms.
The Agile Contract Covers the same main general areas as a
Waterfall Contract
Risk and Exposure
Flexibility to allow for change
Clarity regarding obligations, deliverables & expectations
But
Helps during project execution not just at project failure
Supports avoiding problems in these areas
Uses Agile approaches to reduce client risk and advance
client interests
Bad Practices – Build Us & Them Competition
Penalties & Incentives
Quality Management Plan – Hurdle Mentality
Document Deliverables List
Sign Offs
Good Practices – Build Collaboration
Simplicity—no performance-based incentives or
penalties
Shared definition of Done, Done, Done
Agile and Lean Handbook Page 62 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
If the customer is extremely dissatisfied with
performance, terminate the engagement at the end of
iteration
Shared pain/gain models
In agile projects change management is inherently addressed
by the agile approach of continuously reprioritising the backlog.
Agile contracts should review early termination as positive and
desirable. Either the business goal was achieved early or the
project has failed early.
Key Elements
Acceptance Continuous throughout the project
Joint Clear Definition of Done, Done, Done
o Include stakeholders
o Include Users
Include as much automation as possible
Liability Reduced by early limited move to production
Warranty Tied to incremental working deliveries
As well as normal overall warranty
Deliverables
Keep to a minimum to avoid
A presumption that you know what is important
Quality Plan hurdles – get past the checkpoint mindset
Reinforcing an illusory Big Bang definition of capability
Reinforcing the illusion of predictability
Treat everything as a prioritized requirement
Payment Timing On iteration completion
Possibly with holdback to intermediate milestones
Pricing T&M works best with incremental delivery
Variations
o Capped per iteration ( with possible sequential
variation )
o Capped per project or release
Fixed price per iteration
Value or Function Point based
Shared gain/pain models
Example Contract Models Fixed Price, Fixed Duration, Variable Scope
Agile and Lean Handbook Page 63 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Progressive – T&M per Iteration, Release Cap, Non-
Binding Backlog, Fixed Duration
Fixed Price, Fixed Scope – Variable Duration
Target Cost & Target Profit
Shared Gain/Pain 50% Slope
Agile and Lean Handbook Page 64 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Agile Infrastructure
To allow teams to be maximally effective the surrounding
infrastructure must be fully committed to helping them
succeed. Processes must help the team, not take ownership
away from the team.
All elements of organisational infrastructure must be re-
focussed on enabling teams to maximise Business Value
delivered by their scarce resources.
Inhibitor
Unfortunately, most of our processes and practices, most of our
experiences and expectations, and most of our norms assume a
waterfall delivery.
Assess the Organisational Infrastructure
Prohibit Inhibit Permit Encourage Require
Does not allow
Agile
approaches to
be used.
Agile approaches
are permitted but
at the cost of
additional effort
from the team.
Agile approaches
are allowed
without
additional effort.
Agile approaches
are encouraged
and effort is
reduced vs.
waterfall.
Agile
approaches
are required.
Challenging Infrastructure Areas Legal/IP approvals
Open Source License check
Globalization/
Translation
Technical architectural
integration
Functional organisations
IS operations
Capital process
Finance process
Business process
Business controls
Procurement
Audit
Product Owner
Quality planning
Human Resources
The Infrastructure Can Help
Enable, support and encourage agility and customer focus.
Iterative Deliver value in small chunks.
Minimum viable.
Production quality.
Agile Continuous learning.
Continuous focus on customer value.
Continuous focus on process improvement.
Agile and Lean Handbook Page 65 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Lean Remove all wasted effort and time.
Focus on cash flow (speed).
Optimize across the organization.
Collaboration Build ownership in the team.
Lead, don’t manage.
Support the team.
Work together to deliver.
The Leader’s Role Enable the team.
Help them overcome infrastructure issues.
Help them achieve maximum effectiveness.
Agile and Lean Handbook Page 66 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Agile Behaviours
Moving to Agile requires behaviour changes from all players,
particularly leaders.
Leaders Stakeholders and Business Leaders
Managers
Project and Delivery Managers
Architects and Senior Technical Professional
Professionals Quality Engineers
Stakeholder and Business Leader Example Understand and promote the value of Agile and Lean
development.
Focus on the business goals and value not the
implementation.
Recognize the cost of delay.
Staff the teams with all key players. Build real
ownership in the teams.
Focus on delivering value to the customer and to the
business as rapidly as possible.
Define requirements in terms of key business goals and
user stories at a level that will not change.
Insist your teams to take a time-boxed iterative
approach to development.
Insist that each iteration is fully complete and stable
with few if any open defects.
Recognize content will always evolve. Raise questions if
it does not.
Do not delay any checkpoint or milestone because not
every issue is closed.
Trust and empower the team to make rapid decisions in
line with the committed goals.
Take an active part in the Demo and Stakeholder
feedback.
Fix the infrastructure to enable Agile delivery.
Agile and Lean Handbook Page 67 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Multi-Site Development
Development across multiple sites creates challenges we must
honestly accept and address:
Lack of shared vision between sites which may have
different goals.
Us and Them: a risk of a blame culture arising.
Power Distance: when “junior” locations are unwilling to
raise issues and questions.
Hand-Offs are made more difficult and time consuming.
Communication delays rise as more communication is
asynchronous via email and tracking/library tools.
Exploratory interaction is lost.
Distributed Teams
The first and most powerful factor is awareness of the issue.
Once this is understood by all team members, leaders can help
the team address them by:
Building aligned vision and goals.
Focus especially on cultural differences where
teams are in different countries.
Personal relationships across teams.
Helping sort out the communications.
Video
Audio
Community space
Creating a clear organization and structure understood
by all. Clear responsibilities and authorities for each
team.
Inter-team.
Project Management/Co-ordination: "Scrum of
Scrums".
Team to team technical interfaces.
Overall status reporting.
Use common tools.
Development
Communications
Increase frequency of integration.
Set up alert system.
Encourage non-confrontational issue raising.
Poll for every voice.
Tips and Tools - Communicate A Scrum Master at each site.
Scrum of Scrums (or equivalent).
Product Owner is available for some time to each team.
Agile and Lean Handbook Page 68 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Post PO availability time and contact, set up
Office Hours.
Co-locate entire team for one sprint.
Project wide wiki.
Encourage informal communications across members of
distributed teams.
Scrum of Scrum meeting rotates the time zone meeting
time.
Create a “community of practice” across geography
teams to share resources.
Multiple Interlocking Teams Define a process for making decisions.
Sync the sprints on the same timeframe.
Scrum of Scrums with Development Managers as well as
Scrum Masters.
Create a communications plan and process.
Agile and Lean Handbook Page 69 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Large Scale Agile
Large Scale Projects are difficult whether Agile or Waterfall.
Don’t focus on “agility” in the abstract. Focus on the actual
practices. Most of the Agile practices and tools are applicable to
large projects.
Large Projects Structure the projects to minimize interfaces and
hand-offs.
Try to give individual teams’ full responsibility for
what they do.
Use “Scrum-of-Scrums” but not in a dogmatic way.
Use Scrum Masters to co-ordinate the teams. Focus
on interdependencies and exceptions not
“management”.
Agile Works for Large Projects
Don’t get hung up on the labels. Consider the Agile practices
and determine which are appropriate.
What Scales in Lean?
1. Eliminate Waste
Extra features
Churn
Avoid hand-Offs
2. Build Quality In
Mistake-Proof code with Test-Driven Development
Stop building legacy code
The Big Bang is obsolete
3. Defer Commitment
Break dependencies
Maintain options
Schedule irreversible decisions at the last possible
moment
4. Deliver Fast
Rapid delivery, high quality, and low cost are fully
compatible
Queuing Theory applies to development, not just servers
Limit work to capacity
5. Create Knowledge
Use the Scientific Method
Standards exist to be challenged and improved
Predictable performance is driven by feedback
6. Respect People
Teams thrive on pride, commitment, trust, and applause
Provide effective leadership
Agile and Lean Handbook Page 70 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Respect partners
7. Optimize the Whole
Focus on the entire Value Stream
Deliver a complete product
Measure UP
Challenges to Address Architectural Coordination
Empowered Architects make up an Architecture
Board.
Documentation
Where possible keep within the team and within the
code.
Have Architecture Board create concise overviews.
Otherwise have documents created by those who will
use them.
Cultural and Organizational Differences
Make a special effort to be aware of differences.
Use collaborative tools to come to a common vision
and approach.
Consciously work to build bridges between teams.
Planning and Coordination
Senior leaders build a common vision and goals.
Try to limit deep integration.
Define plans and manage as flexibly as possible.
Effective Mitigations Pay special attention to project start.
Common goals and vision centrally posted.
Active local Stakeholders.
Build a common culture and standards.
Make short iterations.
Break effort into smaller pieces.
Always over-communicate.
Electronic solutions and tools for remote working.
Automate as much as possible.
Common tools and infrastructure.
Self-Contained teams (7 to 15 per team is ideal).
Own things by geography.
Working integration at regular intervals.
Leading Agile Teams
Leader’s Role Enable the team.
Help them overcome the infrastructure issues.
Help them achieve maximum effectiveness.
Collaborative Leadership Model Create an Open Environment.
Agile and Lean Handbook Page 71 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Get the right people.
Foster innovation.
Step back and let them work.
Collaboration Process Agree goals and objectives.
Brainstorm with Sticky Notes.
Group in silence.
Prioritize based on Business Value.
Individuals volunteer for what and by when.
Leading Collaborative Teams Team defines success.
Team decides how to hold each other accountable.
Trust First!
Accept failure.
Remove all blame.
Free the team to analyze and investigate.
Help through asking questions.
Agile Project Management
Product Managers, Product Owners, and Scrum Masters are
facilitators. Don’t take ownership away from the team.
Principles
Continuous flow of value.
Engage customers.
Create an environment where individuals can make a
difference.
Expect uncertainty and manage for it.
Context specific strategies, processes, and practices.
Group accountability.
How Can the Leader Help?
What to Do Understand why Agile works.
Staff the team effectively.
Support the team but give them ownership.
Help the team optimize their own performance.
Help the team decide their own tasks.
Call out parochial and narrow behaviors.
Keep the team honest by asking questions.
Demand flexibility and learning during development.
Enable the team to build strong relationships with
Stakeholders.
Enable the team to define requirements using Business
Values and Epic User Stories.
Continuously reinforce the project vision and goals.
Help the team get early customer feedback.
Help the team address infrastructure issues.
Agile and Lean Handbook Page 72 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
What to Avoid Sharing resources across teams or projects.
Multitasking.
What Not to Do Define the goals for the team.
Direct individual tasks and goals.
Demand spurious precision in plans.
Go for Big Bang delivery.
Ask for documentation for review and signoff.
“Manage” the delivery team.
Step by Step
Overall Planning At the Beginning of the Project Your goal is to ensure that the team understands the
business vision of the need and can take ownership of
delivery.
Enable the team and stakeholders to develop the
requirements as:
Business Goals
Epic User Stories
Non-Goals
Accept “first approximation” estimates of effort
and schedule. Challenge Spurious Precision
wherever you see it.
Press for incremental delivery.
Small releases with minimum viable capabilities.
Short iterations.
Release Planning At the Start of Each Small Release Your goal is to ensure that the team understands the
Business vision of the need and can take ownership of
delivery.
Enable the team to break Epic User Stories down into
User Stories.
Encourage clearly define release non-goals.
Ask questions to guide the team without taking
ownership away from them.
Accept “first approximation” estimates of effort and
schedule.
Challenge Spurious Precision wherever you see it.
Sprint Planning (Every 2 weeks) Help the stakeholders to prioritize a maximum of 2
iterations worth of work as input to the Iteration
Planning activity.
Enough to ensure that the team can be fully loaded.
Agile and Lean Handbook Page 73 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Ask questions to guide the team without taking
ownership away from them.
Help the team define Done, Done, Done for this
iteration. Press for high standards.
Look for team over-commitment and challenge it.
During the Sprint If you want status, listen in at the Scrum Meetings.
Help the team address any blocking issues outside
their capability.
Be available for any help they need.
Stand Back!
Do not allow the business to add new requirements to
impact this iteration.
Add new User Stories to the Backlog.
Do not agree to the Time Box being compromised.
At the End of the Iteration Attend the Demo.
Give constructive feedback.
Ask for the Done, Done, Done status.
Look at the Velocity.
Ask if they are on track to meet the business
goals.
Ask if you will ever have enough value to deliver.
Look at the reflection if the team wants to share the
results.
Ask (but do not “approve”) what process
improvements they will make for the next
iteration.
Ask how you can help.
Continuously Communicate the project vision of success
Help remove any and every obstacle to delivery
Infrastructure Issues
Non-Productive Work
Help the team get access to future users
For discussions
For feedback on early deliveries
Build ownership in the teams
Remember
Agile is a learning process.
There are NO hard and fast rules.
Focus on overall effectiveness.
Tailor to your specific circumstances.
Agile and Lean Handbook Page 74 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
The Agile Development Manager As many teams worry about the role of the Development
Manager in an Agile Self-Organising environment here are a
few pointers. The significant difference is that we expect the
first line manager to act in the same way as more senior
management in the past. That is, they work through leadership
goal setting and influence rather than command and control
Note that the actual activities independent on the actual
structure of the teams in place.
Dev Manager Behaviours Leads – Does not Manage
Builds Ownership
Shares the Vision
Trusts the Team
Guides by Questions
Builds Ownership in the Team With the PO Builds & Share the Project Vision
Helps the Team understand the Project Goals and
Business Value
Removes Learned Helplessness
Builds a Sense of Urgency
Helps the team understand their results
Prevents Chicken Subversion
Stays Outside the Team Boundaries. The Macro
Leadership Cube is a useful tool here
Builds a Culture for the Team to Succeed Creates a Culture of Trust
Builds Pride in Work
Removes Fear
Focuses on Learning not Blame
Ensures Individuals Feel Valued
Protects the Team
Creates a Safe Place to Fail Learn
Builds Team Capabilities Educates, Encourages & Enables Practice Excellence
Sets Standards and Expectations
Ensures Sustainable Pace
Provides Honest Feedback
Coaches & Counsels
Enables Sharing of Best Practice and Experience
Creates an Environment for the Team to Succeed Gathers Team Resources
Delivers Tools and Environments
Provides Test Systems & Equipment
Builds Effective Communications
Removes Organisational Blocks Legal / IP Approvals
Open Source Risks
Agile and Lean Handbook Page 75 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Globalization / Translation
Architectural Integration
Independent Support Organisations
IS Operations
Capital Process
Finance Process
Business Process
Business Controls
Procurement
Audit
Human Resources
Helps the Scrum Master Remove Project Blocks Cross-Team Issues
Risk Management
Pervasive
Specific
Dependencies
Stop Doing Command & Control
Many traditional Management practices are based on Command
& Control principles. Here are some examples of things to stop
doing.
Deciding what work needs to be done
Assign work to Team Members
Keeping track of what everyone is doing
Making sure the Team gets their work done
Making commitments to “Management” on what can be
done by when
Being responsible for the Team meeting commitments
Weekly status report for “Management”
Weekly project meetings
Agile and Lean Handbook Page 76 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Getting Started
Considerations Management Support
Strong and Experienced Leader(s)
Picking the right project as a proof point
Providing the right education, tooling and governance
Ability to allow change to occur
Keep it Simple
Before Sprints Begin
Release Planning:
Product Backlog (Epic User Stories)
Release Themes
Release Backlogs (User Stories)
Iteration/Sprint Planning:
Sprint Backlog
Information Radiator
Release Planning
Form User Story Team to create Product Backlog:
Develop Release Themes.
Create Epic User Stories for each release.
Or:
Create Epic User Stories for product.
Put Epics into releases.
Define Release Themes.
For the next Release:
Break Epic User Stories into User Stories (by User Story
Team).
Estimate the Story Points for each user story (by cross-
discipline Scrum Team).
Scrum Team determines “Done, done, done” for each
user story.
On 3x5 Sticky Notes include:
User Story
Acceptance Criteria (record elsewhere)
Business Value (High, Medium, Low)
Differentiating or Parity
Story Points
Prioritize based on:
User stories of highest business value to
stakeholders.
Agile and Lean Handbook Page 77 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Risky user stories for development (technology
challenges, size of work required, etc.).
Give special consideration to:
Installation - working installer early in cycle
allows all teams to move faster
Migration - often difficult to build, and is usually
critical to customers
For Every Sprint (at Sprint Planning) Identify a Sprint goal.
Select highest priority User Stories from Release Backlog
to reach that goal.
Product Owner works with scrum team to select user
stories from the product backlog for each iteration.
Team may want to break down stories into:
Smaller User Stories.
Or Tasks (all tasks must be done to demo
User Story).
Place all sprint stories onto the Information Radiator
under Work Planned column.
Our Experience Expect the teams to overestimate in the first few
sprints.
It will take about 5 sprints to develop a cadence.
Teams may take on too much after some time.
Section 3. References
What is Agile and Why It Works
Quick Read
“What Is Agile Software Development?” Jim Highsmith,
CrossTalk, the Journal of Defence Software Engineering
“The New Methodology”, Martin Fowler
http://martinfowler.com/articles
“Why Agile” (video) http://www.universite-du-
si.com/fr/conferences/6/sessions/909
“The Agile Manifesto”,
http://agilemanifesto.org/principles.html
“Agile Study Confirms Benefits”,
http://www.projectsatwork.com/article.cfm?ID=274674
andauthenticated=1
Agile In General
Online Resources Agile Alliance
http://www.agilealliance.org/
Agile and Lean Handbook Page 78 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
They have a full list of active user
groups with contact information to
find a user group near you.
Agile Leadership Network
http://www.agileleadershipnetwork
.org/
The Role of the Product Owner and
a great summary of Agile
approaches.
https://www.youtube.com/watch?v
=502ILHjX9EE
Online Magazines http://www.infoq.com
http://www.stickyminds.com
http://www.projectsatwork.com/
http://www.agileconnection.com/
Online User Groups Agile and Lean Software
Development
https://www.linkedin.com/groups/
Agile-Lean-Software-Development-
37631?home=andgid=37631andtrk
=anet_ug_hm
Agile Coaching
https://www.linkedin.com/groups?
home=andgid=114569andtrk=anet
_ug_hm
Agile Project Management
https://groups.yahoo.com/neo/gro
ups/agileprojectmanagement/info
Agile Business Analyst
https://www.linkedin.com/groups?
home=andgid=1916699andtrk=an
et_ug_hm
Using the Kanban Method
https://groups.yahoo.com/neo/gro
ups/kanbandev/info
Agilistas
https://www.linkedin.com/groups/
Agilistas-
43421?home=andgid=43421andtrk
=anet_ug_hm
Lean Agile Software Development
Community
https://www.linkedin.com/groups/
Agile and Lean Handbook Page 79 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Lean-Agile-Software-Development-
Community-
1024087?home=andgid=1024087a
ndtrk=anet_ug_hm
Agile Leadership Network
http://www.linkedin.com/groups?h
ome=andgid=37413andtrk=anet_u
g_hm
Dive Into Scrum
Quick Read
http://scrumalliance.org/pages/what_is_scrum
Scrum and XP from the Trenches, Henrik Kniberg
http://www.infoq.com/minibooks/scrum-xp-from-the-
trenches
Deep Dive
Agile Software Development with Scrum, Ken Schwaber
and Mike Beedle (when learning Agile)
Agile Project Management with Scrum, Ken Schwaber
(experienced with Agile)
The Elegant Solution, Matthew May
Outside-in Software Development, Carl Kessler and John
Sweitzer
User Stories
Quick Read
“Agile Project Planning: Writing Good User Stories”
http://www.extremeplanner.com/blog/2006/01/writing-
good-user-stories.html
Deep Dive
User Stories Applied for Agile Software Development,
Mike Cohn
Agile Estimating and Planning
Tool for Estimating and Planning in distributed environments
http://planningpoker.com/
Quick Read
http://www.mountaingoatsoftware.com/articles
Agile and Lean Handbook Page 80 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
Deep Dive
Agile Estimating and Planning, Mike Cohn
Business Value Model
Quick Read
“In Pursuit of the Moving Target: Business Value” Niel
Nickolaisen and Pollyanna Pixton
Deep Dive
Stand Back and Deliver: Accelerating Business Agility,
Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent
McDonald.
Agile Best Practices
Quick Read
Guidelines for Test Driven Development:
http://msdn.microsoft.com/en-
us/library/aa730844%28VS.80%29.aspx
Deep Dive
Test Driven Development by Example, Kent Beck
Leading Agile
Quick Read
“Creating Trust: It's Worth the Effort” Great Place to
Work Institute whitepaper,
http://accelinnova.com/docs/creating_trust.pdf
“How I Learned to Let My Workers Lead” Ralph Stayer,
CEO, Johnsonville Foods, Harvard Business Review,
http://accelinnova.com/docs/workers_lead.pdf
“Ricardo Semler Won't Take Control” Lawrence M. Fisher
interview, strategy+business,
http://accelinnova.com/docs/semler_nov_07.pdf
“Collaborating with Non-Collaborators” Kent McDonald
and Todd Little, projectconnections.com,
http://blog.projectconnections.com/kent_mcdonald/201
1/05/collaborating-with-non-collaborators.html
Agile and Lean Handbook Page 81 of 81
©2014 all rights reserved, Accelinnova, LLC Accelinnova.com/agileleanrisk.html
“The Operating Model That Is Eating the World”, Arron
Dignan, https://medium.com/on-
management/d9a3b82a5885
Deep Dive
The Agile Culture: Leading Through Trust and
Ownership, Pollyanna Pixton, Paul Gibson, Niel
Nickolaisen
Lean Approaches
Quick Read
“Beyond Toyota: How to Root Out Waste and Pursue
Perfection”, James Womack and Daniel Jones, HBR Sept-
Oct 1996
“Decoding the DNA of the Toyota Production System”,
Steven Spear and H. Kent Bowen, HBR, Sep-Oct 1999.
Deep Dive
Lean Software Development, Mary and Tom Poppendieck
Implementing Lean Software Development, Mary and
Tom Poppendieck, Addison-Wesley
Leading Lean Software Development, Mary and Tom
Poppendieck, Addison-Wesley
http://www.poppendieck.com
Toyota Production System, Taiichi Ohno, Productivity
Press
Software by Numbers, Mark Denne and Jane Cleland-
Huang, Prentice Hall
Error Proofing: Build Quality In
Deep Dive
Working Effectively with Legacy Code, Michael Feathers
Fit for Developing Software, Mugridge and Cunningham