Tear It Down to Build it up - TriAgiletriagile.com/wp-content/uploads/2018/04/Tear-It-Down-to-Build-it-Up.pdfthey fear failure or starting something new ... Agile Software Principle

Tear It Down to Build it up

Case study in progress

Arjay HinekRed Hat Global Agile CoachApril 5, 2018

INSERT DESIGNATOR, IF NEEDED

I need your help


I need your help


I need your help


I need your help

A tale of two teams


● Run, run away, fast● ASk them why they think they want to be Agile● Ask them what problem they really want to solve● Ask them what their actual product is● Ask them who their customer is● Start re-orienting the way you are looking at the problem

What do you do?

What are the problems?● Communication gaps not being

closed● Each team starting the project

independently● “We already held the kickoff.”● “We have the funds. Don’t

you?”

What are the problems? symptoms?

Projects needed to be started in a way that was conducive to Agile thinking

We grabbed a room and here’s what happened next while mapping:● The teams spotted gaps.● The teams spotted dependencies.● The teams discovered sequencing issues.● We stopped and asked--”So what are we

looking at?”○ Created a shared mental model○ Created Shared Ownership in the

project

Yaaayyyyyyy. Little Victories


OK, You got them started. Now What?

“Help us do this with every project”“In every region.”“In a model that scales”

What Gave us pause?● We aren’t delivering software● “Regular and frequent releases” needs to be

re-framed in a construction model● We do not have the luxury of refactoring● Different kind of customer--”I need an office.”● External dependencies slow the tempo on

nearly all tasks● Our teams are never collocated● Our customer need is often based on lease

expiration


Here’s how it unfolded. . .

John Boyd

● I had an ambiguous problem to solve● I knew Agile Could help, but was not a great fit● I knew Mental Modeling would get them on the ”Same Page”● I knew Construction “daily huddles” would fit● I knew the answer would have to evolveTherefore, we would need to expand Agile’s boundaries to other systems. Which means--

I needed to re-orient


Always Be Orienting John Boyd

More specifically

“If we don’t communicate with the outside world–to gain information for knowledge and understanding–we die out to become a non-discerning and uninteresting part of that world.” –John Boyd


OODA the heck out of things--Non-software (and even many software) teams fail because. . . ● they fear failure or starting something new● they focus on mechanics rather than principles● they have been intimidated by a dogmatic approach● they treat the principles like an a la carte menu● they do not understand what they are modifying ● they lack discipline

“With Agile, it’s all or nothing, man!”“With Agile, it’s all or nothing, man!” Kevin, a guy I don’t like

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

We are continuously improving on ways to deliver completed and integratable project work by doing it and helping others do it. Through this work we value:

Start At The Beginning

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Individuals and interactions over processes and tools

Adaptive, Customer-centric delivery over fixed, chart-centric management

Completed and integrated work over comprehensive documentation

Decentralized team member planning over centralized planning

A Very Good Place To Start

Finding balance in the whole

daily comms

technical excellence

sustainable pace

face to face

continuous improvement

Self organizing teams

deliver value regularly

embrace change

deliver working software

provide space for motivated teams

Keep it simple

deliver what the customer values

Finding balance in the whole

daily comms

technical excellence

sustainable pace

face to face

continuous improvement

Self organizing teams

deliver value regularly

embrace change

deliver working software

provide space for motivated teams

Keep it simple

deliver what the customer values

The Principle Differences

Agile Software Principle Pragmatic Delivery PrincipleOur highest priority is to satisfy the

customer through early and continuous delivery of valuable

software.

Our highest priority is to identify and satisfy customer needs through early and regular delivery of completed and

integratable work.

"identify" : Our customers come to us with a high-level need (I need a floor), and then we have to identify what can fit, and the negotiation begins.


Agile Software Principle Pragmatic Delivery PrincipleWelcome changing requirements, even late in development. Agile

processes harness change for the customer's competitive advantage.

We fully acknowledge that change in a project is inevitable; however, we

choose to respond to it in a manner that is the least disruptive to the

customer and the project.

Changing requirements are exponentially more expensive in construction, so our focus is on early identification and transparency of impact.


Agile Software Principle Pragmatic Delivery PrincipleBusiness people and developers must

work together daily throughout the project.

Team members, along with Architects, Designers, and Stakeholders, must

work together nearly daily throughout the project.

We have a broader set of diverse skill sets included in every project


