The first time I heard of agile project management was a couple of months ago when I watched a TED Talk by Bruce Feiler on ‚Agile Programming for your family‘. As Bruce Feiler stated that
Project: what is it?
So in terms of constraints any project is limited by this triple:
Some predefined scope or amount of tasks has to be carried out considering limited resources. And there is a deadline to meet.
Although I definitely studied different types of project management during my bachelor and master, somehow nothing stuck in my head except the waterfall method. Most probably it is because of employers I have worked for never applied anything but a waterfall. And so not used theoretical knowledge got forgotten.
Waterfall method in project management
But what is a waterfall method? It is basically working through a project step by step. As one phase finishes – the next one begins. And as the last phase is over, just at the deadline, the final result should be there.
Waterfall method is also called ‚classic‘ project management as it is very broadly used. And it has important advantages that made it so popular. So the waterfall method is very good for projects with following characteristics:
- well-defined standardized projects
- with fixed and clear requirements for the outcome
Waterfall at its best
As I have worked as an IT project manager I developed and commissioned interlogistic conveyor technologies. So those were huge conveyor systems that basically made sure that someones online order get collected into the box automatically and gets to the right truck for delivery. To establish such a system the waterfall method was used like this:
- Conception phase: develop and approve
- Design phase: design processes of a commissioning site
- Development phase: adapt the database, configure some bits, programming some other bits – basically, whatever it takes to make the system work
- Testing phase: test if and how those bits you’ve configured and programmed before are really working. In my case, it included travelling to the client’s site, starting the system and launching some boxes to run through it. Do they start at the starting point? Do they get ‚married‘ with an appropriate order? Do they get delivered to the right places and collect the right items? Do they get all the items needed? Do they get packed and show up at the right ramp?
- Go-live phase: here client for the first time sees if and how the system is working. Real orders get started, get collected and get delivered. Or not. Depending on how good previous phases were done.
As you see all the phases and all the work proves it (or not) in the last phase. It is a good method for standard projects with
Failing bombastic with waterfall PM method
The waterfall method is perfectly suitable for developing and delivering commissioning systems. However, it might not be the best choice for projects that are not standardized or have no clear understanding of the outcome. And waterfall was definitely not a good choice for developing urlubster.at. From my article ‚8 proven tips to f*ck up your start-up‚ you might know about my bombastic fail, however, I haven’t mentioned waterfall method there. So I will tell you here about it.
Start-ups are usually looking for new ways, they try innovative ideas as they need something special to be noticed on the market. To differentiate. So doing something new is nothing you can really back up with the know-how. You need to be adaptable. You need to be aware that there are better project management methods as
However, at the time we developed the website for
- Conception phase: we developed our 30-pages-long technical specification and picked up a company to do the programming
- Design phase: we created a data model (now I know it is called this way, previously, I simply called it a Database model) and we thought of all the possible scenarios and how this model will or won’t satisfy them.
- Development phase: then we basically heard nothing from our developers for months. They were developing. According to our 30-pages-long plan. As we thought.
- Testing phase: finally we saw the result. And it was like 5 pages out of 30. Resources we limited. So the other 25 pages got cut. And as our developers said, they were not even necessary. Oh. Right.
- Go-live phase: Once our website went live none of our expectations came true. Nobody seemed to find it useful. Damn. Is it because of the other 25 pages are missing?
The real failure here was the method we chose for the project. We should have taken agile. I am not saying that agile leads to a definite success. No. Any method ends up with successes and fails. But agile does fail quicker. And start-ups need to fail quicker. If we would have failed earlier, we would have still had resources to apply changes or do more user research. Whatever needed.
Scrum: Agile method for start-ups
The agile approach is good for projects where you are not quite sure about the outcome and where some kind of discovery or creativity is needed. This approach has an iterative and incremental nature, so it allows to fail quickly, change direction and adopt new ideas within the same project (same deadline, same budget, same outcome). ‚Agile‘ is an umbrella word for different agile methods like Extreme Programming (XP), Crystal, Feature Driven Development, DSDM Atern and Scrum. In this
The main reason I promote agile mothods for start-ups is the ability to fail quickly. While in waterfall method the final outcome is fixed and you can only move deadline or increase the budget – in agile project management it is vice versa. And it meets exactly the start-up spirit. Time and budget are fixed and the result can vary. The outcome is a result of a creative, innovative discovery process. So let us see how it works.
At Scrum there is no project manager. There is a Product Owner who is basically a communication interface between the team and a customer and is responsible for the result. There is also a Scrum Master, who is responsible for the process and moderates all the meetings and work process. All the team members are considered independant and competent to work on their own.
Scrum project starts with a Kick-Off where project constraints and goals are setup. There the duration of a sprint is also defined. It usually takes from 1 to 4 weeks.
The vision of the outcome called ‚Product Backlog‘ is taken as a foundation for each next Sprint. At the beginning of a Sprint, a Planning Meeting is held where the team decides which features from Product Backlog will be implemented in this Sprint. The features assigned to the Sprint are then called ‚Sprint Backlog‘.
Each Sprint results in a potentially shippable product. With each following Sprint (iteration) this product is being incrementally improved.
The success of Scrum is dependant on efficient communication within the team and between the team and the customer. To ensure it there are Daily Scrums – short team meetings every morning to catch up on such issues as:
- what was done since last meeting?
- which obstacles are we tackling with currently?
- what’s the plan till the next meeting?
At the end of each Sprint iteration, there are Review and Retrospective meetings held. Product Owner delivers results to the customer, discusses it and receives the feedback for the next iteration.
I am not telling Scrum is suitable for every project, but I am saying it is worth considering it especially for start-ups and projects with creative discovery nature.
Here is more detailed reading about Scrum I’d like to recommend: ‚Agile project management with Scrum‘. There are also some nice infographics about