2. 2
Pomodoro 1: The Promise of Agile
• What problems in software development does Agile address?
• Where does Agile fit in the Universe of Methodologies
• What is Agile – from Squishy to Solid?
• What is the Promise of Agile?
• What flavors does Agile come in?
• The Current State of Agile
Pomodoro 2: A day/week/month in the life of …
• A Scrum Team
• A Kanban Team
• A Scaled Team
Lean Coffee Retrospective: Agile Dunk Tank
Agenda
3. 3
Businesses are looking for an approach
to software development approach that
offers:
• Predictability and Transparency
• Right-sized, just- enough, and just-in-
time
• Responsive to rapid market change
• Incremental, and iterative delivery to
delivery value, early and often
• Quality built in along the way
Agile Addresses: Software Development is Complex
4. 4
Predictability: What has recent history told us ?
The Standish Group’s CHAOS report results from a 40,000 projects
Top reasons for success
1. User involvement
2. Executive support
3. Clear objectives
4. Optimizing scope
5. Agile process1994
16% Succeeded
≈170% overrun
2004
32% Succeeded
≈70% overrun
“Doing projects with iterative processes as opposed to the
waterfall method, which called for all project requirements
to be defined up front, is a major step forward.”
Jim Johnson, Chairman of Standish Group
5. 5
Sometimes, 16%
Rarely, 19%
Never, 45%
Always, 7%
Often, 13%
Feature Usage in Software Projects
Has Product Development produced Just enough, Just in time?
Always or often used
20%
Never or rarely used
64%
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
6. 6
Agile Accelerates Value Delivery: Incremental and Iterative
4 444 :
Documents Documents Unverified Code Software
7. 7
Transparency: Do Agile Practitioners listen to the Business?
VersionOne: 7th Annual State of Agile Development 2013
0% 20% 40% 60% 80% 100%
Manage distribute teams
Increase engineering discipline
Simplify dev process
Improve team morale
Reduce risk
Enhance maintainability
Reduce cost
Project visibility
Enhance software quality
Better Align IT/business
Manage changing priorities
Accelerate time to market
4
7
10
7
11
8
10
15
17
3
29
30
24
35
42
38
45
39
34
45
50
41
49
43
33
42
37
40
36
39
39
20
26
25
19
22
38
16
11
15
8
14
17
10
7
11
3
5
Highest Very Somewhat Not
9. 9
Mindset
Agile is a mindset
Learn through Discovery
Collaboration
Failing Early
Seeking Feedback for
learning
Strive for Continuous
Delivery
Focus on Value
A mindset is the
established set of
attitudes held by
someone
10. 10
Values
Mindset
Agile is a mindset defined by values: Agile Manifesto
A Value is an established
ideal that the members
of a given society regard
as desirable
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
11. 11
Principles
Values
Mindset
Agile is a mindset defined by values guided by principles
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
15. 15
We’re used to Agile Expects
Time Lines Define Done, Build Quality in
Top Down Control/ Hierarchical Servant Leadership/Self managing teams.
Fixed Budgets Fixed Burn Rate
Predictable, all at once deliverables Incremental deliverables driven by value
Multiple matrixed departments, part time
commitment of resources
Co-location – one team.
Communication by Document Just enough documentation to start
conversation
Customer is “managed” Customer is part of team.
Certain Knowledge Uncertainty solved by “IKIWISI”
Estimates and Actuals Empirical Results, Cone of Uncertainty
The Paradigm Shift from Waterfall
16. 16
There are Many Popular Flavors ……
Agile
Principles
Scrum
SAFe
XP
DSDM
Crystal
Kanban
(Lean)
Flavor Characteristics
Scrum “Reference Implementation” of
Agile. Release, iteration and daily
planning; prioritized backlog,
demos, retrospectives,
generalizing specialists. Time
boxed
Kanban Focus of understanding how work
flows, visualizing the work. Limit
WIP. Often outside of SW.
SAFe: Agile @
Scale
Handles integrating multiples
teams with program and portfolio
layers
Extreme
Programming
(XP)
Technical focus on development
practices. Prescribes practices
that are commonly needed to
make Scrum deliver high quality.
Time Boxed.
18. 18
• New(ish) role introduced
by Agile.
• NOT the same as or a
replacement of the Project
Manager.
• Focus on
relationships, listening, fac
ilitating.
• The Agile SME
• Team facing not product
facing!
About the Agile Coach
19. 19
An agile coach…
Coordinating individual
contributions
Coaching for
collaboration
Being a subject
matter expert
Being a facilitator
for the team
Being invested in
specific outcomes
Being invested in
overall performance
Knowing the
answer
Asking the team for
the answer
Directing Letting the team find
their own way
Driving
Guiding
21. 21
Team Members
Developer [2-4]
Tester [1-2]
Agile BA for larger teams and Scaled Agile
Tech Lead especially for more developers
Technical Writer [Optional]
Specialist roles main join, FE Dev, DBA etc.
Different Sized
Teams will benefit
from different
practices and Agile
Flavors
• Small 1-4
• Medium 5-8
• Large > 10
22. 22
Agile @ Scale: Beyond Team Delivery Models
Agile
Enterprise
Scaled
Delivery
Teams
Agile Delivery
Teams
Scaling Considerations
Enterprise:
• Team size
• Geographic distribution
• Regulatory compliance
• Domain complexity
• Organization distribution
• Technical complexity
• Organizational complexity
• Enterprise discipline
Scaled Teams:
• Handoffs/Integration
• Incoming and Outgoing
process
contracts
• Consistency
Team delivery:
• Maturity
• Construction of working
software; various delivery
models
Software Project
Management practices
focused on delivering
working, tested code every 2
– 4 weeks;
Highly incremental delivery
practices designed to
improve code quality;
Program-level alignment to
a common, larger mission.
Synchronizing
planning, development, int
egration, delivery and
customer feedback
A set of Lean leadership
principles, that include
respect for
people, continuous
improvement, product
development flow and
executive sponsorship for a
Lean Agile operating mode
23. 23
Pomodoro 1 is over!
5 mins at the end of the first time box
Questions?
Get and move to another seat!
24. 24
Pomodoro 2: A Day/Week/Month in the life of an Agile Team
What is the most important part of this go
cart? – The brakes, they let you go faster
Scrum uses time-boxed “breaks”
Kanban uses Work in Progress “breaks”
Agile @ Scale: A peak
at the bigger picture
27. 27
Scrum Cadence
Every Release: The process begins with the product owner
collecting and prioritizing requirements in a product backlog.
Every Sprint Beginning: Sprint Planning - The team and product
owner work together to select the highest priority requirements/
stories that can be accomplished within a time boxed sprint.
Every Day: The ScrumMaster and the team have a daily scrum
meeting.
Every Sprint End: The team demonstrates the completed features
to the product owner.
• These features are a potential shippable product.
• The feedback gathered from the demonstration is fed back into
the product backlog.
• The team then has a retrospective to determine what worked
well, and what improvements need to be made to the process
for the next sprint.
28. 28
What is a Story
Combination of
• Requirements that combined
provide a standalone shippable
feature
• Visuals to support the knowledge
transfer
• Acceptance criteria: Definition of
done to drive developer and guide
testers
• Small enough to fit in a sprint and
be estimable using tasks
29. 29
Sprint Planning where stories become tasks
Planning Units
Ideal hours or days
There are other
units, but these two
are the most common
Purpose of Estimates
Not for tracking time
Scrum is results
oriented, not effort
driven
Sprint Rules
No changes during
No change to sprint
duration
Team takes work until
they’re full
Velocity
How much work the
team actually
accomplishes in a
sprint
30. 30
Scrum board = Information Radiator for the Team
• The board Informs
• Highlights impediments
• Burndown shows progress
• Focus of daily meeting
• Swimlanes per story
• Done means shippable!
31. 31
Scrum: The day starts with a daily meeting
15 minutes or less
Same time, same place – the board
Starts on time regardless with no role calls
3 questions
What I did since the last standup
What I will do before the next standup
What’s in my way
Yes, that’s it. That’s all. No more, no less. It’s a
commitment meeting, not a status meeting.
32. 32
Sprint: Demo and Retrospect on the events of the Sprint
Preparation
• As little as possible
• Low tech, high impact
• No PowerPoint – this is not about slide
ware, this is about showing real stuff
33. 33
Scrums can be linked for larger releases
Release 1
Sprint 1
Sprint
Planning
Daily
Standup
Retro and
Demo
Sprint n
Sprint
Planning
Daily
Standup
Retro and
Demo
Ideas
Product Backlog
Release Planning
Release Backlog
Sprint
Backlog
Fixed Time and Resource
Not Done Sprint
Backlog
Not Done
34. 34
Lean and Kanban: First in factories, now front offices
Toyota
Production
System
TQM
TOC
Just-In-Time
Six Sigma
Lean
Healthcare
Lean
Manufacturing
Lean Marketing
Lean
Construction
60’s-80’s 80’s 90’s 2000’s Today
Focus is on the system: rapid flow and
feedback, versus planning and “efficiency”
Enterprise Kanban
35. 35
Kanban in factories allowed decentralized decision making
Set priorities, not schedules
Enterprise Kanban
Kanban is Japanese
for visual card
36. 36
The Kanban Method for Software
1. Visualize the workflow
2. Limit Work-in-Progress
3. Manage Flow
4. Make Process Policies Explicit
5. Improve Collaboratively
using models and the scientific method
37. 37
Kanban does not prescribe roles, artifacts and meetings
Start with current process and focus on
improvement
Focus on reducing cycle time in the
system
Improvements are done “real-time”
rather than waiting for retrospectives
Metrics are different reflective continuous
flow
38. 38
For knowledge workers, Kanban = Post-ItTM Notes
Visualizing work provides immediate
insight into flow (or not)
bottlenecks
39. 39
Kanban works well outside of IT
But sticky notes don’t scale, work for
distributed teams, or track metrics
43. 43
Project A Project B Project C Project Z
Infrastructure QADevelopment
Multi-level Kanban Supports Scaling
Enterprise Portfolio
Cards:
Vertical Lanes:
Swimlanes:
For:
Key Projects
Quarters
Lines of Business
CIO & Peers
Project Breakdown
Cards:
Vertical Lanes:
Swimlanes:
For:
Deliverables
Months
Functions
Project Leads
Departments
Operations
or User Stories
Process
Team Members
Cards:
Swimlanes:
For:
Road Map
Source Control Change Mgmt Test Planning
API Integration
Link to multiple systems
Enterprise Kanban
44. 44
SAFe Roots
Lean Thinking
Product
Development Flow
Agile Development
Field experience at enterprise
scale
Iterative and
Incremental
Development
Core Values:
1. Alignment
2. Code Quality
3. Program Execution
4. Transparency
46. 46
Agile Teams act as foundations of productivity
• Empowered, self-organizing, self-managing teams with
developers, testers, content authority
• Teams deliver valuable, fully-tested software increments every two
weeks
• Teams apply Scrum and Kanban project management practices and XP
technical practices
• Teams operate under program vision, system, architecture and User
experience guidance
47. 47
Focus: Strategic Alignment. Code Quality.
Collective
Ownership
Test-First:
TDD
ATDD
Emergent
Design
Scalability
Required
Agile
Analysis
Continuous
Integration
XP Inspired
User Stories
SAFe Scrum
XP Inspired Technical Practices
Strategic Alignment
Sprint and PSI/Program
objectives
Aligned sprints and velocities
Program architecture and UX
Guidance, governance
Lean prioritization
Code Quality
Test First: TDD and ATDD
Continuous integration:
component and system
Test automation
Fortnightly system
demonstration
48. 48
Focus: Program Execution. Transparency.
Program Execution
Economic prioritization
Frequent, evaluable, quality
deliveries
Fast customer feedback
Fixed, reliable cadence
Fast tracking to actual needs
Transparency
All backlogs and progress visible
to all stakeholders
Objective reporting based on
working code
Everyone understands
capacity, velocity, WIP
49. 49
Scale to the Program Level
A self-organizing, self-managing team-of-agile-teams committed
to continuous value delivery
Organized around enterprise value streams
Aligned to a common mission
Delivers fully tested, system-level solutions every 8-12 weeks
Common sprint lengths and normalized velocity
Face-to-face planning cadence provides development collaboration,
alignment, synchronization, evaluation
50. 50
Develop on Cadence. Deliver on Demand.
Deliver on Demand
Develop on Cadence
Customer
Upgrade
Customer preview
Docs and
certs
QA-Release to Market-
Governance Firewall
Major
Release
Docs and
certs
Feature
Release
Major
Release
PSI PSI PSI PSI PSIPSI
51. 51
Scale to the Portfolio
• Lean principles emphasize sustainably fastest value delivery
• Portfolio vision guides investments and the enterprise architecture
needed to support customer and business needs
• Business epic kanban system provides visibility and work-in-process
limits to support continuous product development flow
• Enterprise architecture is a first class citizen; architectural epics are
developed and maintained in a kanban system
• Objective metrics support governance and kaizen
52. 52
This session will run more like a Kanban team and can be used
as a retrospective technique:
1. Creates 5 ideas for questions using 5 mins of the Crawford
Slip Method
2. Get with a Business Unit and figure out the groups favorite
5 questions
3. Post to the backlog
4. Vote with Green dots
5. We will flow questions based on highest priority
6. We will answer each question given it 5 mins
7. If it needs > 5 mins we will ask the team “Enough or
another 5”
8. Time Left? Yes - goto 5
9. No – You are released!
Lean Coffee Session
53. 53
Certification Opportunities (beyond initial training)
• Supports both client engagements and internal resources/teams
• Certified Scrum Professional
• Certified Agile Coach
• Certified Agile Trainer
ICF Agile/Lean Community
• Connect internal pockets of Agile/Lean enthusiasts across ICF and
Ironworks
• Create avenues for idea sharing
• Promote Agile/Lean practices and training
• Coaching internal key Agile roles
Local Agile/Lean Communities
• Engage and support local communities (Agile Richmond, Capital
Kanban, LeanStartUP…)
Community Evolvement
Editor's Notes
When you look at the history of the adoption of innovation the length of time available for planning and execution was a lot longer then software
Question: After the second sprint, what does the business have under waterfall? Under Agile? After Sprint four? Sprint six?
We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:[Left over right]That is, while there is value in the items onthe right, we value the items on the left more.
We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:[Left over right]That is, while there is value in the items onthe right, we value the items on the left more.
We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:[Left over right]That is, while there is value in the items onthe right, we value the items on the left more.
Over the years, many delivery models have been created that in line with core Agile Principles.Each model has its strengths and should be selected in context of the project or product needs, technical domain, enterprise objectives
Critical to take Agile delivery models in context to other teams and enterprise goals/processes.
Waterfall planning determines scope first then plans a schedule to fit.Lean / Agile planning develops a regular delivery cadence, breaks work down into the smallest-possible deliverable increments and then makes continuous priority decisions about what makes sense to do next. The non-critical work will somehow never rise to the top.The primary difference between Scrum and Kanban in an iterative sense, is that kanban decouples the planning cycle from the technical release cycle. Stand-ups will still be done daily. Backlog reviews, customer demo’s and retrospectives may still be done bi-weekly or monthly. But product releases will be done as often as engineering practices and customer capacity to accept change will allow.
In a manufacturing or logistics setting, kanban is used to tell people at a given work station when to do work of certain type based on visual signals sent by other workers in downstream steps of the overall process. For example, a worker on an production line might have a bin of parts that he uses as inputs to his step in the process. Once his parts bin gets to a predetermined level, he will come to a kanban card telling him to order more. He will hang that card up in a visible location. That tells the person who makes those parts to start making more. New parts are made just-in-time because in-process inventory is waste. It takes up space. It consumes processing time unnecessarily. It becomes obsolete.We want to have just enough inventory in the system to buffer against variations in demand
This is just common sense, seriously:Seeing helps understanding, especially among members of a groupFocusing on fewer things gets more work done in the long run and helps us do a better job on each oneAs managers, we should focus our efforts on ensuring that high quality work flows smoothly through our system – not on micromanaging the individual tasksStoring “the rules” about how work should be done in a process library is a great to be sure they are ignored. Building them into your board so that people are encouraged to do things the right way because the correct steps are mapped as lanes or written next to lanes is much more effective. As rules change, the board should, too.Kanban is a technique for continuous process improvement. You should never stop at your first version. The team should continually review their results and use that learning to update their process/board. And ideally, they should do so with reference to Lean principles and other good management ideas. Every team has context specific needs but there are a lot of great ideas out there.
On a kanban board, the steps in a team’s process are mapped out as (typically) left-to-right lanes on a whiteboard, wall or window. Marker lines (usually replaced later by tape) separate the lanes. Sticky notes or 3x5 cards represent work items moving through the process flow. Smaller sticky notes (the sort you use to mark where to sign a document) are used to draw attention to specific cards, indicating who’s assigned, specific due dates when truly necessary, priority, blockages, etc.Despite my screenshots, a well designed kanban board uses color to draw attention to cards that matter. For example, you might use green to indicate good cards (those that add value), red to indicate bad cards (work that fixes problems but doesn’t add new value), and yellow to indicate work done to mitigate risks. That’s just an example. The key is draw the eye to the cards that deserve attention by other team members and by management.You don’t have to be able to read the cards on a kanban board to recognize what’s happening. A column that’s jammed full of cards is obviously a bottleneck. Rather than continuing to work on their normal tasks, teams should be trained to “swarm” on the bottleneck – providing whatever help they can to that person or team. At the very least, they should stop piling up work in front of the bottleneck. There’s no value in generating more partially complete work when the system is jammed.
So far, this could also describe the sort of card wall that many Scrum teams use to manage work during an iteration. A few key things distinguish a kanban board.Scrum card walls are typically limited to To Do, Doing, Done. Kanban boards map out all of the main steps that a team normally takes in doing their work. Unless individual workers do all the work on a story without hand-offs, then even a Scrum sprint is really a mini-waterfall of sequential steps. The kanban board represents this reality.For any given main step in the process (Requirements, Design, Develop, etc.), a kanban board should have at least 2 sub-lanes: one for work that is truly in process and the other as a holding queue. Workers in one step of a process cannot put work into the in process lane for the next step down the line. All they can do is put it in a waiting queue indicating that they are done and that next team can “pull the work” when they are ready.To turn a card wall into a true kanban system like in manufacturing, you have to implement Work-In-Process limits Little’s Law and queuing theory show that any system will slow down dramatically at roughly 60-70% of resource utilization. Trying to maximize resource utilization actually results in drastically less output.Putting explicit limits on WIP (Work in Process) is designed to prevent over-utilization. Limiting WIP tends to measurably increase output and decrease variability.
Cumulative flow diagram shows where bottlenecks are forming in a process. Think of it as the board turned on its side. Each color represents a lane. The height of the colors represents how many cards were in the lane at a point in time. If one lane is getting taller and the others aren’t, you have a bottleneck.Burn-up analysis allows you to use a team’s work history data to predict whether they can get current workload done a desired end date. The redline is your required productivity trend to hit a target. The yellow line is your actual trend. The green line is what must be done to hit the target. The steeper the green line, the less likely it is that you can recover. The great thing about kanban analytics is that they are based simply on people moving sticky notes. That’s easy for them to do quickly so they actually do it. You get a picture of what’s actually happening rather than an estimate.