2015 Agile and Lean Handbook

Accelinnova.com 1/18/2015

Agile and Lean Handbook

Page 2 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 3 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 4 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 5 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 6 of 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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 7 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 8 of 81

Section 1. Agile and Lean Workshop In the 1. 2. 3. 4. 5.

course, we cover the following topics: Agile and Lean Introduction Decision Making based on Business Value Dive into Scrum Agile Estimating and Planning 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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Facing   

Page 9 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook



Page 10 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 11 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

   

Page 12 of 81

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 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 Working software Customer collaboration Responding to change

over processes and tools over comprehensive docs over contract negotiation 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 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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

 

   

Page 13 of 81

The most efficient and effective method of conveying information to and within a development team is faceto-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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 14 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 15 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 16 of 81

The Model gives guidance about where the team should be investing and how to get maximum Business Value from that investment.

Differentiating Rules Rules Always Be the Market Leader Focus Own Differentiating Parity Rules Rules Fill Any Gaps Because Gaps Kill Eliminate Risks Because Risks Kill Create Capacity To Focus Resources on Innovation

How? Innovate now and? forever Have 1-3 specific things you do better than anyone else You cannot outsource your innovation How? Adopt Best Practices – adopt the innovation of market leaders Simplify – complexity increases risks and reduces agility 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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

 

Page 17 of 81

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?

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

    

Page 18 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 19 of 81

Dive Into Scrum Scrum is a team based software development project management model developed by Jeff Southerland. Learn more at scrumalliance.org.

Roles Artefacts Meetings

Product Owner

Scrum Master

Team

Stakeholders

Product Release Sprint Blocks Information Backlog Backlog Backlog List Radiator Release Spring Daily Sprint Review Planning Planning Scrum Meeting Meeting 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 with:    

roadmap and prioritizes user stories in collaboration Business Leaders Stakeholders Scrum Master Functional representatives from team

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 20 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 21 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

    

Page 22 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 23 of 81

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 I want so that .

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 24 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 25 of 81

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  When  Then Example:  Given: User account exists in system  When: User enters existing user name and incorrect password

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook



Page 26 of 81

Then: System displays: “You provided an incorrect password”

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 27 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook



Page 28 of 81

Place Epics into releases.

Release Planning Stakeholders, Business and Delivery Team build the Release Backlog.  Select Epics & Release Themes for this Release  Create Decision Filters and Billboards as required  Develop User Stories for one release.  Prioritize based on Business Value.  Delivery Team sizes the release content. Estimate the Story Points for each story in the Release Backlog.

Sprint Planning In preparation the Product Owner (PO) should select some User Stories with the highest value from the Release Backlog. PO should select more than can be delivered in the next iteration to give the development team some flexibility to optimise their resources. Planning Session  Held at the beginning of a new Sprint.  Chaired by the Scrum Master.  Attended by all including Key Stakeholders.  Update the Product Backlog with new User Stories.  ONLY the Delivery Team selects User Stories from highest priority items in the backlog based on Business Value and optimisation of team resources for the Sprint. To complete this activity it is likely that the team will need to do some architectural work during Sprint Planning. Team defines and agrees Done, Done, Done (see below) for the Sprint.

Estimating Approach Accept uncertainty in requirement detail, size/effort and in likely delivery velocity.  Size effort in consistent units (Story Points).  Recognise that Story Points cannot reliably be translated into effort until the development is in progress and Velocity established for this team and this project.  Estimate just enough to make planning effective.

Planning Poker An iterative approach to planning:  Team members use planning poker cards to make an estimate.  Product owner reads and discusses a story.  Each team member selects a card that’s her estimate, placing it face down.  When all cards are face down, turn them over.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

 

Page 29 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 30 of 81

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:

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

  

Page 31 of 81

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?

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

o o o o

Page 32 of 81

Remove non-value work? Help get more feedback from Customers and Stakeholders? Clearly show honest progress? 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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 33 of 81

Scrum Process Summary Product Planning Input SOW

Actions Develop Release Themes and Epic User Stories; identify risks and develop risk mitigation stories

Release Planning Product For first release only, develop user Road Map stories with BV; prioritize user and stories based on BV (high, medium, Backlog low) included on user story Release Breakdown user stories to tasks if Backlog needed; estimate user stories using story points, included on user story Sprint Planning Prioritized Commit to what can be completed Release in the sprint; define ‘done, done, Backlog done’; identify if an architectural spike is needed

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

Demonstration DONE Demonstrate DONE user stories; User get feedback from stakeholders Stories Retrospective Discuss process changes for next sprint Release Backlog

Re-prioritize backlog based on BV

©2015 all rights reserved, Accelinnova, LLC

Who Whole Team

Output Product Road Map; Product Backlog (includes risks)

Whole Team

Prioritized Release Backlog

Delivery Team

Estimated Release Backlog

Delivery Team

Sprint Backlog; architectural sprint backlog (optional); Definition of DONE; Information Radiator

Delivery Team

User stories that meet DONE criteria and are ready to be deployed

