How we work

General approach

We know that the most useful features of an application are the ones you think
of when you start using it. We take advantage of this by delivering release-
quality software early and often. We plan ahead to meet business commitments,
but we don't bog down in detail that may turn out to be unnecessary. Our
number one deliverable is always working software, and we do that on regular,
unmissable, two-week schedule.

We want you to be constantly involved, and we'll always be honest with you
about how things are going. We'll demonstrate new features to you as we finish
them. We'll use our wealth of experience to suggest new and better ways of
doing things, while always leaving you in control.

We have the discipline to maintain a structured, effective Agile process that
maximises flexibility and quality while still allowing you to plan ahead.
We're always improving our process, and we'd love to work with you to develop
a world-class project.

User Stories Workshop

We know you're full of ideas and excitement. So are we. So are the graphic
designers, the interaction design experts, the marketing group and the test
team.

Let's get them all into one room and talk about what we're building.

This is the User Stories Workshop. In advance, we'll have worked with you to
determine the types of people who will use your new site. Each 'User Role'
will have a representative at the workshop - someone from within that team in
your company, or an analyst for external roles. Usually the entire development
team is present, along with a Scrum Master acting as a facilitator.

At the workshop we'll brainstorm everything the new site should do. We'll
write these down in the form of User Stories, often taking the form "as a …, I
want to …, so that…". For example, "As an administrator, I want to download
page views as a CSV file, so that I can graph it in Excel". These describe
what we're building, why we're building it (perhaps we can find a better
way?), and who we're building it for (so we know who to talk to). The stories
are not a specification; they're just a placeholder for a conversation we'll
have later.

Estimation

By this point, we'll have dozens of features we'd love to build eventually,
but it's time to decide where we're going to start. After the workshop, the
development team will write an estimate on each of the story cards, using
'Planning Poker'.

This can take several hours, but it means that everybody is clear on what
we’re doing and – more importantly – how we’re doing it. We break into pairs
for design decisions, or involve the whole team for particularly tricky ones.
Because we’ve listed every task that needs to be completed, the team can
accurately track their progress.

By now, we hope that you've selected a Product Owner - a single person who is
knowledgeable about the product we're building together, and empowered to make
any decisions about it. The Product Owner's responsiveness is critical to the
team's performance, and ideally we'll sit with them for at least some of each
work day.

Release Planning

We understand that, even in the volatile world of software development, and
even with significant uncertainties about exactly what we're building, you
need at least a rough idea of when you'll be able to launch. At the Release
Planning meeting, we'll present the estimates and invite you to place the
story cards in order and draw a line where you'd like your first public
release.

We'll revisit the Release Plan throughout the project as your priorities
change or the work proceeds slower or faster than estimated. We use risk
multipliers to allow you to make a firm release commitment.

Iteration Planning

While agile development lets us stay responsive to changing business goals,
changing too much disrupts programming effort. We work in two-week
'iterations', which are long enough to be efficient but short enough that we
can fully specify the work to be done in each one. We have a prioritised list
of user stories, from the release plan, so we work down the list, making sure
the whole team understands exactly what needs to be done. This is the first
point where we explore all the corners of the story, right down to technical
tasks like "resize user's uploaded photo". We estimate the time needed for the
tasks down to the nearest hour.

This can take several hours, but it means that everybody is clear on what
we're doing and - more importantly - how we're doing it. We break into pairs
for design decisions, or involve the whole team for particularly tricky ones.
Because we've listed every task that needs to be completed, the team can
commit to delivering the work by the end of the two-week period.

To determine how much work to plan, we use the team’s velocity – a measure of
how many story points we’re delivering per iteration. This is different for
each project. Re-used code or occasional flashes of brilliance speed the team
up; delays in communicating with stakeholders, technical problems or difficult
constraints can slow us down. We use a moving average, but in the simplest
terms, the answer to “How much can we do this week?” is “How much did we do
last week?”

We normally maintain both the Release Plan and the Iteration Plans on large
wall displays in our office; we find it's by far the most effective way to
keep the information in front of everyone and always up-to-date. When
collaborating with offsite teams on large projects, however, we're happy to
use Google Docs, Mingle, or your company's existing project management system.

Iteration

With a fortnight's work planned in detail, it's time to write some code. Our
technical practices include:

• A daily ten-minute 'stand up' meeting at 10am sharp. The product owner is welcome to attend.
• The 'burn down' chart on the wall, showing our progress, any hold ups, and how much 'slack' remains in the iteration.
• Paired or 'mobbed' whiteboard design. Every team member knows how each piece of the site works, and how it all fits together.
• Pair programming with rotating pairs. Two sets of eyes on the code improves quality without sacrificing quality. We peer-review all non-trivial code that wasn't paired.
• A 'wall of wireframes'; we print the designs for the entire site, post them on the wall, then annotate them with post-it notes.
• Extensive automated testing, with continuous integration. For particularly complex business logic, we use test-driven development.
• Open coding. We use open-source code libraries where appropriate; we choose only maintained, high-quality code which is a good match for our project. We contribute code back to the community where permitted by licensing agreements.
• "Done-done" testing. There can be quite a large gap between a programmer saying "it's done" and a real-life user using the feature in production. We close the gap by testing each completed feature with the Product Owner as we go; it's not done until the Product Owner says it is. This tight feedback loop avoids the time-consuming change requests and email chains found in other projects.
• Continuous refactoring. If we do find any bugs, we don't stash them on a forgotten bugtracker somewhere; we kill them immediately. Allowing code quality to deteriorate is a false economy, so we don't.

Demo

It’s important that we meet our goals, and it’s important that there are no
surprises for anyone at the end of the project. Every time we finish an
iteration we gather the team, the Product Owner, and any interested
stakeholders for a brief demonstration of the finished work. We’ll work
through the stories one at a time, demonstrating the acceptance criteria that
we agreed on at the start of the iteration, and providing an opportunity for
feedback from stakeholders who weren’t involved in the day-to-day development.
Any changes or new ideas feed into the product backlog, or the next iteration.

Retrospective

While the Scrum process serves us well, we are constantly tweaking it to the
challenges of each project. After the demo, we hold a retrospective: a
structured process designed to output several definitive, testable changes to
our process. While the retrospective is often quite technical, we invite the
Product Owner to join us; often the improvements are in communication and
planning, rather than code.

After the retrospective, we plan the next iteration. We usually use iterations
of constant length, starting on the same day of the week, giving the project a
steady heartbeat.

Release Sprint

After a few iterations, it's time to prepare the site for launch. We'll plan a
'release sprint' for performance tuning, user-acceptance testing, final
content from the copywriters, and any last-minute tweaks. This is about last-
minute changes rather than bug fixes, though; through done-done testing and
crisp iterations we avoid having a large and inestimable amount of 'fix up'
work at the end of the project.

Launch

We'll have asked you to make a decision about hosting early on, so that
everything's set up well before the deadline. We'll work with your preferred
web host, or recommend one of our own. We've deployed sites to EngineYard,
Brightbox, Slicehost, and high-availability clusters at Claranet. We work with
change-control processes for two of our larger clients, and we're happy to
meet your requirements for documentation. If the worst happens, our deployment
system allows for rapid rollbacks, including rolling back data migrations.