agile and lean - accelinnova · lean software development ... there is much confusion and...

2015

Accelinnova.com

1/18/2015

Agile and Lean Handbook

Agile and Lean Handbook of 81

©2015 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



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



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



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 ............................................................ 78

Dive Into Scrum ............................................................ 78

User Stories ................................................................. 79

Agile Estimating and Planning ......................................... 79

Business Value Model .................................................... 79

Agile Best Practices ....................................................... 80

Leading Agile ................................................................ 80

Lean Approaches ........................................................... 80

Error Proofing: Build Quality In ....................................... 81



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.



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.



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.



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



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).



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.



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.



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.



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



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



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.

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.

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.



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



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.



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



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.



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>.



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.



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



Then: System displays: “You provided an incorrect

password”



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.



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.


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.



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.



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:



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?



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.



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



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



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.



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.



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?



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.



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.



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/.



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.



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



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.



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.



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.



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.



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.



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 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 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.



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



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.



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?



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.



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.



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.



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.



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



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 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 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



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



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 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.



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 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.



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

Email

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.



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.



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



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.



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.


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.



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.



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.



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



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



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.



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

http://agilemanifesto.org/principles.html



Agile In General

Online Resources Agile Alliance http://www.agilealliance.org/

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=11456

9andtrk=anet_ug_hm

Agile Project Management

https://groups.yahoo.com/neo/groups/agileprojectmana

gement/info

Agile Business Analyst

https://www.linkedin.com/groups?home=andgid=19166

99andtrk=anet_ug_hm

Using the Kanban Method

https://groups.yahoo.com/neo/groups/kanbandev/info

Agilistas https://www.linkedin.com/groups/Agilistas-


Lean Agile Software Development Community

https://www.linkedin.com/groups/Lean-Agile-Software-

Development-Community-


Agile Leadership Network

http://www.linkedin.com/groups?home=andgid=37413a

ndtrk=anet_ug_hm

Dive Into Scrum

Quick Read

https://www.scrumalliance.org/why-scrum

http://www.agilealliance.org/

http://www.agileleadershipnetwork.org/

https://www.youtube.com/watch?v=502ILHjX9EE

http://www.infoq.com/

http://www.stickyminds.com/

http://www.projectsatwork.com/

http://www.agileconnection.com/

https://www.linkedin.com/groups/Agile-Lean-Software-Development-37631?home=&gid=37631&trk=anet_ug_hm



https://www.linkedin.com/groups?home=&gid=114569&trk=anet_ug_hm


https://groups.yahoo.com/neo/groups/agileprojectmanagement/info

https://groups.yahoo.com/neo/groups/agileprojectmanagement/info



https://groups.yahoo.com/neo/groups/kanbandev/info

https://www.linkedin.com/groups/Agilistas-43421?home=&gid=43421&trk=anet_ug_hm

https://www.linkedin.com/groups/Agilistas-43421?home=&gid=43421&trk=anet_ug_hm

https://www.linkedin.com/groups/Lean-Agile-Software-Development-Community-1024087?home=&gid=1024087&trk=anet_ug_hm



http://www.linkedin.com/groups?home=&gid=37413&trk=anet_ug_hm

http://www.linkedin.com/groups?home=&gid=37413&trk=anet_ug_hm

https://www.scrumalliance.org/why-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

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

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

http://planningpoker.com/



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

“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

http://accelinnova.com/docs/creating_trust.pdf

http://accelinnova.com/docs/workers_lead.pdf

http://accelinnova.com/docs/semler_nov_07.pdf

http://blog.projectconnections.com/kent_mcdonald/2011/05/collaborating-with-non-collaborators.html



“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

http://www.poppendieck.com/