Building a successful software product is no trivial task. Even with a solid vision, a talented team, and an ample budget, a project can still fall apart. In fact, more than two-thirds of technology projects fail outright.So how exactly do projects fail? One day at a time. It’s rarely some single catastrophic event that brings a project down. It’s usually a slow, methodical deterioration over months or years—sometimes called a “death march”—which teams are aware of but can’t seem to prevent. How many of these questions resonate with you?
Building a successful software product is no trivial task. Even with a solid vision, a talented team, and an ample budget, a project can still fall apart. In fact, more than two-thirds of technology projects fail outright.
So how exactly do projects fail? One day at a time. It’s rarely some single catastrophic event that brings a project down. It’s usually a slow, methodical deterioration over months or years—sometimes called a “death march”—which teams are aware of but can’t seem to prevent. How many of these questions resonate with you?
Is your project over budget?
Are you behind schedule?
Are you having trouble figuring out when you’ll be done?
Are you producing more bugs than features?
Is morale low? Is turnover high?
Are user expectations not being met?
If you answered yes to any of the above questions, then your project may very well be on the death march. Fortunately, the industry has developed techniques for dealing with these problems. They go by the name Agile.
Agile is essentially a philosophy on how software should be built. Agile itself is not strictly a process; it’s more of a framework under which various actual software development processes, such as Scrum, Extreme Programming, and Feature Driven Development, have been created. The Agile movement has re-invented the way we build software, and if you’re not familiar with its principles, you owe it to yourself and your team to check it out.
If you need further convincing, here are six reasons why Agile leads to better software:
Agile incorporates external feedback into the product throughout the development process. This is made possible largely by a key concept in the Agile world: the iteration. Rather than writing the entire body of software at once, the team breaks the functionality up into small chunks and implements a few items at a time over the course of a short period (usually 2 – 4 weeks). At the end of every iteration, the system is demonstrated to stakeholders. This gives them a chance to see the progress being made, give suggestions on the direction, and allows the team to correct any misunderstandings or incorporate any important changes that have come up. The concept of the iteration may be Agile’s greatest contribution to the world of software development. If you do nothing else, your team should seriously consider developing in an iterative manner. The benefits are significant.
Agile methods favor real-time verbal communication over documentation. The fact is that humans communicate much more effectively when words are spoken rather than written. Not only are detailed requirement documents time consuming and tedious to generate, they ironically tend to create confusion and misunderstandings. This is because documents are one-sided conversations and lack the back and forth dialog between users, management, and developers that is needed to truly define something as complex as software. Instead of trying to enumerate and convey every single use case, edge condition, and error state in a written document, it’s far more efficient and effective to sit down in a room with your team and hash these out together. Often times this process will identify unconsidered scenarios, eliminate unimportant concepts, and put the team on the same page about exactly how the software works.
Under Agile, visibility into the work being done is given special attention. Teams are encouraged to publish progress information such as automated build server logs for stakeholders to see. Users and managers are encouraged to attend demos and other meetings. Developers often make builds regularly available for testing and use by stakeholders. This visibility enables the team to keep the project on track. Management no longer has to turn the project over to the development team and hope they get what they want six months later. They can see everything that’s going on in the project on a daily basis.
The fundamental point of each iteration is to generate working software. The idea is to focus on user-facing features that add tangible value to the product, which keeps the team focused on the ultimate goal: releasing a product. Over time iterations progressively layer on features, which enable stakeholders to see the product take shape over time. This gradual evolution of the product not only allows the team to more quickly identify problems and course-correct, but it also improves morale and creates positive momentum that carry projects forward.
Since Agile methods break work into small iterations, your team will begin to develop predictability. After a while it will start to become apparent how much work can be accomplished in one iteration, and this can be used to make predictions about the overall schedule of the project. In the Scrum world for example, the average number of story points that your team finishes in a sprint can be used to extrapolate how much time is needed to finish all the work left in the product backlog.
The continuous feedback and incremental implementation help resolve any potential issues early and quickly, which means there is much less risk of having to discard months of work and start over. Software is a moving target, especially for startup projects. It’s crucial that your project can embrace change rather than breakdown in the face of it.
In a follow up blog post, I will describe how Scrum, the most popular Agile method, takes these principles and puts them into practice. We use Scrum on many projects at Eureka, and we’ve had a great deal of success with it.