This is a post I wrote for the now defunct pebblecode.com aimed at some conservative enterprises.
If you have engaged a development consultant in recent years, you have probably heard them wax lyrical about, “Waterfall is dead, we’re Agile” – but what does this actually mean for your product delivery? What is the business case for engaging with Agile?
Neither Agile or Waterfall are actually software development methods. Waterfall is the collective name for more traditional project management methods that have sequential separate stages from planning, design, implementation, testing to maintenance. Agile methods are incremental and adaptive methods for delivering software. The values and principles can be found in the Agile Manifesto.
Across the software industry there is no common definition of success of a project. Is it on time, on budget, to specification or fit for purpose? From each of these points, both traditional methods and Agile can be used to successfully deliver software products, however, research has found that Agile methods are a more effective way to deliver software.
Agile methods have many benefits but are not a panacea for software delivery. There are no guarantees, however, we believe these methods allow us to deliver the best quality and offer value for money for our customers.
Here at pebble {code} we use Agile methods in the development of all our projects. We have distilled the best/core practices from methodologies like Scrum and XP to created a lightweight Agile Framework that gives us the flexibility to apply them to the kind of projects we run with the minimum of ceremony.
Will the spec change over the life of the project?
One of the pathologies of traditional project management is scope creep. In traditional methods everyone agrees to the contract up front and spec changes are managed through some change control process. Each change will cost you; it is going to mean creating a change request, budget approval and back and forth with a purchase order and so on.
Traditional methods work hard to keep things on schedule by controlling scope. Unfortunately, this means, at the end of the project and a large investment, you risk getting a product not fit for purpose and losing your competitive advantage.
How certain are you about your assumptions?
Assumptions add risk to your project because they can turn out to be false. In fixed cost pricing, you have plan up front and no doubt those costs are passed on to you. Worse is when a false assumption is simply missed and it derails your project.
Traditional project management methods invest a huge amount of effort in documenting, tracking and managing assumptions and risks (if they do anything at all).
Are there any other uncertainties?
…there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don’t know we don’t know. – Donald Rumsfeld, 2002
There are many unpredictable things that could cause delays to your project. Developers get sick, get poached by rivals or go AWOL. Technologies have security flaws discovered. Suppliers go bust.
We can never identify all risks that might go wrong – there are almost infinite possibilities. You have to mitigate this risk by building in a significant contingency. These risks might never happen; forcing someone into a fixed price contract will inevitably lead to them adding this risk to the cost or failing to deliver on commitments when something goes wrong.
Mitigating Risks and Increasing Agility
Agile methods embrace change; changes are easily incorporated into the process of prioritization and planning that takes place at the start of each sprint. It is a much more efficient use of your budget. Change is managed, not prevented; you become adaptable.
Typically teams take work from a Product Backlog, which is ordered by priority. The Product Backlog contains things like User Stories and bugs. Product Backlog items are deliberately left as open as they can be. Detail is deferred which allows the specifics to be filled in as the product is developed and more information is gathered.
Software development is a process of continuous discovery. Agile’s iterative approach allows assumptions to be tested each sprint, for example, by getting the software in front of real users or, perhaps, doing performance testing on a piece of technology for its feasibility. If you find your assumptions are incorrect, you adapt during your prioritisation session and waste little or nothing.
Agile technical practices, like collective code ownership, work to reduce the risk that any one developers absence will cause delays or stop work. This practice helps the architecture of the software evolve by sensible practices rather than mirroring the social structure of the team.
Commitment to decisions are deferred as long as possible. This is sometimes called the Last Responsible Moment. Making decisions at the Last Responsible Moment is a risk avoidance strategy; decisions made too early in a project are hugely risky. The earlier you make a decision, the less information you have. In the absence of information, work might have to be re-done or thrown away. Another way to think of the last responsible moment is before your options expire.
When building software products, it is near impossible to get everything right first time. Agile methods allow you to evolve quickly, respond, and adapt. Through frequent testing and stakeholder (customer) engagement we can be sure we get it right as quickly as possible.
Agile methods can respond quickly and effectively to the complexity and uncertainty that characterise today’s business needs.
Dave's Blog 