Traditionally managed projects with a fixed brief, price and deadline don’t do as well as agile managed projects. That’s why one of the IT trends of the last decade is the move to agile project management and the Scrum methodology.
Have you ever agreed on a specific scope, time and price for a web project as a client or contractor and the project didn’t turn out as you, or perhaps the other party, had hoped?
You are not alone.
Many times we have been in this situation as a contractor and gotten burned. They’ve written off jobs worth hundreds of thousands of pounds. Even the client in this situation was not happy about the extended deadline and a result that was not exactly what was expected.
E.g., the FBI “threw $170 million down the drain” in 2000 for an internal system whose traditionally managed development took 5 years and eventually had to be halted without result. (In 2010 they tried to re-develop it agilely and succeeded. Development cost half and the system began to be used in real cases.)
What are the most common causes of these failures?
- The original assignment is not specified enough. It contains spaces. Both client and contractor assume a certain scope and quality, but each is different. (We’ve already written about the unreasonableness of giving and requiring a software warranty.)
- The brief changes as the work progresses. For example, the client delivers content that is significantly richer than anticipated in the original proposal.
- No reserve estimates. During development, unexpected obstacles are often encountered that can never be 100% estimated in advance. In our experience, we need to allow for reserves especially for:
- Connecting the application to other systems e.g. accounting software. The vendor is actually responsible for the work of other people (e.g. accounting software developers), but he did not choose them himself. Complicated connections can throw a lot of sticks under their feet and extend delivery deadlines.
- Using new technology that may look promising, but also bring unexpected hurdles with application development and deployment.
Solution?
Develop sotware with an agile methodology.
Agil manifest
In 2001, when the agile movement was emerging, its main proponents came up with a manifesto on what values software development should be based.
Individuals and interactions before processes and tools.
Agile Manifesto
Functioning software before exhaustive documentation.
Customer collaboration before contract negotiations.
Responding to changes before sticking to the plan.
While points on the right are valuable, points on the left are valued more.
Agile development methodologies are then based on these values.
Waterfall vs Agile Development
The left part of the figure shows a classic waterfall software project development – that is, a project where what, when and for how much is defined. As you can see, the sponsor practically can’t introduce new requirements into a project already underway. He can only comment that what is in the specification has not been delivered. But even a well-written specification doesn’t capture reality 100%. If the contractor accepts the client’s demand – usually vague – as the specification, he has just made hay with smouldering embers.
But the biggest problem is changing the assignment. In our experience, to some extent, we change the assignment for every project over 100 hours of work.
On the other hand, in agile project management development, change of assignment is envisaged as the project is created iteratively. The work is divided into smaller parts that are delivered sequentially.
There is still an overall plan for creating the project. There are defined milestones that the project is supposed to achieve over time.
| Waterfall | Agile Development | |
|---|---|---|
| Task | ❌ Need exact specs at the start, Changing it means increasing the deadline and price | ✔️ Changes are expected |
| Delivery speed | ❌ The result is only seen at the end of the project | ✔️ The results are Seen incrementally (after iteration rounds) |
| Clear budget and deadline | ✔️ Fixed price and deadline for the whole work (unless the brief changes) | ❌ Only an estimate of sub-tasks, Payment by hours worked |
| Change cost of assignment | ❌ High (rework is done after finished product) | ✔️ Low (problems are responded to immediately, prioritized as it progresses) |
| Supplier-customer relationship | ❌ Haggling over months-old specs and contract | ✔️ Collaboration and communication |
Agile Development Results
In 2013, a study was conducted with 173 software teams in which the teams were asked to evaluate the success of development according to the methodology used. The successes of agile development clearly outweighed the traditional waterfall approach.
Agile
- 8% failed
- 64% succeeded
- 28% succeeded with difficulties
Waterfall
- 18% failed
- 49% succeeded
- 33% succeeded with difficulties
Source: 2013 IT Project Success Rates Survey Results
Agile development also scored clearly better than waterfall development in this study in terms of quality of outcome, value to the sponsor, return/profitability of the project, and time/deadline.
“Our” lightweight Scrum
For agile project management, the most commonly used methodology is Scrum. In its full scope, it is suitable for projects where at least a few people are working full-time (around the clock). See documentation of the full methodology.
Copyright: Lakeworks – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=3526338
Our web projects tend to be at the lower end of full Scrum usability, so we use “our” reduced version of Scrum.
How does the development work in practice?
- At the beginning of the project, we create a usual plan for how we will proceed. This is not too different from the waterfall approach, except that in the agile plan we go into less detail. We estimate the time and funding required to develop each milestone and therefore the entire project. The estimate is non-binding, although we try to estimate realistically.
- We arrange regular 2-4 weekly meetings with the client (called Sprints). At the meeting we will discuss:
- Demo. We will show what we have created since the last meeting. We will also discuss what went wrong or where there were problems or unclear assignments.
- Requirements. Is the work delivered OK or will we make any changes? Have requirements evolved and will the assignment need to be modified? We write down the client’s requirements so that we can create a workable assignment from them later.
- Schedule. We schedule the tasks for the next Sprint, i.e., for the next meeting. Typically, the highest priority and reasonably priced (estimated number of hours) work will go to development. We can estimate and schedule the simpler requirements from the previous step right away, and work the more complex requirements into a doable assignment later after the meeting.
Nearly all larger projects (worth hundreds of hours of work) are now agile development. Even clients seem to appreciate this way of working, see our references:
Nothing is impossible, whatever we thought up has been realized to the smallest detail.
Ladislav Meškán, The Perfect Experience
