Agile Project Failures: Root Causes and Corrective Actions

TF
Half‐day Tutorial
6/4/2013 8:30 AM

"Agile Project Failures:
Root Causes and Corrective Actions"

Presented by:
Jeff Payne
Coveros, Inc.

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073
888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

Jeff Payne
Coveros, Inc.

Jeff Payne is CEO and founder of Coveros, Inc., a software company that builds secure
software applications using agile methods. Since its inception in 2008, Coveros has become a
market leader in secure agile principles and has been recognized by Inc. magazine as one of
the fastest growing private US companies. Prior to founding Coveros, Jeff was chairman of the
board, CEO, and cofounder of Cigital, Inc., a market leader in software security consulting. Jeff
has published more than thirty papers on software development and testing, and testified before
Congress on issues of national importance, including intellectual property rights, cyberterrorism,
and software quality.

Agile Project Failure: Root Causes and
Corrective Actions
Jeffery Payne
Chief Executive Officer
Coveros, Inc.
jeff.payne@coveros.com
www.coveros.com

© Copyright 2012 Coveros, Inc.. All rights reserved.

1

Trainer

Jeffery Payne
Jeffery Payne is CEO and founder of Coveros, Inc., a software company that
helps organizations accelerate the delivery of secure, reliable software. Coveros
uses agile development methods and a proven software assurance framework to
build security and quality into software from the ground up. Prior to founding
Coveros, Jeffery was Chairman of the Board, CEO, and co-founder of Cigital, Inc.
Under his direction, Cigital became a leader in software security and software
quality solutions, helping clients mitigate the risk of software failure. Jeffery is a
recognized software expert and popular speaker at both business and technology
conferences on a variety of software quality, security, and agile development
topics. He has also testified before Congress on issues of national importance,
including intellectual property rights, cyber-terrorism, Software research funding,
and software quality.


2

About Coveros

 Coveros helps organizations accelerate the delivery of
secure, reliable software
 Our consulting services:
– Agile software development
– Application security
– Software quality assurance

 Agile services
–
–
–
–
–
–

Agility assessments
Process improvement
Hands-on agile software development
Agile project management
Agile testing and automation
Agile training by role

3

Pop Quiz: Agile Development Means …
 No documentation. We don’t need to write anything down!
 No process. We can do it any way we want!
 No overtime. We can go home at 5!
 No management. We decide when to deliver!
 No testers. Who needs them anyway!

4

What Agile Actually Is
 An approach to software development that recognizes that
building software is much more of a design process than a
construction process
– Adaptive over Predictive
– People over Process
– Visibility into the Process

 Agile Methodologies
–
–
–
–
–

Extreme Programming
SCRUM
Lean Development
Crystal
Agile RUP

5

Agile Development Process
 Just in time requirements
definition
 Integrated design,
development, test
 Automated build, test,
deployment process
 Disciplined iteration scope
control
 Intimate customer involvement
throughout entire process
 Continuous improvement


6

How often do project succeed anyway?


7

Root Causes of Agile
Project Failure


8

Root Causes of Failure can be at Many Levels

Organizational Level
- Senior management
- Organizational
- Cultural
Product/ Project Management Level
- Traditional project management and PMOs
- Product management function
- Sales and customer support
Agile Team Level
- Development process
- Team members / roles


9

Root Cause #1 – Who moved my cheese?
 Resistance to change kills a lot of agile initiatives.
 Most people don’t like change … particularly those who
didn’t think of it 
 Challenges
–
–
–
–

Politics – Agile changes corporate dynamics
Turf – Agile changes the definition of “success”
Apathy – Many people don’t want to learn on the job
Subversion – Some will actively work to sabotage Agile


10

Who moved my cheese? – early warning signs
 “Agile doesn’t work for X”
 “Agile shouldn’t impact my group”
 “Agile is a fad”
 Line managers who insist on being part of projects
 Managers who will not use the dashboards and
measurements the team is using

11

Who moved my cheese? – what you should do
 Educate – knowledge allays fears
 Show success on something small
 Include, don’t exclude naysayers


12

Root Cause #2 – Culture of distrust
 Agile depends upon trust between the business and IT.
 Many organizations have a culture of distrust built up from
