Agile Approach
Project Management is all about ensuring that the right thing is delivered, while reducing the risks inherent in a project, such as:
- late delivery
- going over budget
- delivering the wrong thing to the business
- delivering something the users don't like.
There are many ways of approach a project, and historically the waterfall approach has been the most popular, but it has many problems, not least that it is slow to deliver results and often delivers the wrong thing(!)
At Bright interactive, we prefer the more up-to-date agile approach because it specifically addresses these risks. Read on to find out why...
The agile approach
At Bright Interactive we take an agile approach to project management. We recognise that the stages of the waterfall approach are important (there must be some level of specification, design, build, test and acceptance) but the single biggest way to reduce the risks in a project is to get something in front of users early in the project, and update this often with feedback from them.
This means in practice:
- You won't have to read specification documents—we will work with you to understand what it is that you are trying to achieve and how we will build it, but the software itself (initially a prototype) is often the best 'specification'
- You will see something working within a few weeks of the start of the project—this won't be the complete solution, but enough to get all project stakeholders enthused and testing
- We welcome changes—since these provide the feedback loop for the final successful delivery.
The technical foundation to an agile approach
To achieve an agile approach we use the following tools and processes:- Python and re-usable frameworks enable us to code quickly and efficiently
- Automated testing tools allow us to improve quality across frequent releases, by rerunning regression tests on each release
- Automated rollout/rollback tools reduce the overhead of each release
- Bug reporting and tracking tools mean we spend more time fixing and less time managing task lists.
The old waterfall approach
Historically, the classic waterfall approach was designed to ensure that the right thing was delivered and that some level of predictability was provided to mitigate some of the risks above. Here's how it worked:
- The team consulted the client (and hopefully the users) and specified what they were going to build
- The team designed a solution to meet the specification, again hopefully involving the client and users
- The team built the solution
- The team tested that the solution met the specification and design
- The team released the tested solution to the client for acceptance testing
- The solution was released to the users
The problem with this approach is that it often took several months to complete, and with minimal communication between the team and the client or users, there was a good chance that the wrong thing was delivered.
The team could point to the specification and say "well, look, we delivered to spec", but often the users didn't read or understand the spec, or the business requirement had changed in the time it took to release the project.
So while the waterfall approach to projects gives a theoretical framework to ensure that the specified solution is delivered, it doesn't really deal with the more human side of projects:
- users often don't read or understand specifications
- users often don't know what they want until they see something
- users change their minds about what they want.