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 ∙ [email protected] ∙ 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.

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

Agile Project Failure: Root Causes and Corrective Actions

Jeffery Payne Chief Executive Officer Coveros, Inc. [email protected] www.coveros.com

mailto:[email protected]


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.


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

About Coveros


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!


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


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


How often do project succeed anyway?


Root Causes of Agile Project Failure


Root Causes of Failure can be at Many Levels

Agile Team Level - Development process - Team members / roles

Product/ Project Management Level - Traditional project management and PMOs - Product management function - Sales and customer support

Organizational Level - Senior management - Organizational - Cultural


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


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


Who moved my cheese? – what you should do

Educate – knowledge allays fears

Show success on something small

Include, don’t exclude naysayers


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


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


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


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


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


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


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


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”


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


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


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


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


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


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)


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


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


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


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


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


Root Cause #8 – Scrummerfall

Scrummerfall: Waterfall development inside Scrum

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

Sprint #1

Design

Code

Test

Sprint #2

Design

Code

Test


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”


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


Root Cause #9 – Waterscrum done wrong

Co-dependent Waterfall and Scrum projects

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

Sprint

#1

Sprint

#2

Sprint

#3

Sprint

#4

Governance or non-agile project deliverables


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


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


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


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


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


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


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


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


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


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


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


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


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


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!


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


Questions?

Thank You

agile project failures: root causes and corrective actions

Technology

coveros coveros

agile copyright

agile development process

agile methods

group agile

agile development methods

agile development topics

founder of coveros