successful, agile working in the vortex of a waterfall ... · less principles craig larman and bas...

Successful, agile working in the vortexof a waterfall –

More with LeSSAgile World 20152015-06-29 | [email protected]

Agile World 2015 | 29. Juni | Valtech.de

MARK BREGENZERPrincipal Consultant Agile Methodology

Agile Experience: Scaling Scrum Fundamentals, Scrum Alliance 2015 Certified LeSS Practitioner 2015 Certified Scaled Agile Program Consultant 2014 Agile Coach since 2009, at Valtech since 2011 Certified Scrum-Master since 2007

Software development Experience: Since 1997 as developer, lead developer, subproject leader, technical Coach…

Telecommunication, automotive and insurance


Telecommunication.Experience

Developer

Scrum Master

Technical Coach

Agile Coach

Indien

China

Finnland

Deutschland


Automotive.Experience

Continuous: Weak test automation Integration builds on demand, on demand deployments and manual smoke runs,

manual regression tests

Quality & Release

Management

Scrum of Scrum

Germanyco-located

Embedded into waterfall


Automotive.Experience

Scrum Master

Technical Coach

Agile Coach

Germanyco-located


Management Coach


Insurance.Experience

Technical Coach

Agile Coach

Germanyco-located


Management Coach

Scrum Kanban


Disclaimer!!

Some of the following practices are not agile and not part of LeSS! But they may help in the vortex of a waterfall.


AGENDALeSS principles

  Project-/organization design

  Basis of successful agile working

  Reporting in non-agile environment

  Contract models with suppliers

  Project risks by non-agile environments

  Offshore


CHAPTER!!

LeSS principles


LeSS principlesCraig Larman and Bas Vodde introduced some rules within the third Lage Scale Scrum book. The rules help introducing LeSS in organization with different experience levels (Shu-Ha-Rhi). Now, LeSS meets the sweet spot between prescriptive approaches and principles.

LeSS principles!!

http://less.works!!


CHAPTER!!

Project-/organization design


Craig Larmans 4th law: “Culture follows structure” But how do we build new structures?

Project-/organization design!


Setup a structure where people start to talk   Multi team plannings, refinement and sprint review sessions

  Overall and multi team retrospectives

  Overall sprint review/demo with customer and management participation

  Open space, world café, fish bowl,… formats to connect people frequently

  Consider the LeSS Framework or LeSS Huge as a starting structure



Managers should give up their responsibility for a single team, they become mentors and teachers for the individuals. Management should act as a team sharing their work amongst each other. Managers should become drivers and experts for agile transition.

Management acts as a teamProject-/organization design!


Consider in your organizational design the amount of needed learning and social aspects. It might be the better approach to start with existing component teams, learning the basics of agile practices and principles first and then transform to feature teams.

Limit the amount of necessary learningProject-/organization design!


Self-organization doesn’t happen by announcing self-organization. In traditional organizations employees and managers often feel overwhelmed by jumping into self-organization.

Enabling self-organizationS

uppo

rting

beh

avio

r

Directing behavior

1 – 4: Managers and employees learn step by step to delegate and to take over responsibility.

4 – 1: Can cause uncertainty for managers and employees. Managers fear lost of control and employees feel overwhelmed by “accountability”.

If starting in 4 and problems arise, manager tend to walk towards 1, which is a very frustrating experience for employees.



Enabling self-organization   Consider Shu-Ha-Rhi

  In immature environments, employees and managers need parameters for self-organization

  Reconsider existing pressure to reach fixed milestones

  “Command & control” can improve or speed up change processes at the beginning of a transition

  Without transparency it’s hard to make the right decisions, provide a vision and the big picture

  Foster self-organization at the right levels and at the right time, consider accountability



Great opportunity to foster self-organization. Self-designing Teams at BMW (agile world 2014)

Self-designing team workshop

.…?Do you…

yes!

Dura%on Topic 00:10 IntroducFon/agenda 00:05 Project targets & vision 00:15 PresentaFons crosscuKng teams 00:10 IntroducFon ReOrg process & moFvaFon 00:20 Opening pracFce:

* Build a ship * Group according to tech. skills * Group according to business skills