many, many years of failed initiatives and broken promises
 Challenges
– Makes planning difficult to accomplish in an Agile manner
– Makes completing of tasks in Sprints difficult
– Undercuts accountability


13

Culture of distrust – early warning signs
 Management will not agree that changes can be made to a
release plan
 Management will disagree with estimates and want “more
done with less”
 Management will nitpick individual story estimates
 Management admits that they push for unrealistic deadlines
on purpose

14

Culture of distrust – what you should do
 Hold firm on first Sprint estimate AND THEN DELIVER
 Hold firm on not modifying requirements mid Sprint
 Trust is rebuilt over time, not in a day or because Agile is
now involved


15

Root Cause #3 – Requirements churn
 Just because Agile encourages change does not mean it
can work in the face of constant change
 If requirements are never finalized (iteratively), nothing of
value will be built for the customer
 Challenges with requirements churn
– Estimates are not accurate due to vague requirements
– Significant amounts of rework are done


16

Requirements churn – early warning signs
 Product management wants to swap out Stories in the
middle of a Sprint
 You learn during the first Sprint that the Stories are not valid
/ accurate or too vague to estimate
 Priorities swing wildly from Sprint to Sprint


17

Requirements churn – what you should do
 Incorporate more customers into more UATs
 Hold the line of swapping Stories out during Sprints
 Increase estimates for Stories you believe are too vague as
they will likely take more time to finalize and implement


18

Root Cause #4 – Doing Agile vs. Being Agile
 Agile is not a methodology but a set of principles
 It is not the kind of process that you manage with a
clipboard. Or with “Nike Management” … Just Do It!
 Challenges
– Following the process becomes the goal instead of building great
software that satisfies customer needs
– The process is never improved because it is being “followed”
successfully


19

Doing Agile vs. Being Agile – early warning signs
 ScrumMaster or associated project management is more
concerned about following the process than the content
discussions
– During daily huddles
– During kickoff meetings
– During retrospectives

 Management asks if there is a CMM for Agile 
 The right things to do are often overrules as being “outside
the process”

20

Doing Agile vs. Being Agile – what you should do
 Designate a key technical member of the team to act as the
“internal ScrumMaster” and begin Being Agile
 Focus on customer feedback as it is the trump card over the
process
 Use your retrospectives to push adoption of additional Agile
principles


21

Root Cause #5 – Non-continuous software builds
 Continuous builds are a keystone of any Agile process
 Because Agile is so iterative, on-going and constant
feedback on quality is necessary to complete Sprints on
time
 Challenges with non-continuous builds
– Significant increases in debugging time/costs as the time between a
defect and its discovery increase
– Implementation of features / functionality on top of a broken system
significantly increases integration time later
– No ability to incorporate regression tests into frequent feedback loop
if continuous build isn’t maintained

22

Non-continuous software builds – early warning signs
 Evidence of successful builds on at least a daily basis does
not exist
 No urgency around fixing a build when it breaks (i.e. teams
are not forced to fix the build before the end of the day)
 No continuous integration software has been setup for use
by the team


23

Non-continuous software builds – what you should do
 Enforce a build policy that does not allow the team to finish
their work for the day before a successful build is done.
 Setup an open source continuous integration server if you
have no budget for anything else
– Hudson, Jenkins, CruiseControl

 Step toward a more rigorous definition of “build complete”
that includes successful testing over time


24

Root Cause #6 – Lack of test automation
 Most if not all testing that is performed during Sprints is
done manually by developers and/or testers.
 Often occurs when development is not fully vested in
performing adequate unit testing and/or test team does not
have the skills necessary to automate story, integration, and
system level tests
 Challenges
– Iterative development of features will increase the amount of testing
needed Sprint of Sprint
– Implementation defects will be identified too late in the process

25

Lack of test automation – early warning signs
 No interest / evidence of test driven development
 Manual testers are identifying implementation level defects
while performing high level testing
 Test team is not completing their test cycles within Sprints
and suggest that testing be carried over into the next Sprint
(parallel programming / testing Sprints)


26

Lack of test automation – what you should do
 Pair developers and testers to help developers learn how to
