No new Agile program aims for failure. Yet poor planning by unprepared and ill-informed team members who fix their sights on unrealistic goals will essentially doom a project from the very start.
The software development success rate published in the Standish Group’s Chair Report is among the most commonly cited research in the IT industry, and it provides an interesting perspective. Over the past two decades, there has been little change in the results:
- 29% of projects “succeed”
- 48% of projects are “challenged”
- 23% of projects “fail”
I believe no program ever aimed for failure and with each methodology, we saw different pitfalls but when it comes to success all boils down to the planning. With waterfall, projects failed because they did way too much planning. Agile projects fail because they do way to less planning. Yes, projects fail when you don’t plan. For everything we do in life we need a plan, otherwise, we will never know how to get from point A to point B. Now, the secret is in how much time you put into that plan.
The Agile Manifesto states:
Individual and interaction over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
It is very important we understand that, as practitioners, we are asked to value responding to change “over” following a plan, not “instead” of. The key is how we read the manifesto. I do see people making the mistake of saying there is no need for process and tools, documentation or planning but is important that we consider when the Manifesto was written and what were the prevailing views on how software development should be managed. Back then companies were using methodologies which required a huge amount of documentation, process, and up-front planning, and to sustain that they were building armies of people whose job was to create such documentation, process, and plans. There will be a huge amount of information created about a software that would never be developed as the business requirements have changed too much while all the planning was done. It was not meant as a call for the second set of actions to be discontinued, just that the first is more important and thus should be prioritized.
How important is planning to a successful Agile program?
I go back to what I said before, that the way we look at any program/project is exactly how we do everything day to day in our life. If I say I want to go on a vacation to Europe I will not just pick-up and go; I know you will say there are people that do that but the question is if everyone will do that how successful will they be? How many will find a plane ticket to go today, how many will find a hotel to stay when they get there, … I do set a goal to travel next year, I do make a plan that I should buy the tickets 2-3 months in advance, then the hotel attractions but you will not plan each day by the hour 1 year in advance. We need a plan but again how much time do you spend on the plan and when is the key to be successful.
I believe it’s important to have the goal and to understand planning at each stage because that allows for opportunities to create more value and that implies success.
We recently worked with one of our clients to productize a new way for their customers to interact with the services they provide. The goal was to provide an API that will allow development teams to create light-way mobile clients that don’t require any of the heavy business knowledge integration into the applications. Because of the business requirements, a partnership with multiple clients and number of users (2+ million) we knew this is not an easy task, but there was a high-level plan on how this could succeed and we knew is going to overall be 1-2 years until everyone will use it. We began with ballpark solution design, estimates, plans on how product teams will bring this to customers, we knew there were a lot of moving parts that need to be started and how they have to connect to each-other in order to onboard everyone on the new product but we did not go into detailed planning right away for all of them.
What should be taken into consideration when setting a project’s scope?
In the CHAOS report, even though the success trend line is flat, when you dive into the data there is some good news and shows how improvements can be achieved
- Smaller is better
- Agile project is far more likely to success
- People are the primary driver of projects success or failure
That is how we approached the planning for the project I was mentioning earlier: small is better.
We truly believe that the project scope is a subset of the scope of the product under development and we characterize Agile requirements as high level and focused. So instead of defining the scope for the final product and how every integration will be done, we take a small set of business cases for which we created a model, created a server-side design, created a client-side design, created a plan to be integrated as part of an existing client functionality. I put an emphasis on creating because when I say create I do mean we put a plan on what will it take, how will components interact together, what would it take to see a first app using this, when will that be possible and the teams that we will need to deliver it.
On what criteria should Agile team members be selected?
It is very important to have an organization that when it looks at the essential components for software development, will view people as more important than either process or technology. Linking again to the CHAOS report, it was seen that people are the primary driver of projects success, so invest in the right people.
Organizations adopting agile need enthusiasts but it should avoid purists and those believing in a single truth. There is no single path to becoming agile or sustaining the accomplishments of an agile team. Purists demand strict adoption and may dismiss ideas that are in tune with the existing culture; there is also a risk of them alienating employees and leaders.
Agile teams are self-organized and they rely on team flexibility, autonomy, and diversity. For these, we need team members with a good degree of emotional intelligence and adaptability. We want people that value feedback and build an organization that constantly looks for improvements. Select people who are open to change, enjoy challenges and are willing to do what it takes to ensure success, including learning skills outside their current skill set.
Capers Jones’s research indicated that over 60% of software errors are introduced in the analysis or design phase. Issues introduced at the beginning of the project are often caused by poor communication and misunderstanding so people that can effectively communicate and collaborate are the bedrock of a successful team.
How important is communication to a successful Agile initiative?
As said above communication should be one of the criteria on which an agile team is built. Poor communication is recognized as the major cause of project failure because often results in delivery of the wrong solution.
Effective communicators understand that the goal is to share information, that that the information sharing is a two-way street but we need to understand how different communication methods work and how they should be used together.
When it comes to agile, these are some of the channels used for communication:
- face-to-face conversations
- project planning, release planning, sprint planning
- product vision statement, roadmap (communicates end goal for the team and the organization)
- backlog (communicates the scope of the project to everyone)
- taskboard (visual status to everyone)
- daily scrum (coordinate the priorities of the day and identify challenges)
- sprint review (convey project progress)
- sprint retrospective (communicate improvements)
- collaborative solutions (whiteboards and digital collaboration tools)
We are a global company, and most of the companies we work with have distributed teams, so we can never have a successful agile project without a team that is using all the communication channels. It is very important for everyone to adopt them and pick the right mode of communication at any point. When is the information, that I want to discuss with one person, important for other team members? With the tight and frequent deadlines agile has, the decision to discuss this in a sprint planning and not during a face-to-face conversation is what makes us successful in the long run.
What will the developers deliver to the customers if there wasn’t a clear product vision statement to follow? This is big risks that without communication any agile initiative will fail. There might be some that will think agile will allow you to iterate faster and fix the mistakes, but again that will not happen unless you communicate what was wrong.
What’s the best way to win support from management and staff?
One of the biggest communication challenges is building and sustaining an understanding of the agile process among key stakeholders and sponsors.
Providing understandable and visible milestones and demonstrable product during development is key so that sponsors and stakeholders get a sense of progress. This, in turn, helps to manage their expectations and facilitates communication about issues and schedules
But to truly win everyone, management and staff, you need to create the possibility for them to use the product that you are building.
How important is testing to project success?
if everyone in your company has the possibility to use the product that is being built it will make a project more successful. So we challenge everyone we work with and our employees to no longer think that testing is a phase of the project.
Now, when we look at the role of a tester, we believe it goes beyond the person who is “just testing” and logging bugs. It is about them working part of the development team, working closely with the product owner to improve the quality.
The testers are the people that are best equipped to connect business needs with the actual results of the product. In agile terms, they are in the best position to qualify the user stories and determine how to objectively measure their completion. Testers often have a better understanding of user needs than developers. Likewise, testers have a more technical understanding of application design than users would need. This unique position allows them to take a holistic approach to a users story definition saving the entire team time and frustration.
What is the role of customer feedback in a successful Agile project?
Standish changed what “successful” means in 2015 report. Previously, a successful project was on a budget, on time, and on target. “On target” was never a good measure because it lacked any measure of customer outcome. So they replaced that measure with a measure of customer perceived value. This resulted in a 7% decrease in the rate of successful projects. I believe that says a lot about how important the role of customer feedback is on successful projects.
Now if we come back to how important is for Agile projects, I believe customer feedback is the cornerstone of a company’s transformation on how they deliver. When we work with companies that go through a digital transformation the number one requirement we put an emphasis on, is to create a digital feedback loop between engineering and customers. Second is to reduce the time for the feedback as that proved that will increase the customer satisfaction as we deliver the exact value at the right time for a customer.
One of the most important success factors in agile is that management and project team members acknowledge and accept that everyone will constantly have to improve their planning through the duration of the projects.
An organizational culture that encourages team spirit and learning are key to successful delivery of agile programs.