01:40 ReOrg process: * 3 IteraFons 35 min. incl. Review * Less Fme for iteraFon 2 & 3

00:20 Closing ReOrg process: Find team names, find team room, vote Lead Developer/Scrum-‐Master

00:15 Team presentaFons 00:15 Closing: common acFvity 03:30



After the self-organizing team workshop the teams have to cope with team dynamics. A team building workshop can speed up the time the team needs to reach the performance phase.

Team building workshops

Dura%on Topic 00:05 IntroducFon/agenda 00:10 Ice breaker exercise 00:30 Team Knowledge Model (agile world 2013) 00:45 Agree on measures 00:30 Team Vision/Charta 00:50 Team challenge outdoor

“Toxic waste” 00:10 Closing/Feedback 03:00

Socializing: Lunch or dinner



Collocate as much as possible!



CHAPTER!!

Basis of successful agile working


Basis of successful agile working!

How do big groups come to valuable and fast decisions?


Democracy vs. sociocracy

Decisions in teams and big groups

VS.



Every voice counts, the aim is to find and eliminate root causes of possible resistance. Resistance is only possible, if it’s based on basic principles!

Sociocracy: Consent decisionsBasis of successful agile working!


As basic principles to reason resistance use the principles of the agile manifesto and the LeSS principles. Additional defined principles should not conflict them. http://www.agilemanifesto.org/principles.html http://less.works/less/principles/index.html

Sociocracy: basic principlesBasis of successful agile working!


In the opposite of democratically decisions consent decisions focus on resistance with the aim to eliminate them. All parties should be able to accept the decision. Therefore the chance that people support it is much higher than in democratically decisions.

Sociocracy: Consent decisions

http://www.thesociocracygroup.com/ http://www.soziokratie.com/




There are some technical aspects, which are critical to succeed in an agile environment.


Basis of successful agile working!!

Technical excellenceFocus on high test automation, on test coverage, code coverage, cyclomatic complexity and coding rules. Consider the “standard” tool SonarQube.


Test pyramid Use the test pyramid to focus on technical excellence. Consider the agile development system as learning opportunity, coach and trainer.


System & Interface TestsEnd 2 End (incl. GUI <10%)

dynamic & static QA,Unit, Module, Component Tests (>80%)

Otherman.

Tests (<5%)

Exploratory Tests (<5%)

automated Testfeedback loop

Manual Testing

find

poss

ible

failu

re o

ne le

vel e

arlie

r



Agile development system Just a Continuous Integration server is not enough!

Build traditional CI incl. QA

Deployment & integration

functional tests Reporting

Agile development system

Central repository & master-build concept



ArFfact repository

Report repository

Load repository

Source repository

Central Storage

Developer workplace Source snapshot Local reporitory

Developer workplace Source snapshot Local reporitory

Developer workplace

Source snapshot Local repository

Download

Check-‐out/ Check-‐in Check-‐out

Download/ Upload

Component Build Unit Test System Build All components Building artefacts Quality Build Code Coverage StaFc code analysis ...

ConFnuous IntegraFon System

Store loads

Build reports

Developer testsystem Developer testsystem




Test reports Traces, logs

Load detecFon

smoke check-‐in

ConF

nuou

s InstallaFo

n &

E2E-‐TesFng

regression nightly

non-‐funcFonal

developer test system

Automated

installaFo

n; te

st-‐

execuF

on; sym

ptom

collecFon

onsite/offsite/offshore

Transparency (e.g. Web pages, mailing…)


Build history viewThis table shows all builds of the product with it’s corresponding quality state. This enables to select at the end of a sprint the potential shippable product increment rather than working on a version, which can be shipped.


master-build manual regression smoke quality performance

Product_1.0.321

Product_1.0.320

Product_1.0.319

Product_1.0.318

130/0

127/0

130/5

130/0

1045/3

1045/0

1089/0 Blocker: 0 Critical: 0 Major: 0

Ok

Blocker: 1 Critical: 0 Major: 12

Blocker: 0 Critical: 1 Major: 0

Not OK

Ok Not OK

Ok

Not OK


