Agile working - a good alternative to traditional Project Management close

Each Digital Agency has different management techniques and processes, but due to an increase in Product Development projects at Codegent, we've been adopting the development management style called ‘Agile’.

To give you some background, Agile development was first coined in February 2001 when seventeen software developers created the Manifesto for Agile Software Development. This manifesto outlined the main principles around agile development which were based on iterative and incremental development.

Since we have started to follow this guideline, we have found it really enjoyable and have found the style to have many benefits including:

• Speed to market - design and technology can be done at the same time therefore reducing the amount of time needed on a project

• Visibility - with iterations on the work happening regularly, work can be published earlier to a staging environment, allowing the product owner to view work in progress and feedback earlier

• Regular releases - functionalities are pushed more often meaning that any functionality changes are smoother and quicker to implement

• Risk Management - these regular releases allow any issues to be flagged as early in the project as possible while there’s still time to make a material difference to the outcome

• Flexibility - the product and technology can evolve over time and to best suit the target audience

Below we've given an outline to the three main principles of Agile methology and the different elements that make them up.

1. The Kick off meeting

Before any work is started on the project a kick off meeting should be held with the product owner, project manager and the development team who will work on the project.

During this meeting the following points should be covered:

Product backlog

A product backlog is a list of functionalities, tasks and updates that the client owner or product owner would like to complete during the product’s lifespan. It’s important to make it clear during this meeting that the backlog is for the entire product lifespan so tasks within this list may be completed within the first few weeks of the project, or months later down the line. The backlog can be treated a little like a dream shopping list that you can keep referring back to during the product evolution.

Tip: Add this product backlog to a shared file so that it can be referred to easily in the future.

Roles

Roles prove very important when working on an Agile project and so the following roles need to be delegated during the kick off meeting:

• Product owner: This is the main owner of the product or the client. Their main responsibilities include managing the product backlog, testing work and selling the product to the correct audience.

• Scrum Master: The Scrum Master will run the regular scrums with the development team (explained more later on). The Scrum Master’s main responsibility is to keep everyone in the team on track to meet the agreed sprint objectives.

• Scrum development team: This team is made up of all of the people that will be building the product. During this meeting it is good to identify each person’s skillsets so that the best person is working on the most appropriate task. This also helps separate the tasks when you are in the middle of a sprint.

Goals

In the kick off meeting the product owner should detail what the product vision is to the wider team. Goals for the end product should be outlined so that everyone involved in the project understands the end vision and what they are working towards.

Ideas

The great benefit of using agile development is that as the product evolves and adapts over time, ideas are welcomed and discussed to help improve the product.

Tip: Add all ideas discussed to a shared document so that everyone working on the project can contribute and share their thoughts. You probably won't focus on any of these in the first few sprints but you may want to come back to them further down the line. Jotting ideas and thoughts down in a document helps to park the ideas so that you can keep focus on the work at hand.

2. Sprints

After you have had the initial backlog meeting, the rest of the project is broken up into what are called ‘sprints’. These are the individual phases of a project that help to move the build forward. Each sprint can last between 2 and 4 weeks, so it is important to make a decision in the kick off meeting for how long your sprints will last.

Sprints are created by taking tasks out of the product backlog and consolidating them into a set amount of time (called the sprint).

Sprint zero

This is your first sprint and will be all about planning and organising how the build and future sprints will work.

Basic set up

Every team has their own way of working but is often recommended to complete some of the basic setup tasks during sprint zero. This includes things like getting timesheets and development environments organised in advance, to make sure the team can hit the ground running on day one of the sprint.

Goal for sprints:

A clear goal for what needs to be achieved or completed by the end of the first sprint should be discussed and agreed upon by the whole team.The overall vision for the project, along with the product backlog, has already been defined during the kick off meeting so this should be referred back to when agreeing upon the first sprint objective.

The easiest way for everyone involved to understand this goal is by writing it out as a narrative. This can just be a simple sentence that explains the sprint goal from the user perspective. For example, if the goal of the sprint is to set up the payment section of a website the narrative would be:

