Failure is inevitable but it isn't permanent

@thomasstiehm #AgileDC
© COPYRIGHT 2018 COVEROS, INC. ALL RIGHTS RESERVED. 1
Agility. Security. Delivered.
Failure is Inevitable But it
Isn’t Permanent
Thomas Stiehm

• Coveros helps organizations accelerate the delivery of
secure, reliable software
• Our consulting services:
• Agile software development
• Application security
• Software quality assurance
• Software process improvement
• Our key markets:
• Financial services
• Healthcare
• Defense
• Critical Infrastructure
About Coveros
Introduction
Development Capabilities

Understanding Failure
Antipatterns and ways to avoid them
“You don't drown by falling in the water; you
drown by staying there.”
― Edwin Louis Cole

What can be done:
Start with a goal in
mind, it can change as you
learn
Use progressive
planning to tune your
destination
“If you don't know where you're going, any road will get you
there.” – Lewis Carroll from Alice in Wonderland
Don’t be that Product Owner
Decide where you want to go
No product vision

Agile transformation can be little more than adding daily
standups to an existing “SDLC” or an ad hoc process.
Don’t be that team
What can be done:
Start by using a defined framework
Learn the value of practices before changing them
Get the whole team involved in process improvement
Define and follow your defined path
No process followed

Agile practices are an overlapping and support each other.
Some teams only implement the low discipline practices and
wonder why things don’t work out for them.
Don’t be that team
What can be done:
Embrace all practices
Get help implementing the hard ones
Focus on technical excellence, quality, and automation
With no compensating practices
Process practices are ignored or removed

Who has heard “We will automate tests later”. Does later
ever come?
It is hard to move fast doing everything manually,
don’t be an all manual team.
What can be done:
Insist on automation from the beginning
Use automation the same in every environment
Show the value of automation
Include build, deployment, test, and OPS automation
Plan for automation and automation maintenance
Automation is not valued or planned

Have you set yourself up to fail by not telling your
stakeholders what can be done? Have you let them believe
they are going to “get it all” when you know they aren’t?
The road to hell is paved with good intentions, don’t
move to hell.
What can be done:
Management of stakeholder expectations
• Learn to say no
• Learn to say not now
Let them ask for anything but set their expectations on
what is really going to happen.
Keep the stakeholders in the know
No Expectations Management

Have you worked on a project where you have tried to test
quality into the software after development was done? How
did that work?
Don’t short-change testing on your schedule to save
time or money or anything else
What can be done:
Get QA involved in the beginning
Give testers the time and tools needed to really do
their work to make the software have higher quality
Actually believe that testers can add value beyond
random manual testing
Plan for quality from the start, no really do it.
Quality and testing are an afterthought

Have you had stakeholders that dictate all of the terms of a
project before a team is even selected.
Don’t be afraid to tell stakeholders and the team the
hard truths
What can be done:
Negotiate from the start, be as realistic as you can
Facilitate discussion of the scope trade-offs
Get everyone to watch the Henric Kniberg “Agile
Product Ownership in a Nutshell” YouTube video -
https://www.youtube.com/watch?v=502ILHjX9EE&t=2s
Learn to say the hard things
No negotiation allowed

Have you ever worked on a project where someone else
estimated the work and you were asked to live up to those
estimates?
Don’t try to live other people’s estimates.
What can be done:
Establish the cone of uncertainty around any previous
estimates right away
Insist on using Agile Planning techniques that include
the team doing the work giving the final estimate just
before doing the work
Negotiate away other peoples estimates
Other people do your estimates

Have you ever had a critical dependency on a person that
only worked on your team part time? How did that work out
for you?
Don’t time slice your critical path work.
What can be done:
Negotiate to get critical people on the team full time
Have part time people mentor our team members
Have part time people provide instruction and
oversight
Schedule the critical items early in the project
Arrange for key team members to be full time
Part time team members in the critical path

Have you worked at a place where a lot of people left around
the same time? What did that do to your goals? Turn over
drains morale and leads to more people leaving.
Don’t be the team that dies by a thousand cuts
What can be done:
Figure out why people are leaving and make a change
Refocus the remaining team on the work
Let people express their feelings about the changes in
the team or work environment
People get projects done
Heavy team turn over

Have you been part of a project where the politics of the
projects had more to do with the success or failure of the
project than the software? What was the result?
Don’t be a pawn, fight against it.
What can be done:
Focus on delivering software that meets users needs
Get help shielding the team from the politics
Use the politics to your advantage
Learn to play politics and shield the team
Politics is more important than success

Have you worked with a team that was distracted by outside
concerns? Even positive external events can derail a team.
Negative distractions can make progress impossible.
Don’t be the team that watches the project fail.
What can be done:
Focus the team on what is within their control
Keep the team energized on the work
Get the team to concentrate on getting the work done
Shield the team from outside concerns
Outside distractions taking team time

How many times can you do the same thing?
• The team stops trying to change
• The team wants to have fewer retros
• The team gives up on change
Don’t have boring team meetings.
Things to try:
Different Retro formats, there are dozens
Team building instead of a retro (periodically)
Giving up the reins and having someone facilitate
Change things up to keep them fresh
Stagnant Retrospectives

• Focus on getting out of the danger zone
• Learn to break bad news and take the blame
• Learn to negotiate
• Shield the team from distraction
• Don’t give up until you are ready to give up
• Treat people well and expect to be treated well
Tom Stiehm
tom.stiehm@coveros.com
@thomasstiehm
Don’t let setbacks become permanent failure.
Wrap-Up

Tom Stiehm
tom.stiehm@coveros.com
@thomasstiehm
Don’t leave with unanswered questions.
Questions

Failure is inevitable but it isn't permanent

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Failure is inevitable but it isn't permanent

Similar to Failure is inevitable but it isn't permanent (20)

Recently uploaded

Recently uploaded (20)

Failure is inevitable but it isn't permanent