Functional view of the test automationThe detailed view of a master-build shows each functional area with it’s current functional quality. By drilling down it’s possible to reach the original problem via a functional perspective. All stakeholders can detect immediately which function is broken.


Functional area duration coverage ATDD regression

Offering

Product

83%

65%

23:45

7:16

41/2

34/0 36/2

43/3

Finance 65% 7:16 34/0 36/2

Customer 80% 12:07 45/1 47/3


Functional view of the test automationThe detailed view of a master-build shows each functional area with it’s current functional quality. By drilling down it’s possible to reach the original problem via a functional perspective. All stakeholders can detect immediately which function is broken.


Functional area duration coverage ATDD regression

Customer

Create Customer

Finance 65%

83%

80% 12:07

5:12

7:16

45/1

34/0 36/2

47/3

21/0

Modify Customer

Delete Customer

15/3

11/0

3:55

3:01

13/1

11/0

21/0

62%

90%


User Story status modelIn this case User Stories are considered as the smallest item in the Product Backlog. This is an example from a customer. It’s usable for all kinds of backlog items, but should be used for the smallest items only. In terms of a hierarchical organized Product Backlog.

Basis of successful agile working!!!


Reporting data an User Story should contain


  Status (e.g. new, in analysis, ready, committed/planned, accepted)

  Estimates (Story Points, person days or no estimates!?)

  Sprint (Sprint names reflect an order)

  Release (Release names reflect an order)

  Team

  Release relevance (must have | optional)

You might need further data, such as requestor, market, country, reference to epic/theme, test status…


User Story state historyKnown from Kanban as cumulative flow diagram. This chart makes queues visible and enables an active management by the teams.



CHAPTER!!

Reporting in non-agile environment


Reporting in non-agile environment!!

Navigation needs more than a target.

You need to know your current position!


Good to know, when starting with reporting


  Agile practices and empirical process control deliver much more KPIs than traditional processes

  The content/KPIs of project reporting changes over time (start early and small)

  Take the data from Product Backlog (tools), Continuous Integration system and test automation

  Most available reporting tools do not support all of the following metrics

  Automate and visualize as much as possible, use a project radiator



Attention:

Often reporting prevents transparency!



Functionality, Features Testing & Quality Assurance

Process, Organization and Costs

Project Reporting

Reporting Reporting Reporting

Project Management


Functional progressAs part of visual management it’s helpful to create the functional progress related to important functional areas of the project.




Velocity & default User Story sizeTo know the team-/project velocities and the current average user story size is essential for significant forecasts and planning of upcoming releases.



Velocity & costsThe relationship between velocity and costs creates transparency about scaling aspects and enables budget forecasts.



Can’t you understand, that we need the estimate for our release/milestone planning. Milestones are not agile. You have to understand

agile values and principles!

That’s not Scrum! The team is self-organized and does the estimates! No one else!

No Problem, if you have User Stories we can make them ready and estimate them next sprint.

Hey, Scrum-Master. I need an estimation for a new feature.

That’s too late! And right now it’s just an idea. We only want a rough estimation.

Business must know the costs for this feature now. Bernd could estimate it in a half day.

The team is busy. You have to wait until the team can analyse the feature.



Idiot!

Agile doesn’t work for us!

Manager!

We don’t need them!



Hey guys, why don’t you take the numbers form the Product Backlog?

What? What?



Team estimates without teamsThe teams estimate their User Stories as usual. The average User Story size represents a default value. With this default value it’s possible to determine sizes of default epics and themes.

Max

70%

Range

Average

e.g. Story Points

Use

r Sto

ry c

ount

Theme

Epic

US

[3,6; 5,7; 7,8]

[6,1; 7,2; 8,3]

5,3 SP

x

x

38 217

32 - 44 137 - 296

Defaults

Ranges

Product Backlog


Advantages of default values and ranges


  Rough estimates are immediately available

  Teams still do the estimates

  Using ranges based on variances improve the numbers

  Visible different levels of inaccuracy

  Teams will not be disturbed for rough estimates

  This enables setting waterlines in the Product Backlog

Non-normalized Story Points over the teams make this technique more complex. Recalculate the default values and ranges every sprint (last 3-4 sprints).



