Going agile

It’s been a while since my last post and I feel like I should have written a few more times since then.

However, I’ve been pretty much flat out working with our team to prepare the finishing touches of BuyReply. We are going to be launching in two weeks and are putting the finishing touches on our product.

When we first started building BuyReply there were a few of us designing and developing and we weren’t all working from the same office.

I wrote a 95 page functional spec and designed around 450 screens for desktop and mobile then worked with my developers to turn this into a product. We spent three months planning before we wrote our first line of code.

While we were developing to a functional spec it was relatively easy to know what everyone had to do, however we are now in a situation where most of the spec has been developed.

We are working on tasks such as our deployment processes, continual integration configuration, testing processes and minor feature updates that will set the stage for our business moving forward.

It became clear in the last week that we needed a process that could be used to manage our team and ensure everyone is on task, productive and aware of what each team member is doing at any point in time.

The solution to this problem is to implement business processes that we adhere to with discipline on a daily basis.

After some research, we’ve decided to start using an Agile development approach. Agile works by breaking work into a Roadmap, Projects, Sprints and Tasks as well as meetings called scrums, planning sessions and sprint reviews.

Agile components

Roadmap

This represents our long-term plans and includes high level goals that would extend over a 6-12 month period. It includes major product features. An example of this might be ‘building analytics functionality’ or ‘enabling third party inventory integration’.

Projects

This represents short term goals that can be broken down into sprints. These are more clear requirements. Examples include:

• Launching version 1.0

• Building a web hooks module

• Exposing our orders and customers API

Sprints

Sprints are the building blocks of Agile and should be two to four weeks in length. Projects are broken down into two week sprints that include tasks. Once a sprint starts we do not make changes to the requirements. The scrum master polices this.

Tasks

Tasks are work units that can be broken down into 1-16 hour blocks that can be completed by a single person. Sprints are broken down into a series of smaller tasks.

An example:

If I have multiple cards in my wallet, I should be able to select the default card and if that card is not accepted by the merchant it should land me on a page where I can see a list of cards that the merchant accepts, and enter a new card.

• Add a radio button that enables a user to select a default credit card in their wallet [3 hrs – Adam]

• Create a page that displays the credit card form [3 hrs – Adam]

• Test and debug this function [1 hr – Adam]

• Acceptance test this function [1 hr – Dave]

• Document this function and update marketing site copy to include this [0.5 day – Dave]

• Update marketing site [2 hrs – Joanne]

Meetings

Scrums

Every morning we will get together at 9am in the meeting room for a scrum which lasts no more than 15 minutes. We do this standing up, as that forces us not to relax and get into conversations that waste time.

Scrums occur away from our computers and each individual has to report on three questions every single morning:

• What did you do yesterday?

• What are you working on today?

• Have any roadblocks arisen that have caused the sprint to slow down, and what are they?

It is the role of the scrum master to remove roadblocks. However, this must happen outside of the scrum itself to ensure the scrum lasts no longer than 15 minutes.

In this meeting attendees are not reporting to the scrum master or product owner, they are taking responsibility for the tasks and committing to completing them.

There are three core roles of the scrum:

• Product owner: This person represents the voice of the customer. They are responsible for representing the voice of the customer, defining user stories and what is going to be built. This person can also be a member of the development team. I am going to assume the position of scrum master as I have a clear vision of the direction of our product.

• Development team: Usually three to seven developers working together. This team should be self-organising and work together to get software built. The product owner (myself) can be a member of this team, which I am at this point in time.

• Scrum master: This is a person who protects the development team from distractions and fends off external influences that might cause them to lose focus.

Sprint planning

These are three to four hour sessions where a two-week sprint is planning and every task is broken down into a 1-16 hour block. Work is never assigned to a person – you sign up for work of your own choosing based on what needs to be done.

Sprint Review

This is a demo of the work done in the sprint. It is not a presentation. You need to show working software.

Documents

Product backlog

A backlog of functions and features that can be turned into a sprint. Think of this as a pile of sprints and we choose one, feed it to the team, get it done, then take the next one. We constantly pre-prioritize the product backlog.

Sprint backlog

This spreadsheet represents a list of new work that is still required, and the estimated hours required to complete this over a five-day period.

Burndown chart

This chart represents a number of hours required over time and shows you how fast they are burnt down. It represents the velocity of work.

I’m looking forward to implementing this process at BuyReply and expect that we will be more productive because of it. We are weighing up whether to use TFS, Asana, Greenhopper or Trello to manage this process. Any feedback would be welcomed!