Agile day to day

Rob Borley
by
on 07 February 2013

So far I have talked a little about why we have decided to use agile at Dootrix and what the big picture looks like. Now I want to take some time to talk about the specifics of how it works day-to-day.

Our use of agile is anchored around the principle of delivering working software every two weeks. This means that every two weeks the project owner has something that can be user tested and then provide feedback. This point about testing is the key to understanding why we do things the way that we do.

Testing is never cut

Testing is at the heart of our process. We deliver software; be it a website, a mobile app, desktop software or complex embedded system, that just works. This means that our code has to be vigorously tested and robust. And this also means that the experience of the user is tested and proven to be good.

All of our code is written using Test Driven Development (TDD). Our team analyse the requirements and write the software tests before they write any new code. Only once the tests are written is the code developed. Rather than coding to a requirement each developer writes code to pass these tests. Testing is foundational.

Alongside TDD we run agile user testing. The user stories are considered by the test team. Our developers are then informed as to any user centric code tests that need to be developed to supplement the original tests that came out of the TDD process.

This ‘test first’ approach ensures that we can continue to release working versions of the software every two weeks without being derailed by elongated test phases and endless lists of bugs. When scope creeps and time-lines are squeezed testing is never, ever cut. As a result we deliver software of exceptional quality. It works!

Sprint planning meeting

Each sprint starts with a planning meeting. The principle behind these meetings is that the team, as a whole, owns the project. It’s the team, not a project manager that make decisions:

  1. How a problem is solved.
  2. What the estimated amount of time to complete each problem (user story) is.
  3. What user stories are included in each sprint.

Together the team commit to what will be delivered during each sprint. They sign up to it. They own it.

This is achieve by a process of discussion with the project owner so that all understand exactly what each user story entails and then each team member, individually, assigns an estimate to it. These estimates are put together and a consensus is arrived at.

The next article in this series will look at this in more detail including the fun to be had with planning poker. *smile*

Daily stand-ups

This is the time to have a quick discussion about what happened yesterday and what we aim to do today. The plan is to take 10 mins at the start of each day to get any questions and problems out of the way which enables:

  1. The team to avoid protracted, and often pointless meetings.
  2. Individuals to get down to the tasks in hand with all of the resources that they need at the start of each day.

At Dootrix we have found that we do not actually have a stand-up each day. Our teams are, generally speaking, constantly communicating. Maybe we are fortunate to have naturally cooperative individuals. It also helps that the team members are situated close together. Their desks are right next door! Whatever the exact cause it has become clear to us at the moment that we do not need a daily stand-up because there is often nothing new to cover. Instead these sessions tend to happen every two or three days.

Sprint demo and retrospective

At the end of each two week sprint the user stories that were completed are demoed. This serves a number of purposes in the whole process.

  1. Teams are aware that their stories will be publicly demoed to their peers. This helps to keep them focused, during the planning, on user focused development. The question is asked; “how will this be demoed?”
  2. Individuals are accountable to their peers. As a team they have signed up, together, to complete the work in a sprint. It is obvious at demo time if somebody hasn’t been pulling their weight.
  3. All members of the company are invited to demos. This aids transparency and knowledge sharing.
  4. The sprint demo is generally a fun and social occasion. It is a clear end to each sprint and we have found that it offers some much appreciated down time.

Following the demos is a sprint retrospective. This is the session where the sprint team have a chance to reflect on what happened over the last two weeks and how the process can be adapted, adjusted, and improved going forward.

More detail on the retrospectives will come in a couple of weeks.

Rinse and repeat

This basic pattern of planning, collaborating and reviewing is repeated every two weeks. Sprint by sprint a release is completed. Throughout the whole cycle the process is tweaked so as to adapt to the needs of the team to enable them to produce an ever improving end result.

If you want to discuss how an agile team from Dootrix can help your organisation then please get in touch.

Subscribe

Subscribe to our newsletter for free advice delivered to your inbox on a fortnightly basis.

Related articles

dootrix code review

Behaviour Driven Development. A better Agile?

Or just a natural next step in the right direction? [NB: this article by our Technical Director Kevin Smith, assumes that you are familiar with Agile software development methodologies] Over […]

dootrix code review

Should code reviews be code conversations?

By Craig Rowe — Dootrix Technical lead. Having written on my blog about knowledge sharing I almost immediately wanted to get some thoughts down about code reviews. In the back of my […]

DeathStar

Boiling Frogs can’t build Death Stars.

The technological environment is now moving too quickly for us to take years building big solutions. If we try we’ll get blown up. Recently we came across an excellent think-piece […]

Minimum Viable Product (MVP)

Minimum Viable Product (MVP)

Speedboat IT

Delivering an IT strategy for the future

As CIO, your primary responsibility is to “keep the lights on”, to ensure that critical business systems remain running, no matter what. But your secondary responsibility is to use technology […]

Manchester Comedy Store

DPM:UK 2014 – Change Your Business, Change The World

Dootrix director Rob Borley has been invited to speak at DPM:UK being held at the Manchester Comedy Store during January. “In this talk Rob shares how agile projects at Dootrix […]

govuk

Dootrix promoted to UKGOV Digital Services Framework to provide agile software engineering services

Dootrix have been promoted to the UKGOV digital services framework for the supply of agile software engineering services. The digital services framework is designed to give the public sector access […]

NATS

Kathryn McColl, Strategic Research Engineer at NATS

Rob and his team guided us through our Agile development, enabling us to achieve a fantastic end product to challenging timescales. Dootrix are great partners to work with. Kathryn McColl, Strategic […]

Clouds

Agile at Dootrix

Following on from last weeks article about how our agile teams operate at Dootrix I thought that I would offer a little more detail on the reasons why we chose […]