Don’t talk about it…

Don’t talk about it…

I got some very sage advice at a conference recently about using the Agile method of delivering projects and that is …. Don’t talk about it (just do it).

However based on some of the gormless questions then asked, I thought I’d put my tuppence worth in writing for anyone one who wants to know how it works.

I’ve been using Agile for a good few years now and am a total advocate of it. There are many more evangelical supporters than me, so I won’t preach to you how you’re doing everything wrong if you’re not using it already. I will say it gets great results quickly and can give a traditional waterfall run organisation a kick up the proverbial ass. It can work for non I.T. projects too but I will talk about it in relation to web site development.

How it works

Agile project delivery is basically achieved by a number of time boxed intervals of work – typically a 2 week development cycle and a 2 week test cycle but it can be less or more depending on what your organisation’s needs are. These units of time are called sprints.

In case you were wondering this is how some organisations are able do weekly, daily or even hourly releases.

While there’s still a need for usual preparation work of scope, analysis, architecture, designs, art work etc. you no longer need Gantt charts and the like. (Note: These tasks can also be managed by sprints.)

Instead there’s a brainstorming session with the product owner, a scrum master and the project development team who come up with a shopping list of requirements called a product backlog. Burn down charts can be used to track progress should they be needed.

An initial product backlog can be very broad; every item will need a description, analysis and an estimate. A product backlog that starts out as short and vague will become longer and more concrete as time goes on. Items slated for implementation soon will be the first to be refined; clarified, better defined, split into smaller chunks.

After product backlog refinement, the product owner prioritizes what they want done first. The development team estimate the time required for each task. This helps the product owner prioritize what they want developed and in what order throughout the project development life cycle. The scrum master will highlight inter-dependencies etc. to the product owner, this is called sprint planning. At the end of sprint planning the team will be clear on what work will be completed and how it will be accomplished. They then work off a sprint backlog. The development team may also make task boards to work off for themselves.

While the developers are coding, the System Integration Testers start their preparation. When the developers are ready to deploy their code, the testers then execute their test cases on that code and voila there’s a deliverable called aproduct increment ready to be User Acceptance Tested by the business.

When a product increment is delivered it is as per the shared understanding ofdefinition of done as agreed initially by the whole team.

After each sprint there’s an informal sprint review and retrospective session with all team members where they review where they are, what worked well and what did not. Tweaks are then made to the process.

Then sprint planning starts again (or started in parallel to previous sprint) and the whole cycle repeats ad infinitum until the project is complete or until the project sponsor runs out of funds.

Who said anything about rugby?

The project is managed by daily stand up meetings called scrums that are run by ascrum master. The start of the day is best but anytime that suits the team is fine. The idea is to work through a visual snap shot of the project; this is achieved with ascrum board – which can be physical or digital. Physical is where all tasks have been written on yellow or coloured stickies during sprint backlog planning and digital is where it has been typed into a spreadsheet or an online project management tool such as Trello.

The scrum master does not have to be the project manager but can be, especially on smaller projects. A ‘neutral’ scrum master or a program manager works very well where there’s multiple project managers throughout the course of a project.

During scrum each team member gets 2 minutes to say what they have worked on in the last 24 hours, what they will work on in next 24 hours and what, if any, are their impediments. The scrum master must help them, or find help for them, to overcome their impediments. The scrum master will also facilitate other meetings as necessary.

The scrum board will usually be laid out in a grid, with four columns for the tasks in different states. All the sprint backlog tasks are listed in column one. In the second column are all the tasks currently being worked on. As each team member speaks they should move their task from one column to the next as they progress (i.e. column three is ‘Ready to test’ and column four is ‘Done’) and as tasks are complete choose the next relevant thing for themselves to work on from the sprint backlog. The product owner can provide guidance on what’s required next.

Studies, practice and experience show the yellow (mostly) stickie setup works really well and team members feel more engaged physically moving the stickies than using online versions. Someone (Project Manager or Scrum Master) also needs to maintain the online version for the auditors. Of course, an online version helps with reporting.

Someone at the conference I alluded to in my introduction asked what happens if the stickies lose their stickiness and fall down. One word: Sellotape.

I can testify at the end of the project there’s nothing more satisfying than seeing all the stickies over in the done pile! I also think, that apart from having a crack team of developers and a switched on Scrum Master, a tuned in Product Owner is key to the success of these kinds of projects.

Summary

The scrum team’s members (product owner, development team, scrum master) collaborate to create a series of product increments, during short time boxed intervals called sprints. Each increment meets the team’s shared definition of done. The team work from a product backlog which in turn is broken into a sprint backlog as they refine the product backlog over time and plan each sprint. They self organize to do the development and meet at a daily scrum to ensure that they deliver the best possible product increment. They end each sprint with a review and retrospective.

Further reading

If you’d like to read more, the Agile Manifesto came to life in 2001. Then Ken Schwaber with others later founded the Scrum Alliance and created the Certified Scrum Master programs and it’s derivatives. Scrums values are: Focus – Courage – Openness – Commitment – Respect.

Leave a comment