Agility? What for? And
how?
> Warm-up Session Agile Tour Vienna 2014
© CSS GmbH | November 2014
Agenda
Agile Software Development: reasons & goals
Scrum in a nutshell
Kanban in a nutshell
Agility: prerequisites, limits and corporate culture
2
© CSS GmbH | November 2014
The Manifesto for Agile Software Development
“We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:– Individuals and interactions over processes and tools
– Working software over comprehensive 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.”
www.agilemanifesto.org ©2001, Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
3
© CSS GmbH | November 2014
The 12 Agile Principles
“Our highest priority is to satisfy the customer
through early and continuous delivery of valuable
software.”(1st Principle of Agile Software; www.agilemanifesto.org)
“Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.”(2nd Principle of Agile Software; www.agilemanifesto.org)
4
© CSS GmbH | November 2014
The Cone of Uncertainty (also: Funnel Curve)
At the start of the project, uncertainty concerning requirements is 16 times higher than at the end of the project (Boehm).
After 30% of the project duration have elapsed, this uncertainty is reduced from 16 times to 1.5 times (Boehm).
5
© CSS GmbH | November 2014
The „classical“ project management approach
6
But „C“ would have
been the solution
which the client really
needed Source: Mitch Lacey 2011
„B“ was 100% implemented
as planned
„B“ was specified
and sold in the
beginning
© CSS GmbH | November 2014
The 12 Agile Principles
“Working software is the primary measure of
progress.”(7th Principle of Agile Software; www.agilemanifesto.org)
“Deliver working software frequently, from a couple
of weeks to a couple of months, with a preference
to the shorter timescale.”(3rd Principle of Agile Software; www.agilemanifesto.org)
7
© CSS GmbH | November 2014
And now here is the agile approach…
8
Source: Mitch Lacey 2011
„B“ has been planned. And it has been
specified how to deal with changes.
Here they found out
that „B“ should look
more like „C“...
So they
decided to go
for „C“!
The „B“-
detour has
been skipped.
© CSS GmbH | November 2014 9
What do you read?
IUMRING TQ GQNGIUSIQNS
Source: Mike Rother
IUMRING TQ GQNGIUSIQNS
Our brain automatically fills in blanks, instead of saying to us “Sorry, I don’t know yet”
Source: Mike Rother
© CSS GmbH | November 2014
The 12 Agile Principles
“Continuous attention to technical excellence and good design enhances agility.”
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
“Simplicity--the art of maximizing the amount of work not done--is essential”
(9th, 8th & 10th Principle of Agile Software; www.agilemanifesto.org)
11
© CSS GmbH | November 2014
Don’t forget about uncertainty!
12
Sometimes we have to look at
things we don’t want to see…
But it’s better to have
thunderstorms during a project
than having a hurricane in the
end…
An agile, iterative approach
forces everybody to check
continuously if we are on the
right way - even the client
Scrum in a nutshellHow does Scrum ‘implement’ agile principles?
13
14
Ken Schwaber
The only thing Scrum can gurantee is, that latest after 30 days the shit will appear from underneath the carpet.
„I help people build software in 30 days or less. Tell us the most important stuff you have, and we’ll give you as much of that as we can at the end of 30 days.“
© CSS GmbH | November 2014
What is Scrum?
Scrum is actually a rugby tactic where all team
members have to work together in order to bring
an "out of play" ball back into the game.
Scrum is a set of values, principles and practices
improving the working environment for the team.
Scrum is a mindset and different way of working
to realize business value for our clients sooner.
15
© CSS GmbH | November 2014
Some facts about Scrum
agile approach for cyclical, even empirical and evolutionary software development projects
the team is the anchor of the project
inherent change management and built-in continuous improvement
it’s boosting people’s creativity when doing complex work
continuous delivery of “done” functionality with integrated iterative client feedback
the classic role of a project manager is shared by several persons
it’s scalable to work with large projects and organizations
high productivity and efficiency
iterative, time-boxed, short-phased, team-oriented
16
© CSS GmbH | November 2014
Sprint Review /
Demo Meeting
Working Software Product Backlog
Sprint Backlog
Product Owner
Scrum Master
Scrum Team
[Consultants]
Sprint Planning
Retrospective
Daily Scrum
2 Lists1 Goal 3 Core Roles4 Core
Meetings
Product BacklogSprint Backlog
Sprint Planning
Working Software
Sprint (1)/2/3/4Weeks
dailyDaily Scrum
Sprint Review/Demo
Sprint Retro-
spective
Client
Source: Mike Cohn, modified
© CSS GmbH | November 2014
The Scrum Product Owner
18
Represents the client's wishes and business
values
Responsible for the project’s requirements
• the “internal representative of the client”
• represents and talks to stakeholders
• owns and manages the product backlog
• defines, maintains and communicates the "product vision"
• monitors (economic) project goals and values
• defines what "done" means together with the Scrum
Master and the team
• takes release decisions
© CSS GmbH | November 2014
The Scrum Master
19
In charge of maintaining a healthy team
and team culture
• moderates and manages Meetings, especially
the Daily scrum
• gets rid of project obstacles
• protects the team against outside influences
• manages the team's time (meetings requested
by the PO, external requests etc.)
• ensures that the Scrum guidelines are observed
• defines and reports team-productivity
© CSS GmbH | November 2014
The Scrum Team
20
Implementing the product backlog and
vision
• self-organized and self-reliant
• sets its own workload
• manages its own work
• manages its own deadlines
• multi-functional
• (only) develops the product backlog features
with the highest priority
© CSS GmbH | November 2014
The Product Backlog is a prioritized list of features and work to do
– contains user stories (features, spikes, taxes and preconditions)
– user stories are first on an epic granularity and will be broken down into smaller stories before being selected for a sprint
– user story syntax: As a <type of user>, I want <some goal> so that <some reason>.
– like a “specification” but always up-to-date
– new items may be added or older ones being re-prioritized at any time
– owned and prioritized by the Product Owner who voices the client's wishes and values
21
© CSS GmbH | November 2014
The Sprint Backlog is a list of features and work which have been selected to be done during a certain sprint
– contains detailed user stories
– is being set up during the Sprint-Planning Meeting
– the workload has been defined by the team based on their estimation (e.g. with Planning Poker)
– it represents the team’s commitment for the sprint and will be frozen during the sprint (no items will be removed)
– “done” means “100 % done”
– the velocity (relation between planned and real progress) and trend are being monitored using burn-down charts and cumulative flow diagrams
22
© CSS GmbH | November 2014
Sprint Planning Meeting
Daily Standup Meetings (max. 20min)– a kind of daily status update (focus on progress & problems) for the Team
and Scrum Master
– very efficient and effective communication technique!
Sprint Review Meeting (Demo Meeting)– the Team presents the results of the recently finished sprint to the Product
Owner and the Client, moderated by the Scrum Master.
– a continuous improvement feedback-loop for the product / software
Sprint Retrospective – Team and Scrum Master discuss what went well and what went
wrong during the recently finished sprint
– a continuous improvement feedback-loop for the scrum process and for project management issues
23
© CSS GmbH | November 2014
"Large" project?– More than one Scrum team (with their respective Scrum Masters)
working on a parallel implementation
– Working on a shared product backlog
– Supervised by one or more Product Owners
"Distributed" project / team?– Project team members or teams working in more than one location
– different degrees of distribution
low: different room/floor; medium: different building/location; high: different time zone
Dispersed Team: one team is spread over more than one location
Distributed Team: Teams work together in more than one location, but each team as a unit is located in one location
24
Kanban in a nutshellTo which extend does Kanban go with Agile?
25
© CSS GmbH | November 2014
Some facts about Kanban
Kanban is evolutionary change management
Kanban focuses on optimized, continuous workflow
Kanban visualizes the present situation of a system and / or process (workflow)
Kanban is agile and lean, it’s ‘less regulated’ than Scrum
Kanban is highly adaptable and must be adapted
Kanban is perfect for optimizing continuous workflow– for managing Operations & Support teams or departments
– for product development or Startups with just one product
– for product enhancement and maintenance / future versions
– management of strategy departments or portfolio management
– Some people also use it for project management
26
27
Source: David J. Anderson
Source: The Agile Pirat
28
„You don‘t have to change, survival is optional“
Dr. W. Edwards Deming
© CSS GmbH | November 2014
Kanban briefly defined
29
It’s the “Start with what you do know” Method
Stop starting, start finishing
4 Principles & 6 Core Practices
Evolutionary Change
Visualize
Limit Work in Process
Manage FlowSource: David J. Anderson
30
Kanban Agendas
• Resilience/anti-fragility• Evolutionary capability
• Fitness criteria metrics• Workflow• Service level
expectations
• Relief from over-burdening
Survivability Service-orientation Sustainability
Lead the business Decide with confidence Engage with people
© CSS GmbH | November 2014
The six Kanban core practices:
Visualize the Workflow: Visualize all steps of your workflow on a Kanban
board. This provides a complete overview at first sight whenever you pass by.
Limit Work-in-Progress: Limit the number of items where work is in
progress: prevent from overload and bottlenecks. Like with Scrum there is the
‘done means really done’ principle (define done first!).
Manage and Measure Flow: Kanban is a continuous improvement process.
Workflow will be optimized ongoing. Don’t forget: it’s a pull system!
Make Process Policies Explicit: Define rules to keep the workflow
understandable for everybody. Focus on communication and teamwork.
Implement feedback loops
Improve Collaboratively: Use Models to Recognize Improvement
Opportunities (measurement, use scientific methods…)
31
© CSS GmbH | November 2014
The four basic Classes of Service
Standard - Fixed Delivery Date - Expedite - Intangible
Tickets within a Kanban system are prioritized by different classes of service
They are measured by CoD (cost of delay) over time
Often visualized by using different colors for the tickets
Sometimes represented by swim lanes or an ‘express lane’
The total number of service classes within a system should be kept low (e.g. max. 6)
Each call of service has it’s own SLA (‘Expedite’: X% completed within Y hours)
32
© CSS GmbH | November 2014
Kanban WIP limits
WIP stands for Work in Progress. So WIP will be limited!
This is to prevent from task switching or interruptions, visualize blockages, limit through-put time, improve quality,…
Bottlenecks will be buffered
Don‘t forget the rule ‚done means really done‘
Column limits
ConWIP (constant WIP)
Swim lane limit
Column & swim lane limit
Limited resources (Avatars)
Limit by discussion
33
© CSS GmbH | November 2014
Kanban Meetings
Daily Standup: focusing on blockages in the workflow
The After Meeting: more details for whom it concerns
Input Queue Replenishment Meeting: filling the IQ
Triage-Meeting: ‘grooming’ the Product Backlog
Release Planning: packaging what will be released
Team Retrospective: continuous process improvement
Operations Reviews: continuous system improvement
Like in Scrum, teamwork and communication and are THE
most essential agile core principles with Kanban.
34
© CSS GmbH | November 2014
Measurements and Visualization
The performance of the Kanban system must be measured. Measure the performance of the system and the workflow
CFD (Cumulative Flow Diagram); quantity and constancy of WIP
Lead time: timespan from the IQ input date until the item is ‘done’
Cycle time: timespan between the different phases on the Kanban Board. When the WIP limit is (too) high this will result in high lead and cycle times (so this is bad!)
Flow (throughput): check if the SLAs for the classes of service are fulfilled
Flow efficiency: Work time, wait time, ‘blocked’ time, efficiency
Failure load: tickets which have to be reactivated after they have already been ‘done’
Blockages
35
Agile prerequisites & limits and
an Agile Corporate Culture
36
© CSS GmbH | November 2014
„pure“ Feature Teams
User interface
Business logic
Backend system
37
Feature
Team AFeature
Team B
Feature
Team C
Product Owner A
Product Owner B
Product Owner C
In an organization solely consisting of feature teams, each of the 3 sample teams will implement all work packages for one requirement across all systems.
© CSS GmbH | November 2014
„pure“ Component Teams
User interface Component team A
Business logic Component team B
Backend system Component team C
38
In an organization solely consisting of component teams, each of the 3 sample teams will implement all work packages for all requirements in their respective system.
Product Owner A
Product Owner B
Product Owner C
© CSS GmbH | November 2014
Organization with combined team-structure
39
Feature
Team B
Product
Backlog
ChiefProductOwner
Product Owner 1
Feature
Team A
Feature
Team D
Feature
Team C
Product Owner 2
Product Owner 3
Component Team X
Component Team Y
Product Owner Team
© CSS GmbH | November 2014
Often met with resistance when introduced– Management role turned upside down, the team has the
responsibility, trust in employees,…
– More than one person has the role of a "project manager“
– Agility (Scrum, Kanban) has to be ‘possible’ in your organization
– Especially with Scrum a lot of change in mindset is needed before you can even start
Team members always have to work full-time in one project (Scrum) and with limited parallel work (Kanban)– at least 80% of their time; and at one location…
The team has to be 100% committed
The client needs to be willing to give regular feedback (and also have time for it )
© CSS GmbH | November 2014
It needs some time (Sprints) until the advantages will be seen.
Team members will experience more stress during the first sprints compared to e.g. a waterfall. – Don’t give up too fast!!!
It was primarily highly specialized on software projects, although agility can be used for other projects as well
If an agile approach fails, it often fails hard, especially on the social level (nobody can hide, transparency,…)
Unfortunately the agile hype has ruined a lot– e.g. Scrum was / is often used wrongly and when it fails,
everyone agrees that it was bad…
© CSS GmbH | November 2014
You cannot "only do a little bit of Scrum" or "just
adapt Scrum to the organization“ when you have
no experience with it before.
– if you adapt core things, don’t call it Scrum anymore
Don’t merge the core roles! (…Project Master )
Be careful when trying to introduce Scrum,
Kanban or agile working culture in organizations
whose management or structure are not
designed or ready for the agile principles…
© CSS GmbH | November 2014
Common mistakes when introducing Scrum / Kanban
Don’t try it in a giant project for the first time!– And don’t try it in a small, unimportant project as well
At least core people of your department or company should attend a training first.
Don’t forget to involve the client and explain the agile advantages, as well as the prerequisites
High staff fluctuation or too many part-time employees will kill Scrum and Kanban teams!
Stick to your commitments and to the core principles. Only 100% done is really done.
Agility does not help if you still do “code and fix” (draufloswurschteln hat nichts mit Agilität zu tun!)
© CSS GmbH | November 2014
It‘s all about people!
“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.”
“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.”
(4th, 5th, 6th, 11th & 10th Principle of Agile Software; www.agilemanifesto.org)
44
© CSS GmbH | November 2014
Shifting from a plan-driven to a
value-driven project management
Shifting from a formerly task- and work-package oriented
approach to focusing on how to reach our goals (= the
client’s goals!)
Shifting the focus from just writing about features to
discussing and understanding functionality
Team-work and discussions help us to understand the
client’s needs and build the perfect solution
© CSS GmbH | Juni 2013
Agility is all about Values and Principles
Shifting from a plan-driven to a value-driven project management
Shifting from a formerly task- and work-package oriented approach to
focusing on how to reach our goals (= the client’s goals!)
Shifting the focus from just writing about features to discussing and
understanding functionality
Team-work and discussions help us to understand the client’s needs
and build the perfect solution
46
Source: Pawel Brodzinski
© CSS GmbH | November 2014
Great! Super! Fantastic! Let‘s work agile forever!
CONTACTDipl.-Ing.(FH) Sven Schweiger
CSS Computer-Systems-Support GmbH
Landstraßer Hauptstraße 167, 1030 Wien
Phone +43-1-712 18 21
Internet: www.cssteam.at
Dipl.-Ing. Mike Leber
Agile Experts e.U.
Joseph-Lister-Gasse 31C/9, 1130 Wien
Phone +43-699-18194880
Internet: www.agileexperts.at
Fotos: Gert Krautbauer / Sven Schweiger / München / Wien