Agile vs Waterfall Project Delivery- Is there a better way?
So is there an alternative to Agile and Waterfall project delivery?
A lot has been written about Agile software delivery and Agile project delivery and the benefits of this over other methodologies. If you do not know what these are then please look up the Agile manifesto. In essence, though, what we are talking about is working in small incremental steps, usually about three weeks, constantly reviewing and iterating. The irony of Agile is that there are a whole host of people and businesses who stick to the methodology rigidly, which makes a bit of a mockery of calling something Agile. It has benefits, particularly over Waterfall delivery (again, look this up), but like all models they need to be flexible and to work for you.
The reason I do not give fixed elements to Discuss and Discover in my methodology is that it will change by industry, business size, age and goals. The methodology is designed to work for everyone and be adaptable enough for any type of business. How you then Deliver projects will again depend on your business, size, skillset, what outcomes you have purchased and timescales.
In Deliver we look at how to allow your projects to Deliver by whichever model suits your business best, but still giving you the oversight that you require as a leader to ensure the projects meet their outcomes. We will be looking at how to put together a project reporting template that works for your business.
Today, technology companies tend to deliver software through the Agile methodology. This is fine for the software companies. They can build software however they like. However, when it comes to your business you have to find what works for you. Agile often has large implications for the resources that you need to provide on a project. If you do not feel like you can cope with the resourcing or speed at which companies want to deliver, then do not. You do not need to follow the crowd. Your IT delivery team needs to work at the right pace for the company.
1. Deliver your projects
So how do you apply the Be The Five oversight to your projects?
In Agile the focus is on sprints. These are 2-3-week development cycles. I will not go into the detail of exactly what happens in each sprint as you do not need to know. This is one for your technical guys.
However, I dislike the term sprint, it is wrong and meaningless to those outside of technology and puts people off. In athletics a sprint is full-on, all effort, can go no quicker and be exhausted at the end race event. Think about a 100m race. We do not want that. Waterfall is more comparable to a marathon if you only saw the start and the finish. It is a slower but equally exhausting exercise. However, a development project is often just a number of sprints. We need to relate to something simple and easy to understand.
In athletics, there are many different types of race, and the first one, where it is a controlled sprint, is the 400m. Therefore, in this model we are going to work in races and laps. One lap of the track being 400m. We will relate a lap to being a week of time. Therefore, your project will be made up of a series of laps, that make up the race.
You do not need to keep the number of laps in a race consistent. You may Decide that the correct ‘race’ to run is for four laps (four weeks) initially to build the core of the product and then move to two-lap (two-week) races afterwards to gain better feedback on the key features. The choice is yours and depends upon what you are delivering, but you do not need to prescribe to a fixed time. Do what works for you. It may be a series of one-lap races, it might be five-lap races, or it may be a mix. Find what works and what you are comfortable with to be able to Deliver the outcomes you have looked at throughout Discuss and Discover.
For some technology builds, perhaps a rebuild of a website, you will not need to see anything for the first month at least as there is a core framework to put in place. Similarly, with smaller builds you may want to see developments weekly as you can achieve results quickly. This is one decision that is yours and does not need to follow a set rule book. Find a pace that works for your business. Not every company is a sprinter and not every project is a marathon. What is important, though, is that at the end of each designated race, however long, that you communicate progress to the business.
As the leader, if your team can report back to you based on the 5 Ds at the end of each race, then you will be in a good position to have a complete overview of the projects. Think of this as being the reporting layer above the developer or delivery layer. Give your project team the flexibility to find the right pace that works for your business.
2. Delivering the 5 Ds
Here is what you should expect to see in each element.
Discuss. Here your delivery teams can go further in depth and look at actual processes in more detail and how to improve these. This must be a joint effort with the users of the systems. Do not assume you know what the best process is unless you are involved in it or speaking to the right people. Do not underestimate the power of having proper, more detailed, conversations with people at this stage. One key discussion here is if any resources from outside the project will be required. This may be for testing or data checking. The resources and their availability should help you in Decide to plan how long this race is and potentially what in Discover is prioritised.
From a reporting perspective you will want to see who has been involved and what outcomes, processes and requirements have been Discussed. We need to see what resources are required in this race.
Discover. You have had the conversations. You have understood frustrations, pain points and poor processes. You know what they like and what they do not like. You can now start to pull this together into a list of requirements and outcomes. From the conversations you have had in Discuss, you should now be able to pull together a comprehensive list of these at a high level that will start to make sense from an outcome perspective. You can still iterate on specific functionality later, but the core outcomes you want to achieve should be well understood at this stage.
From a reporting perspective we want to see what outcomes the project is delivering and which of these are being delivered or part delivered during this race. Does this tie up with the resources available?
Decide. Any decisions that are made about this particular race should be collated here. The main decision that the project will make is going to be how many laps will be run in this race. Remember that one lap is a week of time. If you know that, based on Discuss and Discover, three laps are going to be required, then this needs to be reported. It helps the service managers plan their time and resources better if they know upfront who is required and when.
Reporting will cover any decisions that have now been made. How long is the race and how does this relate to the resources available? If there are any conflicts here, then you need to be aware of them. Do you have the necessary people available at the right time to Deliver the outcomes?
Design. This is where you are going to go into greater detail on how you are going to Deliver the outcomes of this race. No-one builds a house without designing it first, even if they change requirements further down the line. Similarly, there is always a sensible order to building a house. Start with the foundations and work your way to the top before adding the fixtures and fittings towards the end. This aligns nicely to having longer races early in the project and then much shorter races towards the end as the final touches that Deliver the best outcomes are agreed and delivered.
From a reporting perspective, you want to know and understand how they are going to Deliver the requirements and what you should expect to see at the end of the race.
Deliver. This then is the element of going away, doing what you have said you will do, and building or configuring what you have Decided and Designed in the first race. It is important not to dive into the Deliver phase of projects and it is something I see all too often. Going back to Proper Planning and Preparation Prevents P*ss Poor Performance, you need to ensure that you have an agreed plan that you can follow, even if it is just for the first race.
From a reporting perspective at the end of the race the report will be updated with what was delivered against what was agreed to be delivered. You will easily be able to see how on track you are or whether there has been any slippage. If there are issues arising with resourcing or similar, then this should be clear to you at this point. You can then take any necessary action.
Once your first race is finished, we return to Discuss.
In normal Agile terms, this would become a show and tell, where you are showing key users what has been built. However, the phrase ‘show and tell’ is one way. It must include a feedback loop and that is why it is not a show and tell as such, but another conversation. You could add another D here and go with Display and Discuss as that is nearer the exercise that you are going to be doing.
Once complete, you continue the Discuss phase into the next race period of the 5 Ds. It’s a very cyclical method that ensures that you can bring users in at the right time, ensure communication is clear, see benefits as early as possible and gain an understanding of the people-change element of the project.
3. Deliver the race reports
What you will end up with is a series of reports that relate to each race within a project. To keep the language familiar to athletics we will call the project a meet. So, we have a meet (project) with a defined number of races taking part within it and each race is broken down into laps (weeks). You will have a high-level meet report that covers the overall length of the project and the overall outcomes broken down into smaller race reports. At the end of the meet you will have some comprehensive project information to use. Each report produced should be shared with your organisation. So, a 16-week meet could be made up of four races and each race is four laps. You would have five reports – one for the meet and one for each race. Alternatively, a 16-week meet could be made up of eight races and each race is two laps. Here you would have nine reports. The choice and flexibility is yours to manage.
Once the system is ready and you have built or configured what delivers the outcomes, then you are ready to deploy. Even at this stage, if the business case still stacks up to continue working on the build, then you loop around the Ds again and again until you have maximised the value of your delivery. You do not have to deploy software and then stop. The benefits of digital is the flexibility to constantly be looking at improvements and, as you grow to become more efficient, you will need to take advantage of this flexibility. Alternatively, you may not need to add functionality, but you may want to improve what you have already built. You might want to refine the system and make it even more efficient. You may want to stabilise the system and make it more robust. The projects do not always need to be about new functionality.
4. Deliver the benefits
We should also consider development costs of projects here. I have stated that you can continue to iterate and improve processes almost on an open-ended scale, if you so desire. This really must be looked at in relation to the benefits that it will Deliver. An important step to consider, particularly if it is a development project, is to know roughly how much you plan to spend on building your software. If you have a team of five developers and project managers and each costs you £40,000 per year, then with on costs of 25% that team will cost you £250,000 a year, or just under £5,000 a week (or lap in our terminology).
Knowing from the outset that you are going to spend £80,000 on build costs gives you 16 weeks to Deliver a system. The overall meet time is then the 16 weeks, which you will break down into races. The £80,000 number can be figured from the benefits that you will realise from the development. It might be about more sales, business growth, increased customer service levels or higher customer retention rates.
After 16 weeks you can keep going, but if every week of additional delivery costs you £5,000 in salaries and costs, then you need to be seeing the additional returns against this figure. One of the key terms that we need to be looking at as you get towards the end of a project is Evaluate. This ensures that you have delivered the outcomes for the costs and timelines and looks at whether further benefits could be delivered. Always take the time to evaluate your projects against the outcomes and desired outcomes. It is the only way you can measure success and know what the next steps should be. You will have your set of reports for the meet so evaluating against these is quite straightforward. Projects cannot be open ended, hence why you need to initially place a limit on this. You may Decide to extend the project to meet further benefits. The build might take longer than expected. You should have a figure as a starting point to work towards. Just be flexible where it makes sense to be flexible.
Share this to social media