Agile 'Tiger Teams'

Having a lot of fun producing incredible stuff!

Team members fist-bumping at a desk

The old school way of developing software was to define the requirement, estimate the cost, and then obtain funding based on cost justification. However, my experience is that often the entire funding is spent on defining the requirements. So they have a detailed requirement, but the entire budget’s been spent producing it, and now there’s no money to actually do it! Often these projects start with a big 'bang', with lots of communication, new specialists onboard, lots of talking ... but actual delivery of tangible assets (something working, not just an 'understanding' of the problem/solution!) takes far too long.

So there must be a better way? It turns out there is. We're not claiming it’s the ultimate way, but it’s the best we’ve seen so far. We often refer to it as “Agile with a small ‘a’ ” because it’s heavily based on Agile.

Here’s some of the principles:

  • Delivery. Everything we do is about delivering value to the business - quickly!
  • Iterative approach. Rather than disappearing for months/years, and then turning up with a new system, Agile is based on a number of iterations (called “sprints”) that deliver something of value to the business every time.
  • Minimum Viable Product. We produce a minimum viable product (MVP) that provides the business with value. Then we refine it and build on it.
  • Close working. We work with the business constantly. That way any mistakes / wrong directions are caught early and rectified quickly.
  • Welcome change. We welcome change - change means we’ve resolved a mistake early rather than late.
  • Tight Team. Our team works really closely together. The environment should be fun, because people having fun work harder, enjoy their work, and are more productive!
  • Constantly Evolving. We keep looking at our performance (“retrospectives”) and find ways to improve it.
  • Discussion over Documentation. We do have documentation, but we believe a discussion and deep understanding is more important than a complex document.

Initially this approach seems really weird. Agile teams are often seen as a bit ‘whacky’ because they work so differently. But believe us, it’s worth it when you see delivery in weeks rather than months/years.

A Feeling

Building a great team is difficult to define because a lot of it is about feelings (or it is just me, as a software nerd, that can’t describe feelings?!) Here’s some of the things you should feel when you’re in a great Agile team.

  • You should feel that everyone is pushing as hard for the same things as you are
  • You should look forward to your day. Working in a good coherent team should be a whole lot of fun
  • You definitely should not feel you are being ‘managed’ or ‘driven’. The team should feel that they are being facilitated to allow them to become as productive as possible (believe it or not, every developer wants to produce great stuff!)
  • You should feel the difference between when you’re sprinting and when you’re planning (you can't keep sprinting all the time!)
  • A Brave New World

By their very nature, many organisations are risk averse, and often have a strong resistance to change. And now every organisation is being cut back to the bare minimum of costs, and even generate income from areas that were previously purely a cost. So convincing an organisation to try a “new way” isn’t always easy! But the results are usually astounding! Added to that, the people in the business (the 'customers', or in Agile terms the 'product owner') often enjoy this new way of working, and love having something delivered every few weeks.

Agile Gecko

The 'Agile' in our name is for this reason. We've setup and worked in a number of these 'tiger teams' and have now refined a good way to get such a team off to a flying start. We have also done this in local authorities - which have a very distinct set of challenges to this way of working.