Well that’s all well and good and sounds about right - but what does it actually mean?
Let's go on a project management journey shall we?
Project Management in itself is a very valuable skill. It is easy to get a project 90% done and get it signed off as “Good Enough”. But what about the extra 10%, how do we actually set about achieving the extra mile and finishing off knowing with absolute certainty we ticked every box and exceeded all expectations.
Well that’s where project management tools & systems come into play. They help us to track progress, know exactly where we are in a project at any given time, what the budget looks like, are we on target to hit deadlines etc etc etc
A short time ago the generally accepted model used was called the waterfall where the project was broken down into a series of steps and flowed downhill until the project was completed at the bottom.
For many years this method was used extensively and was very effective until it as applied to Software Development. As technology improved and speeded things up - it was no longer appropriate to wait until the perfect product had been developed before launching.
This approach took too long and the whole project could be held up because of 1 niggle upstream that was preventing the waterfall from flowing through to the next phase.
A great example of this is the difference between Nasa & SpaceX. Before a project can begin being built at Nasa, the scientists must work everything out on paper first - they calculate every possible equation and must account for every scenario before that design can leave the lab and go into development - This is the Waterfall Approach.
SpaceX use an Agile approach which is the new Mindset used in Software Development. Agile does not try to create the perfect product right from the start. With Agile you look to create an MVP or Minimum Viable Product that you can learn from and improve as you go along. It accepts the fact that Failure is part of success and embraces knowing that more will be learned from getting it wrong than getting it right.
So they say at SpaceX “ Hey, we’re going to launch this rocket! It Might blow up, but we’re ready to learn” - That is an Agile mindset.
That’s a hard question to answer, both have their place so it really does depend on what it is you’re looking to achieve. For the purposes of this article though, I’m going to assume that you’re thinking about software development so I have to say, in my experience the Agile approach is better suited to this industry.
The story of the sheet metal company that taught me the lesson.
I will share the case study for this later on but needless to say the reason I adopted an Agile approach in my business was thanks to a client, that first time round we got the development very wrong…
I approached a sheet metal business and was talking to them about their frustrations they had experienced while looking for a workflow management system and CRM for the business.
This business was not digitalised and ran everything from a whiteboard and pieces of paper. The problem they were having was that too much information was kept in the employees heads and often, the person who had spoken to the client was the only one that properly understood the job.
You can imagine how frustrating this was when that person was not on hand to be able to answer a question at any given time. The whole job would be held up while waiting for information from “upstream”
And this is a typical problem with the waterfall approach. So our challenge was how can we get the information out of their heads and attached effectively to the job sheet.
We decided that we would build a system to track an enquiry from inception through to invoice. We mapped out the journey and took into consideration all of the steps along the way, including scoping the job, creating the form, adding it to the queue, tracking the time, recording the time, linking the staff member to the job, marking the job as complete, sending the invoice, tracking the payment marking the job complete when the payment was made, archiving the job and reporting on the job
And this is where we discovered the value of an Agile mindset.
We naively assumed that this was the MVP because all of these things had to be viable and in place before it could benefit the business so we set about building the perfect product
Needless to say this was the wrong approach.
As we were building out the product the tasks changed as we saw how it was coming together so before we moved on to the next phase we added the modifications. This was disastrous. It led to an unstable system, lack of confidence from the client and not much forward movement.
We identified the key tasks and put them into a priority.
Clearly entering an enquiry into the system was key so we built that and tested it.. We asked ourselves what we needed for an enquiry. We obviously had to have customers who would place the enquiry, Staff who we could assign the job to and materials that would be needed for the job.
So we built all the components we needed and made the enquiry form. This was our first MVP. we built it , and tested it to make sure we could get the information into system quickly and effectively, and had the right information in the right order .
Once we had our MVP and now we can enter enquiries into the system we could look at the next phase. In Agile this is called a sprint. So in a sprint we design, develop deploy review all based off our initial plan and we keep doing these sprints until the product is ready to launch.
There is a comprehensive case study of this job available to read here -the purpose of this article was to give you a basic understanding of the difference between Waterfall & Agile. Hopefully we’ve done just that - lets re-cap
We’ve looked at the journey of project management and 2 different approaches. The first was the Waterfall approach, used extensively in the past by including NASA who insisted that their scientists figured out every possible detail before releasing a design from the lab.
Next we looked at the Agile approach and explored the differences using SpaceX who rather than perfecting things on paper first prefer to learn in a more practical way by blowing things up.
Neither approach is right or wrong however, in terms of software development we looked at a case study from my own business and a lesson I learned in my early days as to why the Agile approach is more suitable for software development.
I’ll let you draw your own conclusions as to which approach will work best for you.