Release forecastUsing the default values for non estimated items allows to calculate the remaining Product Backlog size. The average velocity enables to draw educated (guesses) burn downs.



Calculate Backlog waterlinesBurn downs are often not enough for traditional thinking organizations. Business departments want to know what’s in and what’s out of scope. Based on the previous explained default values, the ordered Product Backlog can be extended by waterlines to answer that question.


Defect reportingA cumulative defect flow chart shows open defects over time. Defects take resources from development. The defect balance chart gives the transparency about new/reopend and solved defects. The runtime chart helps to keep defect runtimes short (consider pareto).



CHAPTER!!!

Contract models with suppliers


Contract models with suppliers!!

Time & Material

Pros

•  High flexibility, because scope is not part of any contract

•  Purchaser responsibility for project management

•  Less overhead on supplier side

•  It’s easy to hire people from different suppliers

Cons

•  Some legal problems in Germany with “Arbeitnehmer Überlassungsgesetz”

•  Purchase departments do not like this model

This model allows the highest flexibility and can reduce the contract gaming between purchaser and supplier.



Fix price modelHumans love fix prices! It’s nice to know the costs, or better to belief that the costs are fixed. Fix prices create an illusion of certainty.

Pros

•  Purchaser pays a fix price •  Some flexibility, because

scope is changeable •  Margin opportunities for the

supplier? •  Risk reduction for purchaser? •  Purchase departments like

this model

Cons

•  Supplier establishes an own project management

•  Different project success & risk perspective

•  Contract gaming regarding size & scope of Backlog Items

•  remaining contingent influences Backlog Item sizes



Fix price based on # user storiesThis model enables forecasts independent from different estimates of teams and would work even for no-estimates approaches. This demands equal sized Backlog Items or at least some grouping of similar sizes like small, medium, big… with a fix contingent/price.

Pros

•  Easy reporting •  Normalization of estimates

across teams not needed •  Works with no estimates

Cons

•  Difficult to determine costs for themes or epics

•  Remaining contingents will influence the Backlog Items sizes

•  Stakeholders try to put more content into a Backlog Item

•  Bigger Backlog Items



Fix price based on # story pointsThis model enables more detailed forecasts for features, epics and user stories. In multi-team approaches it’s helpful to normalize the story points across the teams, at least per requirement area.

Pros

•  Smaller Backlog Items •  Transparency about sizes of

themes or epics

Cons

•  Normalization of a story point across the teams


Contract Model.Experience story

$

$

PB-‐Changes

monthly



Lower costs?

$

$ $$$$Risks!

$

PB-‐Changes

monthly


?


Fix Price!

Fix Price!

Fix Price!

# US