Agile Software Principle Pragmatic Delivery PrincipleBuild projects around motivated

individuals. Give them the environment and support they need, and trust them to get the job done.

We build projects around motivated teams of collaborative individuals. We

give them the environment and support they need, and trust them to

get the job done.

We felt we needed to be more emphatic about being collaborative because this was such a big divergence from the way things were done before.


Agile Software Principle Pragmatic Delivery PrincipleBuild projects around motivated

individuals. Give them the environment and support they need, and trust them to

get the job done.

Effective communication to and within a team should be immediate and

conversational to every extent possible; where face-to-face conversations are the

ideal, depersonalized blanket emails should be seen as “throwing it

over-the-wall” behavior.

Co-location is a luxury that few can afford. Rather than throwing everything out, we felt the spirit of the message is that we try as much as possible to be face to face.

Here are the things we are doing that seem insane from a mechanical point of view

● We do not estimate story size● We do not predict velocity based on historical throughput-sort of● We work with an external PMO that insists on using waterfall● Stories often have a single owner of all story tasks● We do not use burndown charts--yet● We are applying Agile principles to work that physically requires

linearity

Should Agile be an All-or-nothing approach?

● We do not estimate story size● We do not predict velocity based on historical throughput-sort of● We work with an external PMO that insists on using waterfall● Stories often have a single owner of all story tasks● We do not use burndown charts--yet● We are applying Agile principles to work that physically requires

linearity

Should Agile be an All-or-nothing approach? Kevin? Should it?

FREQUENTLY ASKED QUESTIONS--time permitting

How do you work without sizing?

The teams are very focused on thinking through what they can accomplish by the end of each iteration.

It definitely causes stress.

They are still figuring out what their version of “INVEST” is (PLVRSI)

How do you predict velocity or provide estimates?

Velocity gives us predictability, but● if every project is different● if projects often use different

vendors● if team membership often fluctuates

(for now) We have a false sense of predictability

Instead, we find ourselves determining which components take a set amount of time or have fixed lead times..

Could you just have standups?

standups certainly help with the rapid turn-around of information, but they do not stand on their own in terms of providing a shared sense of ownership and camaraderie.

Can’t we just plan like we do in waterfall and use Agile mechanics to be “agile”?

● What problem are you trying to solve by doing that?

● Just going through the motions? Don’t.

● Centralized planning? Iteration planning and ownership breaks down.

● Anything is better than nothing, but build something that you can sustain.

Doesn’t individual ownership of stories kind of ruin everything?

It does make it harder to keep people engaged with one another, but many pieces of a project puzzle are sequential and, therefore, have built in dependencies. We miss out on team refinement of stories, but we do get good group thinking at the project level.

How do you track burndown?

One of the hardest things for me to let go. We don’t use a burndown-- at least not yet. If we did use a burndown, we would use a story burndown.

Are we getting the most out of Agile?

It depends on how you define "the most."

If you start with nothing, and you are getting something of value. . .

Doesn’t this only apply to a very specific type of team?

The practices of these teams only apply to a small subset of industry.

The concept of reviewing the manifesto and its principles is wide open to all.

Know Your customer

Know your product

Measure your success

Doesn’t this only apply to a very specific type of team?

● Who is our customer? ● What is our product?● How can these be reflected in a manifesto and a

full set of principles wholistically?● What problem is this project solving?● Can this project be mapped?

I maintain that the following questions are agnostic to any team; therefore, the model will benefit, potentially, all teams:

Fast Forward 1 yearHere’s what I hope I to be telling you about in a year

● Upper management and Project Finance fully support the Pragmatic Delivery team model and allow to staff projects accordingly

● If projects cannot adapt to Pragmatic Delivery, they go Waterfall--i.e., they do not water this model down

● We have regional teams that never work on more than 2 projects at a time.● We have a someone acting as a Pragmatic Delivery Team coach for each region.● We have a Global Pragmatic Delivery coach who keeps the practice consistent

while ensuring it continuously improves.● Members from all teams meet by role to ensure cross-team awareness and

consistency in practice (a la the Spotify communications model)● Managers have seen enough success that they allow teams to self organize and

deliver

Questions

Tear It Down to Build it up - TriAgiletriagile.com/wp-content/uploads/2018/04/Tear-It-Down-to-Build-it-Up.pdfthey fear failure or starting something new ... Agile Software Principle

Documents