write good unit tests for their code
 Reassign a developer to be an “engineer in test” and
automate Story level tests on at least a part time basis
 Integrate these tests into continuous build process so all
code is regression tested frequently


27

Root Cause Exercise #1
 Identify some other symptoms of the first six Agile Root
Causes
 Determine some other ways you can help solve these
problems
 Present findings to class


28

Root Cause #7 – Inadequate Retrospectives
 Effective retrospectives at the end of each Sprint are the
key to iteratively moving toward an Agile approach that
works best for you.
 Kent Beck’s “Agile Maturity Model”
– All
– Some
– None

 Challenges with Inadequate Retrospectives
– Cookie cutter approach for Agile will often not work
– Sometimes throws the baby out with the bath water

29

Inadequate retrospectives – early warning signs
 Recommended process changes appear in the notes taken
at multiple retrospectives in a row
 All suggested modifications appear to be gravitating the
process back to a legacy process that did not work before
 No one leads the retrospective and makes sure that
recommendations are implemented


30

Inadequate retrospectives – what you should do
 ScrumMaster is responsible as the “servant leader” to make
sure the agreed upon Agile process is followed … this is
true of all modifications to the process as well
 Explicitly assign someone to implement each process
change and add it to the backlog if greater than a few hours
of work
 For each changed that is proposed, determine Agile
principles that are impacted and make sure new process
still adheres to these principles

31

Root Cause #8 – Scrummerfall
 Scrummerfall: Waterfall development inside Scrum
Sprint #1
Design

Code

Sprint #2
Test

Design

Code

Test

 Challenges with Scrummerfall
– Increases need for unnecessary coordination and documentation
– Decreases team velocity
– Difficult to fit into short sprints

32

Scrummerfall – early warning signs
 Entire development team is not working together day-to-day
on the same Stories
 Testing is often not completed by the end of a Sprint
 Testing of previous Sprint Stories is done in parallel with
design / development of new Sprint Stories
 Moving toward one 9-12 month “Sprint”


33

Scrummerfall – What you should do
 Pair a developer and a tester to work together on specific
Stories
– Tester helps developer think through unit and integration tests for
Story
– Developer builds functionality and automates unit and integration
tests
– Tester reviews / validates unit and integration tests
– Tester adds to system level test plan and creates additional tests
– Developer reviews additions to test plan

 Stories are not marked as complete until all testing has
been performed and defects are fixed

34

Root Cause #9 – Waterscrum done wrong
 Co-dependent Waterfall and Scrum projects
Governance or non-agile project deliverables

Sprint
#1

Sprint
#2

Sprint
#3

Sprint
#4

 Challenges with Waterscrum
– Temptation is to lapse into a Waterfall process to align with the rest
of the organization
– Team shirks it’s responsibility to the rest of the organization and
agile is disbanded
– Waterfall schedule slips and agile team does not adjust

35

Waterscrum – early warning signs
 Development team pushes back on providing necessary
documentation
 Agile team misses deliverable date(s) associated with
Waterfall schedule
 No visibility into progress on Waterfall process
 Team does not factor external delivery dates into Story
priorities and schedule

36

Waterscrum – What you should do
 Designate a team representative to communicate /
coordinate with the rest of the organization on at least a
weekly basis
– Should be the responsibility of the project manager or product
manager

 Assign a “customer” to the project from the Waterfall
initiative to assure agile deliverables meet organizational
needs
 Define documentation or functionality constrained by
Waterfall process in terms of Stories and place them in the
appropriate Sprints to meet Waterfall schedule

37

Root Cause #10 – Ad-hoc development
 Team characterizes its development process as Agile to
justify poor programming practices
 Poor development practices
–
–
–
–

Little or no structured unit testing
Little or no test automation or continuous integration
Little or no necessary product documentation
Handoffs between development and testing

 Challenges with Ad-hoc development
– Ad-hoc development has never worked within any software
development process except perhaps when prototyping something
– Significant quality and maintainability issues will exist
– Not a rigorous process

38

Ad-hoc development troubles – early warning signs
 Lack of evidence that adequate unit testing has been done
