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
2 © Copyright 2012 Coveros, Inc.. All rights reserved.
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.
3 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
4 © Copyright 2012 Coveros, Inc.. All rights reserved.
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!
5 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
6 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
7 © Copyright 2012 Coveros, Inc.. All rights reserved.
How often do project succeed anyway?
8 © Copyright 2012 Coveros, Inc.. All rights reserved.
Root Causes of Agile Project Failure
9 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
10 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
11 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
12 © Copyright 2012 Coveros, Inc.. All rights reserved.
Who moved my cheese? – what you should do
Educate – knowledge allays fears
Show success on something small
Include, don’t exclude naysayers
13 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
14 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
15 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
16 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
17 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
18 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
19 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
20 © Copyright 2012 Coveros, Inc.. All rights reserved.
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”
21 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
22 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
23 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
24 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
25 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
26 © Copyright 2012 Coveros, Inc.. All rights reserved.
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)
27 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
28 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
29 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
30 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
31 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
32 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
33 © Copyright 2012 Coveros, Inc.. All rights reserved.
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”
34 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
35 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
36 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
37 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
38 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
39 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
40 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
41 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
42 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
43 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
44 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
45 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
46 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
47 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
48 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
49 © Copyright 2012 Coveros, Inc.. All rights reserved.
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!
50 © Copyright 2012 Coveros, Inc.. All rights reserved.
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
51 © Copyright 2012 Coveros, Inc.. All rights reserved.
Questions?
Thank You
Top Related