Seeing as most members of our Agile Scrum team are based in India, and with Diwali coming up on 4th November, I wanted to facilitate a Retrospective that incorporated this significant religious festival.
Below is a simple board I put together for our team. It got an amazing response, arguably the best since the team was formed in April this year. For anyone else currently doing similar with their teams I hope it proves to be a useful kick-start.
When you complete each stage of a project in isolation. You can’t move onto the next stage until the previous one has been completed.
Teams may have frequent meetings in the form of monthly boards, where decisions are made by stakeholders, or dial in meetings with team members who may not work in the same office location (e.g. a Tester who works offshore).
A project example would be upgrades to multiple interlinked computer servers. Server one must first be upgraded first before server two can be looked at.
Methodical and the traditional method of running projects.
Works well for projects where there’s one end goal and nothing in between.
Enables clear investment decision points and reviews at stage ends and also ensures everything is completed before progressing to the next stage.
(Pro or con!) results in stricter levels of governance as projects need to fulfil specific criteria before being allowed to develop and implement.
Slow. A hold up at one stage affects the rest of the chain for the project.
This also includes potential impacts on dependant projects who rely on other projects for meeting their deadlines.
This in turn can lead to resource inefficiencies, project overspend and failure to meet to time scales.
Instead of aiming to complete whole stages in isolation, Agile projects take a more cyclonic approach, tackling a project delivery in multiple smaller stages (or sprints). Sprints tend to last between two and four weeks.
Teams keep each other informed via stand up Kanban/scrum meetings. An appointed scrum master leads discussions to enable the different teams working on the project provide updates. A) with what they are going to tackle during each sprint (at the start), B) progress updates (during) and C) what they have achieved (at the end). Meetings tend to be more informal and visual compared to Waterfall and the use of whiteboards with post its and/or dedicated software are adopted more frequently to enable updates in a quicker paced project.
An example of an Agile project would be the development of a App. Over the course of multiple sprints teams are able to gradually build and test the App, first with the basic code, then the functionality, then finally adding in user appeal – pictures, sounds etc.
Fast moving. Enables teams to quickly identify any faults and either fix or ‘drop’ them before too much money and time is invested.
Deliveries grow over time, a project leader can start to see formation much earlier into a project, where in Waterfall the change is sudden.
Considered to be a more resource efficient model and allows for greater collaboration.
Agile is not a suitable method for all projects. A single delivery can’t be built over time (for example, the delivery outcome ‘running a marathon’ cannot be done in separate sprints. You sign up, train, then run it. An Agile approach would be useless in this instance – you cannot gradually run bits of the marathon over twelve weeks!)
The working environment must contain all persons on the project (project lead, governance, software architects, testers, accountants, etc.) to enable collaboration. These resources can only be dedicated to one project or sprint. If resources are split between multiple projects (as they can be on Waterfall) then the sprint may fail to meet its delivery.
As sprints are quite short and projects adopting Agile are quicker paced, the project lead must ensure that suitable investment and project governance/review points are put in place as the cycle system doesn’t naturally allow for any sudden or prolonged stops.
As it’s a new methodology of project working, team members may require additional support and/or training.
And there you have it. A (very) quick overview of the two main methods of running projects. I want to add here that I am by no means an expert on either approach, having only started a career in business project management and governance three months ago(!) but hopefully for that reason it will help any new starters in the world get to grips with the basics.
(Also, I hope that doing this will stop Mumma Bennett getting into hysterics when I talk about my job- ‘Waterfall? Ha, ha, haah! What’s Waterfall?! I don’t understand, what’s water got to do with technology upgrades? You’re so corporate!’ and so on and so forth…)
And who says you don’t learn awesome things from this blog?