– No automation infrastructure to support unit testing
– Limited code coverage

 Lack of evidence that architecture / design has been thought through at
a high level
 Individual developers working on multiple Stories at the same time
 Lack of testers on the team
 Builds break and are not fixed within a day

39

Ad-hoc development – What you should do
 Incorporate unit testing infrastructure (ex. jUnit, nUnit) and
code coverage (ex. Cobertura, Quilt) into continuous
integration
 Incorporate design activity into Sprint kickoff meeting
 Incorporate test planning activity into Sprint planning and
Sprint kickoff meeting
 Pair developers and testers during Sprints

40

Root Cause #11 – Non-existent customers
 Customer’s are not involved throughout entire development
process
– Requirement definition / priority
– Functional clarifications
– User acceptance testing

 Challenges with Non-existent customers
– Significantly reduces the business value of Agile as requirements
are not validated
– Increases in rework due to changing requirements
– Reductions in Sprint velocity and productivity


41

Non-existent customers – early warning signs
 Customer is not intimately involved in initial planning phase
before Sprints
 Customer is not available to answer questions regarding
Stories / requirements during Sprints
 Customer is not part of User Acceptance Testing or UAT is
pre-scripted by development team


42

Non-existent customers – What you should do
 Proactively seek out at least one customer to be involved in
project
– Talk to customer support to identify the most “vocal” client you have
– Don’t assume you already know what customers want

 If customer simply cannot be involved day-to-day or even
week-to-week, work with customer to identify appropriate
“proxy” to act on their behalf
 Do initial User Acceptance Testing at the client’s site to
ease them into the process


43

Root Cause #12 – Frozen requirements
 Complete requirements list created up front that feeds into
Agile Sprints
 Often occurs when development group has moved toward
Agile but business side has not
 Challenges with Frozen requirements:
– 80% of requirements will typically not be useful to customers when
implemented
– Does not allow Agile team to adapt to changes in business
circumstances
– Prioritization of requirements across Sprints will not be accurate


44

Frozen requirements – early warning signs
 SRS requirements document has been produced for the
project
 Contract exists that specifies fixed requirements to be
delivered within a particular timeframe
 Customer is not available / willing to discuss Story priorities
during iterative planning process
 Business resists changes to upcoming Sprints based upon
customer feedback

45

Frozen requirements – What you should do
 Prioritize existing requirements so highest priority
requirements are satisfied first
 Discuss priorities with customer during UAT and highlight
differences between upfront plan and their needs
– May result in modifications to priorities that can help drive a more
effective process
– May result in agreement to change requirements once they better
understand the impact

 If business resists requirements change, pull customer into
discussion with business and get agreement

46

Root Cause #13 – Fixed scope … with a deadline
 Traditional project management fixes scope and estimates
schedule and resources necessary to complete project
– Sometimes all three are fixed in size!

 Agile project management fixes schedule (Sprints) and
resources (Staff available) and estimates scope
 Challenges with Fixed scope
– We don’t know what features have the most business value up front
– Customers don’t know what features have the most business value
up front
– The market changes constantly, necessitating change
– Scope is the most difficult thing to predict up front


47

Fixed scope – early warning signs
 There is resistance to any type of changes in priority, initial
scoping of a Sprint, or initial scoping of a release
 The word “time-box” gets introduced along with the
assumption that a particular scope will be completed within
the time-box
 Efforts to incorporate appropriate refactoring and rework
into Sprints are resisted


48

Fixed scope – What you should do
 Push back as hard as you can on this trend
– Explain how and why Agile works
– Emphasize that this is not Agile
– Emphasize the importance of building maintainable code and cost
of rework

 Vote with your feet!


49

Root Cause Exercise #2
 Identify some other symptoms of the last six Agile Root
Causes
 Determine some other ways you can help solve these
problems
 Present findings to class


50

Questions?
Thank You


51

Agile Project Failures: Root Causes and Corrective Actions

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to Agile Project Failures: Root Causes and Corrective Actions

Similar to Agile Project Failures: Root Causes and Corrective Actions (20)

More from TechWell

More from TechWell (20)

Recently uploaded

Recently uploaded (20)

Agile Project Failures: Root Causes and Corrective Actions