Four things (of many) we learnt from Liz Keogh
We’ve had the great pleasure of having Liz Keogh doing some agile coaching with us for the last two days.
I invited Liz after meeting her at the BDD workshop I ran last week. We were very lucky that she was free and available at short notice. I felt we had a pretty good agile system set up here, but we’d not scaled it to a larger team (6+) before and we were coming up against issues (such as the best ways of estimating) which we felt Liz could help us with.
It’s been enormously beneficial to have Liz with us. Much of our practice were validated: pair programming, co-location, BDD, outside-in, continuous integration. These are core tenets of our process which have been proven in many companies. Instead of changing our basic practice, Liz has helped us to the next level through much conversation and discussion.
Here’s a few snippets of what we’ve learned and how we’re tweaking our process to give our clients the maximum number of features with the shortest possible lead time.
Use Feature Injection to force the value question
One small change with big ramifications is the concept of Feature Injection.
In brief, this means changing the way you write stories so that instead of having:
As a
I want
so that
You have:
In order to
will need
.
Rather than just a way of specifying technical stories, we realised that by putting stakeholder value first, we are forcing the question of what’s actually necessary about this feature that causes us to do it in the first place. This ties our stories very much to stakeholder value, which ensures that everyone knows exactly what value is being provided when they’re working on a story.
Read more about Feature Injection here.
Keep completed stories visible
Once our stories are clearly about stakeholder value, it’s important for everyone to see exactly which features currently exist, preferably broken down by stakeholder. We’re working on ways of getting the features list that we’ve already completed more visible to our clients. Once everyone can see what’s been delivered so far, it’s much clearer what should be worked on next.
One way of doing this might be a small Rack app which handles /admin/features and returns all the features grouped by tag… does anyone know of a Rails plugin that might do something similar?
Ensure you can always release
If we’re truly doing BDD, then we are delivering tiny slices of functionality that can be released immediately. Often we batch these into releases, often accompanied by a rather laborious and crunch-like polish process.
However, there’s no reason that we shouldn’t be ensuring that the site is release ready at any point. If this is the case, the stakeholders have the option to say “Done – ship it!” whenever they like, and we’re able to do this straight away, rather than after a three week polish + skin period, and the dreaded IE6 compatibility check.
Lesson learned: Get a site release-able as fast as possible, and keep it there.
Put performance tests in the build
As developers we are always concerned about timing our performance improvements. How do we balance over-optimising a site with doing performance testing too late and risking a meltdown? How do we ensure that performance is kept at an acceptable level?
If the goal is to always keep a project release ready, then we need to ensure that our new system hasn’t introduced any serious performance issues, which bring it below a minimum performance level. If you are guaranteeing to your client that your site can handle a certain level of traffic, then anything that breaks that effectively breaks the build. Therefore, what better way to do this than make your performance tests part of your build?
And there’s more…
I plan to blog further about some of the other things we learned: including the major insight about the benefits of a Lean approach, which is worthy of its own post.
Do you have strong opinions about the above? Do you disagree? Let us know!