Agile & Lean / Kanban 0
What is Lean? 1
Agile Development Methods (Dogma) extreme Programming (XP) Scrum Lean Software Development Behavior Driven Development (BDD) Feature Driven Development (FDD) Crystal Clear Methodology DSDM Others: Test Driven Development (TDD), Model Driven Development (MDD), Rational Unified Process (RUP). 2
Lean Has History Standard software development practice for the last decade. Agile is the combination of principals that have existed for over 60 years. Lean Software Development exposes the pedigree of Agile. Almost all Agile practices can be traced back to Deming s System of Profound Knowledge and his 14 Points for Management. W. Edwards Deming Deming s System of Profound Knowledge: Deming advocated that all managers need to have what he called a System of Profound Knowledge, consisting of four parts: Appreciation of a system: understanding the overall processes involving suppliers, producers, and customers (or recipients) of goods and services (explained below); Knowledge of variation: the range and causes of variation in quality, and use of statistical sampling in measurements; Theory of knowledge: the concepts explaining knowledge and the limits of what can be known. Knowledge of psychology: concepts of human nature. Lean Lean Manufacturing Software Dev. Agile Quality Management (Six Sigma) 3
Agile Principals Communications Simplicity Feedback Courage Respect Visibility Honesty Realism Quality Lean Principals Optimize the Whole Eliminate Waste Create Knowledge Build Quality In Defer Commitment Deliver Fast Respect People 4
Eliminate Waste Everything not adding value to the customer is considered to be waste (Muda). This includes: Unnecessary code and functionality Delay in the software development process Unclear requirements Bureaucracy Slow internal communication 5
Create Knowledge / Amplify Learning Customer Feedback Short Cycle Times Refactoring Code Review Automated Test instead of documented defects. 6
Build Quality In Unit Test / TDD Automated Acceptance Tests Refactoring Pattern Based Development Continuous Integration 7
Defer Commitment Wait till the last Responsible moment to make an irreversible decision. Set Based Design Pursue multiple solutions eventually choosing the best one. Agile Version: Prioritize backlog, but don t commit more then one iteration at a time. 8
Deliver Fast Small Batch Sizes Short Iterations Feedback, Feedback, Feedback. Close Customer Collaboration Software Demos 9
Optimize the Whole Manage the Value Stream Look beyond the Development Team Standardize the process Efficiency vs. Effectiveness 10
Respect People Trust in people that they know the best way to do their jobs. Recognize Teams and Individuals for their effort and contribution People are not Resources Empower the team to make the right decisions and improve the process. 11
How Does Agile Fit? 12
The Agile Manifesto Agile Principals We are uncovering better ways of developing software... Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 13
Individuals & Interactions > Process and Tools We value communication and teamwork over strict processes and the tools to enforce them. Most software problems can be traced back to communication problems early on in a products lifecycle. Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. 14
Working Software > Comprehensive Documentation Working Software requires just as much documentation as the customer needs. No More & No Less. 15
Customer Collaboration > Contract Negotiation Remove barriers between the developers and the customers. Understand that the closer the relationship between the customer and the development team the better the product. 16
Responding to Change > Following a Plan 17
Agile Principals Some of the principles behind the Agile Manifesto[6] are: 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. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 18
Typical Agile Adoption 1. User Stories 2. Acceptance tests 3. Iterative Development 4. Burn Down Charts 5. Story Boards V.S. 6. Daily stand-ups 7. TDD / Unit Tests 8. Continuous integration Simple Lean Adoption 1. User Stories 2. Acceptance tests 3. Iterative Development 4. Burn Down Charts 5. Kanban Boards 6. Daily stand-ups 7. TDD / Unit Tests 8. Continuous integration 19
Kanban 20
Kanban Signboard or Billboard Kan means "visual," and ban, means "card" or "board Is a signaling system to trigger action Uses cards to signal the need for work to be done Another Toyota Lean lesson focusing on Just in Time production Example: 20 car doors, 5 left = time to make more doors Doors are requirements, requirements are inventory 21
3 Rules 1. Strict Queue Limits 2. Pull Value Through 3. Make it Visible Kanban Strict Queue Limits Pull Value Through Make it Visible 22
Example Development Boards 23
Example 2 24
Example 3 25
Work In Progress (WIP) Create Columns for Each Step in your process Pick Limits for Active Queues (team size divided by 2 or just be logical) Set Wait Queues to 2 or 3, keep small, Eliminate waste, get feedback FIFO If a slot is full, can t start more work (A.K.A. PULL) Team sets Queue sizes to be most efficient, experiment Designed to Limit WIP, More WIP means slower flow 26
WIP Visible feature goals to minimize thrashing MMF = minimal marketable feature or MUF = minimal usable feature Can Only reorder in Wait Queue to move MUF forward Put Team Signals/Rules Above WIP Queue & Cross Team Signals On Bottom Could add a Queue for External Team 3 Rules: Strict Limit, Pull Value, Visible 27
What Goes On A Card 28
Cycle Time / Throughput Goal is to get optimum flow How many days does it take to flow through the team once it enters the WIP? Keep a chart: Wait/Cycle Time for each card size Good teams/systems: XS to Medium cards, Large = Bad If 22 ~same size cards in WIP, track 22 as well Sum up unit value on each board Velocity is a trailing indicator Throughput is a measure of demonstrated capacity 29
Backlog Board 3 Queues to show priorities Set back log limit for each board to equal number of slots on WIP Make assumption relative sizes will be close Same number of items in WIP on each board (22 in this example) Add up the units to ensure they are close, move wait line if they are considerably (not marginally) off Can now forecast based on logical assumptions Schedule regular backlog honing meetings with customer, rules at top Trigger release planning meetings when necessary Card is a TOKEN, physical means real, avoid temptation to live by a tool 30
What s Changed: Optimize/Continuous Flow No Iteration Planning Meetings FIFO work order, don t sign up Cycle Time replaces velocity, always updated Signal Event Show & Tell RPM Scheduled Events Retrospectives Releases per MMF/MUF or Cadence 31
Agile & Lean 32
Scrum vs. Kanban Why do we really care? Agile Manifesto is about uncovering better ways of doing software not about one practice vs. another Principles Frequent Delivery does not mean you must do iterations Maintain a constant pace indefinitely (sustainable pace AND consistent pace?) 33
Daily Scrum/Standup Used to Be What did I do yesterday What am I going to do today Do I have any road blocks Could Now Be How are things flowing? Team stands and reviews the WIP Talk about blocks & constraints Downstream work is most important Take Turns with each person reading the flow 34
Agile & Lean Together 35
Agile & Lean Teams 1 Team Agile 2 Week Interations 1 Team Lean Kanban Coordination: Release on the Cadence 2 Weeks Separate Stand-Ups / Scrum of Scrums Rotating Testing & Verification Product Owners provide work to both teams based on criteria. Velocity, Lead Time & Cycle Time can all be coordinated. 36
Kaizen - Continuous Improvement 改善 Team retrospectives, Scrum of Scrums, Scrum Master Retrospectives Product Owner Retrospectives, Release Retrospectives The entire process of development at an Agile Enterprise should be regularly inspected and improved. The outcome of the PDCA process must include the Check and Act portions. 37