Abstract
So what would you say if we told you an Agile view of project status would be that all projects start in RED and have to work their way to GREEN status? Would you rather respond to the RED status early or when it's too late? Failing early gives you (sponsor, project manager or team) the opportunity to recover and see hidden or small failures and resolve them quickly. Agile development framework provides daily opportunities to see potential small failures and resolve them before they get to be BIG failures. The first part of the paper establishes the fundamental knowledge of Agile development and the key processes, artifacts, and meetings. The second part discusses the big and small failures that can be found in a project. The third part provides real work examples of successful failures using agile development. The fourth part highlights way a project manager can look for early failures.
Introduction
According to a survey by VitalSmarts (2007) published in their Silence Kills study there were some alarming statistics found about the rate of project failure on major corporate initiatives. Here is a summary:
- 82% of employees within companies with significant organization-wide initiatives underway, believe those projects will fail.
- 78% are currently working on a “doomed” project.
- 90% knew early on that the project would likely fall short of the objectives.
- 77% describe these projects as “slow motion train wrecks.”
- 81% believe it is impossible to approach the failing project's key decision-maker.
The study identified five crucial areas that are the most costly barriers to project success.
- Fact-Free Planning. Deadlines and resource limits are set with no consideration for reality.
- AWOL Sponsors. Sponsors not engaged and don't provide leadership, clout, time or energy to see the project through.
- Skirting. People work around the priority setting process.
- Chickens. Team leaders and members don't admit when there are problems, waiting for someone else to speak up.
- Team Failures. Team members unwilling or unable to support the project. Possibly lack of empowerment.
Agile Development Framework
Part 1: What is Agile?
Agile refers to a set of values and principles that govern a style of software development that encourages iterative, collaborative and results-focused development. Agile is the umbrella for several popular methods such as Scrum, XP and others.
The key Agile Values and Principles outlined in the Agile Manifesto (2001) (www.AgileManifesto.org) emphasize the need for high customer collaboration during project planning and execution, high degree of interaction within the team and continuous feedback, frequent and early measurement of working software, (or other deliverable), and ability to quickly recalibrate and respond to the changes on the ground. These values address all of the five crucial project failure areas above.
We follow the Agile Lifecycle shown in Exhibit 1, which emphasizes the need for the Release Planning and Iteration 0 activities in addition to the common sprints/iterations for most larger projects.
Exhibit 1. Agile Software Development Lifecycle
New Skills Needed to Make Agile Succeed
The transition to Agile Development is not as simple as it may seem; to the contrary, there are many points of failure related to incorrect adoption of processes, team foundation, and leadership skills needed to make Agile succeed.
As a project manager, the key new skills you will need to learn are:
- Servant Leadership—Leading high performing empowered team without commanding and controlling them
- Effective Facilitation—You will need to learn how to effectively bring groups to consensus
- Agile, Scrum, XP Processes—You need to learn real world methods for applying sound project management and engineering practices to your projects
- Agile Release Planning—You will need to learn how to effectively gather requirements, size, prioritize, and develop a high level schedule for Agile type projects
Part 2: What Does Project Failure Look Like?
Big Failure Signs
These are easy to brainstorm. They are the ones that appear too late in the game and cause the project to go into RED status (by our measures, this project should have been RED for a while!).
- Project has missed several milestones
- Project is now over budget
- Customer is show signs of dissatisfaction with final deliverables
- Employees and staff are burned out
- Project managers struggling to comfort sponsor and gain confidence back
- Missing the date or reducing the promised deliverables becomes inevitable
Small Failures that Lead to the Big Ones
We don't always see or even look for small failures, because as project managers, we are so focused on the big failures. After all, the big failures are the ones that can put our projects at risk. Small failures occur every day and have a way of compounding if not addressed. In fact, small failures are the ones that lead to big failures. By seeing the failures early, we can mitigate them and avoid failures. Here are a few small failures that if not addressed can turn into big failures.
- The project does not have the right people
• The right skills
• The right number of people
• The right availability of people
• Business and information technology—the right mix of cross-functional roles
- Technology failures
• New software that was not proven early or tested
• Hardware that arrives too late or does not meet basic requirements
• Integration issues with external or internal systems that were not planned for early or tested
• No clear and agreed upon backlog of non-functional requirements, which leads to out of scope backend work
- Training failures
• No upfront training on the required technology. Team “figures it out as we go.”
• Leadership. No leadership buy-in or training on Agile and Servant Leadership. Leaders continue to command and control team, which leads to hiding of information and problems that could be identified early.
• Business. Business partners are not trained on how and why to collaborate with IT. They don't engage, don't provide direction on priorities, don't respond to questions quickly, don't iteratively and continuously test and provide feedback on deliverables.
• Coaching. The “We can learn and do this alone” adoption method with no expert coaching.
- Process failures
• No daily stand up meetings to help identify impediments early and mitigate them.
• No reoccurring feedback/retrospective sessions that allows the team to point key failure points or concerns.
- Schedule—Hard deadline
- Budget—Not enough money to cover the completion of the project
Part 3: What is a Successful Failure?
#1 Failing Early Case Study—Absent Resources
Case Study #1 was a data warehouse project for Financial Business Partners. The core team was successful in Sprint 0 in designing and installing the hardware and software needed for the project. Sprint 1 was building the physical table structures for the financial data. The database administrator (DBA) was typically absent from the required daily stand-up meetings and her work was not getting completed…IMPEDIMENT. ScrumMaster addressed the issue with sponsor and DBA manager and offered several alternatives. The DBA manager selected to come to the daily meetings with the DBA and ended liking the daily communications and collaborations. The manager also realigned the work to allow the DBA to be dedicated to data warehouse project. The team could have loss months of time waiting for tables to be generated, but the impediment was resolved within 24 hours.
#2 Failing Early Case Study—New Software
Case Study #2 was a portal project for Human Resources. The team was provided some basic training on the new portal software. In Sprint 0, the team successfully installed all new hardware and software for the project. The designs were completed and the team was ready to start coding in Sprint 1. After one week, the team was behind on every coding story. The project would be at least six months late in their delivery. A team member stated at the daily stand-up meetings that the coding was harder than anticipated and the training was too basic…IMPEDIMENT. ScrumMaster addressed issue with sponsor and chief technology officer and resolved within 24 hours. Training was not adequate for project complexity; brought in expert for 30 days to train team and caught up on the schedule. Collaborated with customer for realistic delivery date, one month later.
#3 Failing Early Case Study—Set Budget
Case Study #3 was a Business Intelligent project delivering hundreds of complex financial reports, graphs, trends, and analysis. The business sponsor's requirements included hundreds of reports. A product backlog was created to document all the requirements as features and then stories. The sponsor assigned a priority to each story. The sponsor, ScrumMaster and team built the release plan for all the stories. Quickly the sponsor realized that she did not have enough budget for the project. The current budget would not allow all stories to be completed; so only the high level priorities were scheduled to be delivered. At the end of the project, 90 stories were no longer required by the sponsor to be delivered. They were identified as high priority at the beginning of the project; but the business priority changed and the project could easily change with it. This saved the project ~$500,000 by not implementing low priority or no longer needed requirements.
#4 Failing Early Case Study—Large Projects
Case Study #4 was a large enterprise-wide project that had been tried twice before…and failed. This third approach was using agile development methodology. Requirements were documented in the product backlog. The core team was trained in agile development and co-located with their business partners. The team quickly adapted the agile techniques and forged ahead each sprint. Collaboration was very high and impediments were identified early and resolved. The results: The developers worked with the business to collaborate on the design; so communication was improved with minimal design documents. The developers worked with the business to test so they could resolve defects on the spot; avoid rework and minimize waste. In each Sprint, software was tested so when production implementation came, it was a “non-event”. By following the agile development framework, you work in an iterative or evolutionary manner and only do the high priority work that is needed by the Business.
Part 4: Looking for Early Signs of Failures with Agile
#1 Impediments
At the Daily Scrum or stand up meeting; each team member describes what he/she accomplished for the project the day before; what they will do today; and if they have any project impediments. An impediment is something that will not allow team members to continue their work. The ScrumMaster's number one priority to the team is to help them resolve impediments. The ScrumMaster takes these impediments very serious and resolves them within 24 hours or they are escalated to the next level of management.
#2 Task Board Where Too Much Work Is In Progress
The Agile task board can be as simple as sticky notes on a wall; an electronic spreadsheet, or a sophisticated Agile software application. Whatever you use, it should provide you with signs of potential early failures. If your task board has all the tasks in progress or started, then it could be a sign that thetTeam is not working the priority of the stories. The team may get a lot of work done on the majority of the stories; but the goal of the Sprint is to complete the stories and deliver working software. It is better to get 85% of all your stories completed and accepted by the business; then to have 100% of your stories 50% completed and no working software to show your business partners.
#3 Task Board Where People Are Working Vertically
If your task board has the majority of the task in progress and they are all being designed; and then they are all being coded; and then tested; this is working vertically. Many project managers will call this the Waterfall Method or if you are using Agile, Scrumfall.
Waterfalls are wonderful tourist attractions. They are spectacularly bad strategies for organizing software development projects.
- Ambler, Scott (2006, p. 1)
Agile allows you to focus on the high priority stories and design, code, test, and deliver the working software and the next day do the same thing with the 2nd highest priority story. Again, it is better to get 85% of all your stories completed and accepted by the business; then to have 100% of your stories 50% completed and no working software.
Final Words
In summary, failing early gives you the opportunity to recover and see hidden failures and resolve them quickly before they become large failures and put your project at risk. Agile development framework provides you with several ways to see and hear of small failures before they become big failures and put your project at risk. So failing early in agile development is a GOOD thing.
