Being Agile.
We’re old hands at agile, having adopted agile development methodology back in 2009. How we implement it is fairly unique to us.
If you’re reading this, then you’re probably already well versed in agile. However, our version of the five founding principles are most definitely worth repeating:
- Individuals and interactions over processes and tools
- Working deliverables and iterations over super-massive projects and comprehensive documentation
- Collaboration over rules, hierarchy and silos
- Responding to change over following a plan
- Learning over opinions, via experimentation and testing
Agile has brought us tremendous productivity gains, increased client satisfaction and removed much of the panicking and working late that usually accompanies running a client-centric business. In fact, it’s fair to say that it’s over a year since the last time we had a “massive panic” or were forced to work late/long hours. There is no firefighting at Connected; it’s simply not required.
Our approach, developed over three decades, just seems like second nature. Recently, at an agency retreat event, the simplicity and efficiency of our model came into sharp focus. This clarity and simplicity are a rare treat in the digital agency world, and we’ve worked very hard to get to this stage. And we’re more than happy to share how it works (we like all that transparency and open source stuff!).
If you’re new to agile, then you can kickstart quickly, or you can read our full Agile Manifesto here.
Some numbers
To better frame the explanation I’ll provide some outline numbers so you can better understand some of the gains. These are real numbers and costs.
We found the harsh reality is that a single person can produce about 25 good sprinting hours in a week (we have a decade of timesheets to show this as being true). So, 25 sprinting hours per week is the basis of how we estimate work and charge the client.
This is quite different to agencies that charge “full days” or “full weeks”. 25hrs at £150ph (our rate) is the same cost as 37.5hrs at £100ph!
So not all of our time is spent sprinting
It makes (almost) no sense to apply agile methodology to WordPress support tasks that might only take 30 mins to fix. It’s also true that, despite best intentions, it’s impossible to book 40 hours of chargeable sprinting into a single week.
So what’s the remaining time spent doing? Support, unsurprisingly.
We dedicate resource to deal proactively with (potential) problems before they become real. Time spent in firefighting mode is highly inefficient, wasteful and can turn a profitable project into a loss-making mess. Avoiding that firefight stage is key, and investment in client support is how we remove it.
We carry out a fair amount of client WordPress support (over 3,000 tickets in 2015 and expect to be closer to 4,000 next year). So the remaining time left over (10 to 15hrs per week) are allocated to support. With around 20 tickets per working day, we can be kept quite busy.
The two workflows require us to operate a two-tier resource management process. It might sound complicated, but it’s not, and works something like this:
Support trumps Sprinting trumps Other Stuff
And to do that we look at sprinting in a different way to many traditional Agile exponents. In a given day, support comes first (correctly) and once a dev has burned 2 hours on support tickets then up to 5hrs of sprinting is still available. Other stuff has to wait.
2 hrs WordPress Support, 5 hrs Development Sprinting and whatever is left to deal with normal day-to-day frippery. It, uniquely, allows us to use highly skilled folks to deal with support, but never for more than 10 hours per week per person. Using better-skilled folks in support also contributes to the reduction in fires and panics.
Pros and cons
The maximum time spent “in a sprint” is just 25hrs in a week, so this reduces client development billing by 33% while, often, producing a very similar amount of useful output – and in a less tight timeframe. We did find driving experienced folks to sprint 40hrs a week can cause burnout, conversely adding variation and reducing the time pressure kept folks fresh, better grounded and more efficient.
- Lower chargeable burn rates. A topline figure of £142 per hour actual converts to about £100 per hour across a “full” day. This is particularly useful for long projects
- More manageable sprint durations. We stop, evaluate and re-plan every 25hrs, theoretically allowing the project to be more flexible. Most development houses run 80hrs before a stop (2-week sprints in 40hr weeks). If you are running a 3-man team that 240hrs before “stop and look back” occurs versus 75hrs using our approach
- Less waste, greater efficiency and lower development cost. We found the last 15hrs of a 40hr week were extremely unproductive, perhaps only generating five good hours of output. We eliminate this waste.
- Staying ahead of the game. In our version, we already have 40% slack built it – with no slack any non-sprinting activity bites into limited time.
- Fits the Freelancer Model. We cannot and don’t expect our freelancer developers to commit 100% of their time in any given week, this works out particularly well, and gives us huge “scaling on demand” possibilities and the ability to deal with spikes in resource requirements.
We’re still refining the process and every year we find little ways to improve how we work. We can categorically say that our delivery efficiency is up massively. I understand this is an abstracted measurement and greatly influenced by many factors (the skill level of the team, person cost per hour, processes and collaboration). As a result, we aim to have the best skills, leanest processes and most open collaboration.
Supporting Notes:
In agile terms, we do 1-week sprints when many other agencies do 2-week sprints.
25 sprinting hours caps to ~£3.5k of bookable time per developer per week (our standard charge is £150ph). The total cost of a developer is Circa £75ph per sprint hour, yielding approximately 50% gross margin (which is broadly similar across the agency industry).
However, we pay very top-of-market money for resource and are also highly selective when it comes to clients, so our absolute yield per sprinted hour is quite high, at £75. At the other end of the spectrum, a smaller agency might only pay £40k pa for a developer, which could bring the real cost down to about £50 per delivery hour (possibly at the expense of quality and service level?) and might yield £50 per delivery hour. The increased quality, service-level and yield fit the service-based needs of our clients and our business model, it does not suit all.
Costs and chargeable rates are representative, not definitive. E&OE.