“As a user I would like to be able to purchase package X on the website successfully’

Remember, focus on only one sprint at a time. You only need to create the goal for the first sprint for the moment as you will make a goal for the next sprint at the end, in your round up meeting.

Tasks

Now that you have identified the goal for the sprint you should list out the tasks that need to be completed to achieve this goal. These tasks can be technical or non technical but it is best to write all of them down, no matter how small they are so that you ensure you tick everything off.

Tip: Write these tasks on post-it notes, this will help when adding and moving them around your task board.

Task board

This is where your tasks on post-it notes come in handy :) The task board is used to monitor the progress of each task during a sprint. It is a great tool to help everyone visualise what needs to be completed - pretty much like a big to do list.

During sprint zero you should set up your Task Board. Depending on the sprint and the project, this board may look different each time, however I try and keep the columns the same for all of our agile projects to keep things consistent.

All tasks are to be placed under the ‘Backlog’ column during sprint zero, then each task (post it note) will move from one column to the next during the sprint throughout the following columns:

• Sprint backlog (all tasks that need to be completed in the sprint to achieve the sprint goal)

• In progress

• Pushed live (this doesn't mean pushed live to a site just pushed to the internal testing environment for everyone involved in the sprint to view.)

• Tested: Once a task lands in the ‘Tested’ column the team, including the product owner, are to review the task and sign it off. If the task has been completed successfully the task can be moved to the edge of the task board. If more work is needed on this task this should be discussed and the task moved back into the ‘In Progress’ or ‘Backlog’ column to be worked on more.

Tip: Put the task board up on the wall somewhere everyone can see it for quick reference.

3. Sprint Cycle

So once you've completed sprint zero and you're ready to get stuck into your first official sprint, how does the cycle of each individual one work?

Scrums

Sometimes called ‘Stand ups’, scrums are short catch up meetings with all the team working on the sprint, that occur each day and last around 10-15 minutes. We do our scrums here at Codegent standing up in our sofa area of the office around the task board. The key is to get everyone away from their desks where they get distracted and get them focused on the tasks for the day.

All teams run their scrums differently but to keep ours as short and sweet as possible we go round the circle of team members getting them to answer the simple questions:

“What did you do yesterday?” “What are you doing today?”

Individuals are not to go into detail on every single thing they did during the day but give more of a brief outline. Whilst people are outlining what they did and what has been completed, the scrum master will work along the task board and identify if any of the tasks can be moved along the columns of progression.

Sometimes during these scrum sessions new ideas are created but it is crucial that you don’t all start discussing these as it will draw focus from the sprint at hand. Once an idea has been aired it should be added to the shared ideas document or product backlog.

Tip: Plan your scrums for the morning, it helps get everyone motivated and focused on what they need to work on for the day.

Weekly backlog meeting

As well as having scrums every day with the sprint team we also have what we call backlog meetings at the very end of the week, normally around 5:30pm on a Friday before people are getting ready for the weekend. These internal weekly round up meetings are an opportunity for all the team to sit down and discuss what has been accomplished this week, if there are any concerns and what the goals for the following week should be.

Tip: Reiterate the goal and narrative for the overall sprint in this meeting and set individual goals for the following week to help keep people motivated.

Post sprint meeting

After the allocated time has been completed on the sprint and the sprint has ended it is always good to have a post sprint meeting. In this meeting you should cover:

• What was achieved during the sprint
• Any problems or concerns you had about the sprint
• How you can make the next sprint better
• Any tasks which did not get completed in this sprint and need to be carried over into the next one

Once these have been discussed and finalised you can start the cycle again and start planning what should be taken from the product backlog to be worked on in the next sprint and what the sprints goal are.

It may sound like a lot of work but once you are setup to work Agile, you’ll never look back. They key of course, is having the discipline to stick to the tasks in each sprint and not get distracted by the shiny, exciting new features in the backlog which is usually the case in product development. If you can do it, you'll undoubtedly reap the rewards of a high quality product that has a better market fit and needs less iterations later on in the development process.