Whole Team Working software; and not DONE user Stakeholders stories added to Release Backlog Delivery Team Whole Team

Changes team makes to next sprint process Prioritized Release Backlog

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 34 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 35 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 36 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook



Page 37 of 81

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?

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 38 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 39 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 40 of 81

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.

Watts Humphrey, a Fellow of the Software Engineering Institute, http://www.cs.albany.edu/~csi418/. 1

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook



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

Page 41 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook



Page 42 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 43 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook



Page 44 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

  

Page 45 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

  

Page 46 of 81

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?

SelfDirection 1-5

4) How do they know what defects to work on next?

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 47 of 81

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

Profit = revenue – cost.

Defer Commitment

Decide as late as possible.

Deliver Fast

Respond quickly to changes’

See the Whole

The whole is bigger than the sum of the parts.

and Build Quality In

Stop the line.

Focus on Learning

Lessons learned and applied.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 48 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 49 of 81

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 Metaphor (e.g., chalkboard app)

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

Scrum Product Owner

Roles

Scrum Master

Artifacts

Product Backlog

Sprint Goal

Meetings

Spring Planning Meeting

Team

Sprint Backlog Daily Scrum

Stakeholders

Blocks

Increment

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 50 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 51 of 81

Stakeholder Goals Document      

Project overview Project non-goals Principals: As-Is Users: As-Is Partners: As-Is Insiders: As-Is

Situation, Situation, Situation, Situation,

To-Be To-Be To-Be To-Be

Goals, Goals, Goals, Goals,

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 52 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 53 of 81

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?

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 54 of 81

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 Exec Metrics Metrics Sprint burn down Technical Debt Release burn up Completed User Stories Deferred User Stories Stakeholder success Working software Sprint Velocity Actions from Quality Reflection feedback Reflections Timely Iteration  Sev 1 and Sev 2’s completion  UT/FT coverage  Successful tests 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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 55 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

  



Page 56 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 57 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

 

Page 58 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 59 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 60 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 61 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook





Page 62 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

   

Page 63 of 81

Progressive – T&M per Iteration, Release Cap, NonBinding Backlog, Fixed Duration Fixed Price, Fixed Scope – Variable Duration Target Cost & Target Profit Shared Gain/Pain 50% Slope

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 64 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 65 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 66 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 67 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 68 of 81



    

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 69 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook



Page 70 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

  

Page 71 of 81

Get the right people. Foster innovation. Step back and let them work.

Collaboration Process     

Agree goals and objectives. Brainstorm with Sticky Notes. Group in silence. Prioritize based on Business Value. Individuals volunteer for what and by when.

Leading Collaborative Teams       

Team defines success. Team decides how to hold each other accountable. Trust First! Accept failure. Remove all blame. Free the team to analyze and investigate. Help through asking questions.

Agile Project Management Product Managers, Product Owners, and Scrum Masters are facilitators. Don’t take ownership away from the team. Principles  Continuous flow of value.  Engage customers.  Create an environment where individuals can make a difference.  Expect uncertainty and manage for it.  Context specific strategies, processes, and practices.  Group accountability.

How Can the Leader Help? What to Do             

Understand why Agile works. Staff the team effectively. Support the team but give them ownership. Help the team optimize their own performance. Help the team decide their own tasks. Call out parochial and narrow behaviors. Keep the team honest by asking questions. Demand flexibility and learning during development. Enable the team to build strong relationships with Stakeholders. Enable the team to define requirements using Business Values and Epic User Stories. Continuously reinforce the project vision and goals. Help the team get early customer feedback. Help the team address infrastructure issues.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 72 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

  

Page 73 of 81

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.

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 74 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

          

Page 75 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 76 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

 

Page 77 of 81

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook

Page 78 of 81

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-SoftwareDevelopment37631?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/Agilistas43421?home=andgid=43421andtrk=anet_ug_hm Lean Agile Software Development Community https://www.linkedin.com/groups/Lean-Agile-SoftwareDevelopment-Community1024087?home=andgid=1024087andtrk=anet_ug_hm 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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook



Page 79 of 81

Scrum and XP from the Trenches, Henrik Kniberg http://www.infoq.com/minibooks/scrum-xp-from-thetrenches

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

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook



Page 80 of 81

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/enus/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/onmanagement/d9a3b82a5885

Deep Dive  The Agile Culture: Leading Through Trust and Ownership, Pollyanna Pixton, Paul Gibson, Niel Nickolaisen

Lean Approaches Quick Read

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html

Agile and Lean Handbook





Page 81 of 81

“Beyond Toyota: How to Root Out Waste and Pursue Perfection”, James Womack and Daniel Jones, HBR SeptOct 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 ClelandHuang, Prentice Hall

Error Proofing: Build Quality In Deep Dive  Working Effectively with Legacy Code, Michael Feathers  Fit for Developing Software, Mugridge and Cunningham

©2015 all rights reserved, Accelinnova, LLC

Accelinnova.com/agileleanrisk.html