I’m sure we have all heard buzzwords around project management and methodologies, waterfall, agile, scrum, sprints, this list goes on. But what do these actually mean and what is the best way to actually run a project.
Let’s start with some of the definitions.
Agile: This one is very controversial, the word agile means to be responsive, flexible and fast, however, some of the methodologies attached to Agile are the opposite, they are slow, thought out and inefficient.
Waterfall: An oldy but a goody! One task can not start until the previous is completed, is this the fastest way of completing a project? No, does it ensure that you are not starting 100 different tasks, becoming blocked and leaving them? Yes - it is a foolproof way of completing a project, but for an effective dev team, not the most efficient way
Kanban: Put very simply, move a ticket from left to right until it is 100% complete. This can be paired with lots of other methodologies to create an effective project
Sprints: Usually 2 weeks at a time, a sprint is the development team agreeing to a goal e.g. completing 10 tickets in a 2 week period, at the end of that 2 week period the board is released and anything that is not complete is pushed into the next sprint, and then additional tickets are added. Again, varying opinions on this as to how effective it is.
Scrum: No it is not to do with rugby, it’s not even a methodology, it is a framework of processes to get a project completed. Usually paired with sprints.
I’m sure as clients you have all heard these, and as agencies, we have all proposed these, but do they actually work?
Let’s use an age-old metaphor, one size does not fit all, this metaphor applies to project management and methodologies as well.
No client is the same, and therefore no project should be run the same, is there certain milestones and procedures that need to be adhered to to ensure success? 100% but a blanket statement of this is how a project is to be run is no longer the case.
I like to use a blended approach, so what does this mean? It means that we use a framework of milestones and releases to reach a goal and we lean on the strengths of both the client and the team to hit that goal.
Enough talk, let’s use an example.
I had a client recently that was not tech-savvy at all but they we’re business savvy and knew exactly what they wanted from a design POV, but from a coding and build POV, this process went over their head. They had a hard deadline and it was not movable.
So a traditional sprint methodology would not have worked here as the client is not brought into the process and they would not be engaged. They are interested in the progress, however, in this certain circumstance, a Kanban approach worked best.
Myself as the Product Owner would groom the backlog and get tickets to an acceptable state and then between the Scrum Master and myself would plan the next 2-week release based on the estimates given by the dev team. A weekly demo of progress was shown to the client to ensure they are seeing success and the development team we’re left to code and progress to hit their deadline, rather than being held up on constant meetings.
As you can see we have taken a sprint and modified it to suit the needs of the project, which resulted in an on time and on budget project. From estimations, if we went down a pure sprint methodology including all sprint ceremonies, the project would have been over time, over budget and most importantly the client would have been left dissatisfied.
However this is definitely not the case with all clients - some are more controlling than others, it is about the relationship you build with the client and not the methodology.
So how do you know what way to run a project? Trust your instincts, after all, there is no such thing as failure, there are only learnings.
My methodology? “Get shit done” after all, that’s all we really need to do.