How they agreed on fix price for #US


  Elaboration of project velocity (#US) related to project costs

  Introducing 3 categories of sizes: small, medium and large

  Only feature implementing teams were allowed to deliver user stories

  A warranty buffer was agreed, based on traditional experiences


  The expected velocity was higher than the elaborated

  Upcoming maintenance support was not considered as work related to user stories

  Ramp up of cross-cutting teams was not considered

  The bigger the user story, the cheaper for customer

Some of the initiated problems




PB-‐Changes

Every two sprints

$

$ $$$$

Every sprint #

$



$

PB-‐Changes

Every two sprints

$

full full MS L

Fix conFngents

$ $$$$

Every sprint #

more more

less less


$


$

PB-‐Changes

Every two sprints

$

MS Lfull full

Fix conFngents

Every sprint #

?


$

Contract Model.Experience stoy

$

PB-‐Changes

Every two sprints

faster! faster!

$

MS Lfull full

Fix conFngents

Every sprint #


$

Contract Model.Experience stoy

$

PB-‐Changes

One sprint

Yes! Not my risk!

Need to change!

MS Lfull full

Fix conFngents

Every sprint # $



Qualify the content!

Fix Price!

Keep Fix Price!

# SP


$


PB-‐Changes

$

MS Lfull full

Fix conFngents

Every two sprints

more more

less less



Agile maximum fix price = Concept Analysis + Concept Implementation

Concept- Analysis Fix price

Concept-Implementation Fix price, recalculated after analysis

Alternative Model?It‘s hard to es%mate analysis

Remaining budget can influence quality of analysis

Wild guess at the first es%ma%on

Size of concept delays feedback loops!


And the moral of the story?


Fix price contracts initiate

the contract game external

and internal! They are an

impediment for agility!


CHAPTER!!!

Project risks by non-agile environments


Larman’s 4 laws of organizational behavior:

Project risks by non-agile environments!!

  Organizations are implicitly optimized to avoid changing the status quo middle- and first-level

manager and “specialist” positions & power structures.

  As a corollary to (1), any change initiative will be reduced to overloading or redefining the new

terminology to mean basically the same as status quo.

  As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, and “needing

pragmatic customization for local concerns” — which deflects from addressing weaknesses and

manager/ specialist status quo.

  Culture follows structure.



Transparency can become an enemy

today Releasedate

faster faster

Reporting burn down charts showing that current velocity is not sufficient to reach the project targets, can increase the pressure from outside.



Transparency can become an enemyReporting burn down charts showing that current velocity is comfortable to reach the project targets, can increase the project scope in early phases.

today Releasedate

more more



Transparency can become an enemyReporting current planned content, BPIs above the waterline, could be misused from surrounding traditional managers to consider the shown BPIs as fixed like in a contract. Even worse if they use changes to discredit the project as not reliable.

contract contract


Balance transparency & reporting

  Explain the meaning of velocity and forecasts

  Ensure must have and optional scope indication in the Product Backlog

  Report to surrounding managers according to must have scope

  Report content above waterlines as preliminary

  Use ranges (remaining scope/velocity) to decide the right traffic light color, if they are requested




Agile vs. non-agile projectsTraditional waterfall projects usually work in four phases.

Business proposal

System proposal ImplementaFon System IntegraFon

Test



Agile vs. non-agile projectsAgile projects, embedded into an program with non-agile projects, often start iteration after the business proposal phase.

Business proposal


Test

Business proposal

System proposal ImplementaFon System IntegraFon Test



Agile vs. non-agile projectsBut at the end of a release, a common milestone steals time from an agile project. So comparing the productivity of agile- with non-agile projects at this time, can lead to wrong assumptions. Even worse, if investments into a CI system are not considered.

Business proposal


Test

Business proposal


System IntegraFon Test


Risks by these wrong assumptions


  Image of agility can turn to inefficiency

  Managers could start to request higher velocity and increase pressure

  Developers could postpone fixing end 2 end tests and defects

  Developers could open their secret toolbox



Agile vs. non-agile projectsBased on a strong CI system and high quality assurance, agile projects are able to deliver new features during the system integration test phase. This increases trust.

Business proposal


Test

Business proposal



Project envy


  Traditional sibling project may tackle the project to hide own weaknesses:

  By pointing out increased “hardware” costs

  Express their doubts about the efficiency of the agile project

  Complaining that agile projects are not planable/predictable

  These agile guys do not behave as the rest of the company


CHAPTER!!

Offshore


Offshore!!

Offshore?

Don’t do it!

But…


Offshore development can work quite well, if:

Offshore!!

  One development system, one trunk, same transparency is ensured

  Working with offshore suppliers is prevented/limited

  On- and offshore units work independent as much as possible (requirement area)

  Management practice GoSee (gemba walks/stands) at all sites

  Physical exchange between employees happens frequently

  Video conferencing systems, web cams… are available

  All sites participate the overall planning, review/demo at least remotely


CHAPTER!!

Summary


Keep focus

Summary!!

LeSS principles are helpful to succeed even in the waterfall environment

  One product, one Product Backlog, one status model, one powerful development system

  Focus on working software and technical excellence, prevent branching

  Self-organization doesn’t happen just by delegating

  Prevent contract games by choosing contract models that enables cooperation

  Calculate default values/ranges and provide forecasts

  Focus on functional progress, quality, organizational progress and costs every sprint

  Connect people frequently, e.g. by synchronized plannings, reviews, retrospectives…

STAY COOLSTAY AGILE ;-)MARK BREGENZERPRINCIPAL [email protected]

successful, agile working in the vortex of a waterfall ... · less principles craig larman and bas...

Documents