View
300
Download
0
Category
Preview:
Citation preview
AGILE&KANBAN
AgileSolutions
Keith Klundt, AgileSolutionskeith.klundt@gmail.com@WebSolvewww.linkedin.com/in/keithklundt• 15 years in product and technology
leadership• Agile/Scrum/Kanban trainer and coach• Scaled Agile Framework (SAFe) Program
Consultant
Introductions
© 2013 AgileSolutions
Agile Manifesto
© 2013 AgileSolutions
We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items onthe right, we value the items on the left more.
agilemanifesto.org
Agile Principles
© 2013 AgileSolutions
1. Deliver value early2. Welcome change3. Deliver value often4. Customers and
creators work together daily
5. Involve only motivated people
6. Convey information face-to-face
7. Outcomes are the main measure of progress
8. Work at a sustainable pace
9. Technical excellence
10. Simplify11. Self-organize12. Reflect and improve
Agile Characteristics
© 2013 AgileSolutions
Empirical – relies on objective measurementIterative – builds value over timeAdaptive – adjustments made periodically based on results
© 2013 AgileSolutions
Behind The Decision to Try Agile
© 2013 AgileSolutions
Actual Benefits from Agile
© 2013 AgileSolutions
More prescriptive More adaptive
RUPDSDM
XP Crystal
Scrum Kanban
Agile Methods & Practices
Agile Methods & Practices
© 2013 AgileSolutions
Scrum
© 2013 AgileSolutions
© 2013 AgileSolutions
• Commitment• Focus• Openness• Respect• Courage
Scrum Values
Scrum Artifacts: Product Backlog
© 2013 AgileSolutions
© 2013 AgileSolutions
Scrum Artifacts: User Story or PBIGood Story FormWhere <user type> is a persona or entity that we define that can take action or perform a function:
As a <user type>, I want to <function> so that <benefit> or<user type> <action> <because>
Good Examples• As a passenger, I want to set the temperature of my seat so that I
am comfortable• As a laptop user, I want to de-clutter my screen so that only the
application I'm working with is visibleBad Examples• The current clinician clicks the icon to find out what
contraindications exist• The system alerts the clinician because the patient prescription
limit has been reached
User Story – 3 CsCardJust enough information to identify the requirement and let everyone know what the story is. Common reference point for all: Product Owner, Stakeholder, Developer, QA.
ConversationThe card is an invitation to have a conversation: an exchange of thoughts, opinion, feelings and ideas. The conversation takes place over time—when the story is first introduced, during subsequent grooming and sizing, and at iteration planning. Conversation may be supplemented with documents and prototypes.
Confirmationkey aspects of the story that will be used by the Product Owner as acceptance criteria.
© 2013 AgileSolutions
Acceptance CriteriaWhat is it?
• Details from the user story conversation• Expectations of how the customer team expect the user
story to work • Used to validate that the development for the user story
is doneWhy does it need to be done?
• Used to validate that the development is done• Acceptance criteria is folded into use cases and used for
the life of the product• Used for documenting how the product works
Who creates the acceptance test?• The customer and/or Product Owner• Team members should participate
© 2013 AgileSolutions
Agile Planning
http://commons.wikimedia.org/wiki/File:XP-feedback.gif
Sprinting
© 2013 AgileSolutions
The heart of Scrum is a Sprint, a time-box during which the team creates a potential releasable product increment.
During the Sprint:• No changes are made that would affect the
Sprint Goal• Development team composition remains intact• Quality goals do not decrease• Scope may be clarified and re-negotiated
between the Product Manager and Development Team as more is learned.
Sprint Planning
© 2013 AgileSolutions
• Time-boxed to 8 hours for a one-month Sprint (4 hours for a two-week Sprint)
• Answers the questions:1. What will be delivered in the increment
resulting from the sprint?2. How will the work needed to deliver the
increment be achieved?• Inputs include:
1. Product Backlog2. Latest product increment3. Projected team capacity during the Sprint4. Average historical velocity of the team
• Team commits to the Plan
Product Backlog Grooming
© 2013 AgileSolutions
• Provide clarity • Establish acceptance criteria• Establish more detailed estimates
As stories move to the top of the backlog we increase the details of the story and break them down as needed
Sprint Review
© 2013 AgileSolutions
• Scrum Team and Stakeholders collaborate on what was done and what should be done next
• Product Owner identifies what has been done and accepted
• Development team provides an overview of what went well and how they solved problems
• Development team or Product Owner demonstrates work done
• Product Owner updates stakeholders on what’s likely to happen in the near future
Sprint Retrospective
© 2013 AgileSolutions
• Opportunity for the Scrum team to self-inspect and create a plan for improvement in the next Sprint
• Evaluate how the last Sprint went with regard to people, relationships, process, and tools
• Identify and order major items that went well and opportunities for improvement
• Create a plan to implement improvements to the way the team does its work
Daily Scrum
© 2013 AgileSolutions
• Time-boxed to 15 minutes• Primary purpose is to synchronize the team and
commit to a plan for the next 24 hours• Held at the same time and place each day• Each Development Team member explains:
1. What s/he has accomplished in the past 24 hours
2. What s/he will complete before the next meeting
3. What obstacles are in the way• Daily work is evaluated in the context of the
Sprint Goal. An effective Daily Scrum should help the team increase the probability of achieving their goal.
Scrum Artifacts and Ceremonies
© 2013 AgileSolutions
Prioritized Items desired by Customer
Potentially Shippable Product
Increment
Sprint Planning Meeting•Review Product Backlog•Estimate Sprint Backlog•Commit to 3 weeks of work
Backlog tasksexpanded by team
•Product backlog items assigned to sprint•Estimated by team
Daily Scrum Meeting•Committed to yesterday•Commit to today•Obstacles?
Sprint Showcase•Demo done items•Retrospective on the Sprint
© Cutter Information LLC, used without permission
© 2013 AgileSolutions
Kanban ̶ A Lean Practice
Toyota Production System House of Quality
Kanban
© 2013 AgileSolutions
© 2013 AgileSolutions
Lean Principle: Eliminate Waste
Seven Wastes of Manufacturing Seven Wastes of Software Development
Inventory Partially Done WorkExtra Processing Extra Processes or
DocumentationOverproduction Extra FeaturesTransportation Building the Wrong Thing
Waiting Waiting for InformationMotion Task SwitchingDefects Defects
Source: Esther Derby, “Three Encouraging Developments in Software Management,” CrossTalk, January 2009 http://www.stsc.hill.af.mil/crosstalk/2009/01/0901Derby.html
© 2013 AgileSolutions
Scrum and Kanban Similarities• Lean and Agile shared values• Pull scheduling• Limit WIP• Transparency drives process improvement• Deliver releasable software early and often• Self-organizing teams• Break work into pieces• Release plan is continuously optimized
based on empirical data (velocity in Scrum, lead time in Kanban)
© 2013 AgileSolutions
© 2013 AgileSolutions
Contrast
Scrum KanbanTime boundaries (iterations) Work unit boundaries (batch sizes)
Narrow appeal to SW engineering
Broad appeal to Product Management, IT Ops, IT support, etc.
Radical change Minimally invasive, evolutionary
Requires high trust culture Can succeed in relatively lower trust culture
Requires cross-functional team
Allocates specialized knowledge and skills
Focuses on delivery team capacity Expresses system capacity
Kanban Emphasizes Continuous Flow• Work-in-progress (WIP) limits• Pull system• Just-in-time work• Collaboration around process
problems• Systems approach to
continuous improvement© 2013 AgileSolutions
Name Writing Project
Step 1: Estimate how long it takes to write:
1 name1 + n names
Step 2: What factors influence the time it takes?
© 2013 AgileSolutions
Name Writing Project
© 2013 AgileSolutions
Name Writing Project – Round 1
© 2013 AgileSolutions
Name Writing Project – Round 1
© 2013 AgileSolutions
Estimate Actual
1 Name5 Names
Name Writing Project – Round 2
© 2013 AgileSolutions
Name Writing Project – Round 2
© 2013 AgileSolutions
Name Writing Project – Est v Actual
© 2013 AgileSolutions
Estimate
Round 1 Actual
Round 2 Actual
1 Name5 Names
Reflect
© 2013 AgileSolutions
• How did the two rounds feel to you as Developer and Customer?
• What was it like to be the last customer in round 1 v round 2?
• What do you think about the statement, “if we start early, we’ll finish early?”
• What causes us to do this? Why is it so common?Henrik Kniberg, http://
blog.crisp.se/2011/12/07/henrikkniberg/multitasking-name-game
The Kanban Board – Left to Right1. Goals – on the far left side of the Kanban board is a column
labeled “goals.” Prioritization of the Backlog should reflect something in the goals column.
2. Backlog – stories standing in line waiting to be worked by the team. Team always pulls from the top of the Backlog
© 2013 AgileSolutions
3. Story Process Steps – columns for the process steps a story needs to go through to be called “done.”
4. Done – stories that are ready to be deployed.
Kanban Goals Focus on The System• Deliver high quality• Improve predictability• Improve employee
satisfaction• Continuous process
improvement• Simplify prioritization• Provide transparencyDavid J. Anderson, Kanban
© 2013 AgileSolutions
Foundation Principles
1. Start with what you do now2. Agree to pursue incremental,
evolutionary change3. Respect the current process, roles,
responsibilities and titles
© 2013 AgileSolutions
Practices• Visualize the workflow• Limit WIP• Manage flow for just-in-time value delivery
CONstant Work in Process (CONWIP); new work is pulled into an activity when there is capacity in the local WIP limit
• Make process policies explicit (criteria that must be met before work can be pulled into the next phase)
• Improve collaboratively (PDCA cycles)• Work for uniformity in work item size© 2013 AgileSolutions
Create The Board
© 2013 AgileSolutions
1. Agree on the goals for introducing Kanban
2. Map the value stream
Define the attributes required to accept a request into the system
3. Define the point where you want to control input
4. Define the exit point beyond which you do not intend to control
Create The Board
© 2013 AgileSolutions
5. Define a set of work item types based on the types of work requests that come from upstream stakeholders
6. Analyze the demand for each work item type
Type A – BurstType B – SteadyType C – IntermittentType D – SteadyType E – Cyclical
Create The Board
© 2013 AgileSolutions
7. Meet with the upstream and downstream stakeholders to discuss:• Policies around capacity of the piece of the value stream
you want to control and get agreement on a WIP limit. For example, you may want to put in place a policy for Environment issues that states they will be addressed within 24 hours and can exceed the WIP limit on any state within the value stream.
• Discuss and agree on an input-coordination mechanism with upstream partners.
• Discuss and agree on a release/delivery-coordination mechanism with downstream partners
• Introduce the concept of classes of service, if needed• Agree on a lead-time target for each class of service of
work items.
Create The Board
© 2013 AgileSolutions
8. Create a card wall to track the value stream you are controlling
Create The Board
© 2013 AgileSolutions
9. Agree with the team to have a standup meeting every day in front of the board. Each team member reports on his/her work with:• What I accomplished yesterday• What I will commit to doing today• Impediments in my way
In addition to the Daily Standup, agree on a cadence and next meeting dates for:• Queue Replenishment – to be held with a group of business
stakeholders or product owners weekly• Retrospective – team members meet regularly (e.g., weekly or
every 2 weeks) to reflect and work on process improvement. Among other things, the team reviews:• Average throughput based on latest results• Average cycle time based on latest results• Feedback from customers on process and delivery• What the team feels it should keep doing, start doing, and
stop doing to achieve even better results
Scrum or Kanban Cadence
© 2013 AgileSolutions
Queue Size Control PrincipleFor real-time control and system optimization:
1. Don’t control capacity utilization
2. Don’t control cycle time3. Do control queue size
Donald G. Reinertsen, Principles of Product Development Flow
© 2013 AgileSolutions
Monitor WIP per Team Member
Rally Software: The Impact of Agile Quantified, 2013© 2013 AgileSolutions
• Lower WIP produces fewer defects
• The right WIP level optimizes throughput and quality
Mature Lean OrganizationLean Assumption #1 – A mature organization looks at the whole system; it doesn’t only focus on optimizing disparate or separate parts
Lean Assumption #2 – A mature organization focuses on learning effectively and empowers the people who do the work to make decisions
M & T Poppendiek, Lean Software Development© 2013 AgileSolutions
Kanban Measures Continuous Flow
http://www.targetprocess.com/userguides/userguide.html© 2013 AgileSolutions
Frequent Review and Incremental Improvement
© 2013 AgileSolutions
Make Policies and Flow Explicit
© 2013 AgileSolutions
Meetings
• Grooming• Prioritization / Planning• Standup
© 2013 AgileSolutions
“Since our last meeting, two slots have become free. Our current cycle time is
6 weeks to delivery. Which 2 thing would you most like delivered 6 weeks
from now?”
Making The Transition
© 2013 AgileSolutions
Causes of Agile Failure
Transition Backlog Example
© 2013 AgileSolutions
Schedule Recurring Agile Governance meetings to inspect and adapt, and to review status of transition backlog itemsBacklog Item Responsible Status Due Date
Publish goals for using KanbanSet expectations that change is needed and will require commitment, work and creativityMeet with stakeholders to describe the changeDetermine how to communicate progressDecide on tools
Inspect and Adapt
© 2013 AgileSolutions
Keep Doing
Stop Doing
Start Doing
© 2013 AgileSolutions
Get It DoneThe Cult of Done Manifesto
1. There are three states of being: Not knowing, action and completion.
2. Accept that everything is a draft. It helps to get it done.3. There is no editing stage4. Pretending you know what you’re doing is almost the same as
knowing what you’re doing, so just accept that you know what you’re doing even if you don’t, and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things done.
. . . 9. People without dirty hands are wrong. Doing something makes
you right.10.Failure counts as done. So do mistakes.
© 2013 AgileSolutions
Appendix
Appendix
Scrum and Kanban – A Case Study
• 2001 – 2006 used waterfall process with annual release cycle: design -> implementation -> testing -> deployment
• 2007 moved to Scrum with 3-week sprints• 2013 moved to Kanban with emphasis on
uninterrupted flow and WIP limits• Measured lead time (from next in line at the
start to ready for release at the end of the board), quality, and productivity
http://www.infoq.com/presentations/kanban-for-software
© 2013 AgileSolutions
Stuff from David Anderson
Kanban allows us to implement my (David’s) recipe for success:• Focus on Quality• Reduce (or limit) Work in Progress• Balance Demand against Throughput• Prioritize
http://www.infoq.com/presentations/kanban-for-software
Slideshow only: http://www.slideshare.net/deimos/david-anderson-kanban-at-q-con
http://www.slideshare.net/davidpeterjoyce/kanban-overview-and-experience-report-export-3593596
© 2013 AgileSolutions
Stuff from David Anderson
Case Study: XIT one of Microsoft’s 8 IT departmentsXIT Sustained Engineering• Small team• Change requests• Supports over 80 applications (and growing)• Engineering responsibilities moved from
Redmond to Hyderabad in 2004• Hyderabad vendor is CMMI Level 5 and uses
TSP/PSP• Initial quality is very high
http://www.infoq.com/presentations/kanban-for-software
© 2013 AgileSolutions
Recommended