The Agile Tractor Engine Analogy

Since 2001 agilists have been focused on finding ways to improve how software is developed.  We’ve adopted fundamental strategies such as regular coordination meetings, regular demos, product owners, developer regression testing, retrospectives, and incremental releases of working software.  Disciplined teams have adopted more advanced strategies such as active stakeholder participation, continuous integration (CI), test-driven development, continuous documentation, continuous deployment, measured improvement, and incremental releases of consumable solutions (to name a few).  We experiment with new techniques to learn what works for us in the situation that we face, improving our approach as we do so in an incremental kaizen-style manner over time.  In effect we are finding ways to tune our “development engines” so that we can deliver more valuable functionality, to reduce our cycle time, and to be more productive as a team.  This is very similar to a Formula One team who over the years improves their racing car engine to deliver more power and more speed for less fuel consumption so as to help them win the race.

Race car engine

Our challenge is that a race engine alone doesn’t win the race, what we really need is a race car. We see too many agile teams, who on their own are doing a great job at improving the way that they work, get bogged down by the organizational environment in which they work.  This is particularly true in established enterprises that have been in operation for decades and sometimes even centuries.  Your development team tries to work in an agile manner but they’re forced to conform to your PMO’s existing traditional governance strategy that requires creation of inappropriate artifacts following a lifecycle that is far from agile; they’re forced to work with a bureaucratic data management team who often takes weeks or months to do work that should be accomplished in minutes or hours; or they’re forced to work with a review-focused enterprise architecture team who hasn’t been actively involved with software development for years (to name but a few common challenges).  This is akin to putting their racing car engine into an organizational tractor.  Is it any wonder you’re not winning the race?

Yes, it’s nice that we’ve discovered ways to get better at software development, but what we really need to do is streamline our approach to IT in general so that we can enable our organization to become a lean enterprise.  Our software development engine needs an effective IT chassis so as to enable our lean enterprise racing car to win the race.

Race car

Here are several strategies to help you to go beyond building an agile software development engine and instead build a “racing car” organization:

  1. Go beyond agile software development.  When we’re optimizing a race car, it’s not just about the engine.  The tires, the shape of the body, the shape of the spoiler, the design of the suspension, and many other factors come into play.  Similarly, it’s not just about optimizing your delivery teams, instead we need to optimize the whole of IT and more importantly your organization in general.  We need to be enterprise aware in our agile transformation efforts: While our development teams to be more agile we also need to transform the teams that they’re working with.  This includes our stakeholders, the data management team, the enterprise architecture team, the portfolio management team, and others.  The challenge, as we point out in principle #15 of the Disciplined Agile Manifesto, is that these teams will likely need to support a multi-modal IT department – some delivery teams (we hope most) will work in an agile/lean manner, some will work in a more traditional manner, and some may even work in an ad-hoc manner.  The implication is that anyone working with more than one IT delivery team will need to be prepared to work in a mode that reflects the paradigm the team is following.  In other words, you’ll work with an agile team in an agile manner, a traditional team in a traditional manner, and so on.  More on this in a future blog posting.
  2. Adopt a flexible, context-sensitive mindset.  Races are run in a range of conditions, and a race car must be sufficiently robust to operate in these conditions.  Similarly IT teams work in a variety of conditions: They range in size and in geographic distribution; the face zero or more regulations; they face a range of domain and technical complexities, and of course every team is made up of unique individuals with their own preferences, experiences, and skills. In short, one process size does not fill all.  To address the need for process flexibility the Disciplined Agile framework supports multiple delivery lifecycles, it promotes a flexible goal-driven strategy that guides you through process choices, and it now includes process blades describing flexible strategies for strategic IT capabilities such as release management, enterprise architecture, reuse engineering, and many others.
  3. Optimize the flow across all of IT.  All the parts of a race car work together effectively as a whole, they are more than a collection of parts bolted together.  It is the same for an IT department.  For an agile software development team to be effective they must be governed in an agile manner, the enterprise architects must support them in an agile manner, the data management team needs to be responsive, the release management team needs to be able to short frequent releases, and so on.  For the enterprise architecture team to be effective the software development teams that they support must be enterprise aware, the data management team needs to recognize that architects need to look beyond data, and so on.  Every team interacts with other teams and must do so effectively.  When one team wants to work one way and another team wants to work another way its the equivalent of trying to use a metric gear with an imperial gear – they simply aren’t going to mesh and progress will grind to a halt.  It is far more important that these teams all follow flexible and compatible approaches rather than approaches that are locally optimized for each team.  Just like a perfect metric gear won’t work with a perfect imperial gear, a strategy that is perfectly optimized for your enterprise architects will likely not work well with a strategy that is perfectly optimized for data management.
  4. All teams will improve.  Your IT department, and your organization as a whole, is a complex adaptive system.  It is a collection of teams working together to achieve, we hope, a common goal.  Each of these teams will be learning from their experiences and improving their approach.  Changes in one team will potentially affect the way that they work in other teams, requiring changes there.  The implication is that your organization is constantly evolving, we hope for the better.  With a goal-driven approach teams can recognize what their process options are, and the trade-offs of each, providing lightweight guidance for choosing effective strategies to address the situation they find themselves in.

We’d like to leave you with this: The collaborative, evolutionary strategies of the agile paradigm isn’t just for software development, but instead should be applied to your IT department and your organization as a whole.  We need race cars, not just race car engines.

One thought on “The Agile Tractor Engine Analogy

  1. Lynda Girvan

    Great post. I think this just perfectly highlights the skill gap that is ‘business analysis’. In some ways this gap is widening as Agile grows. Now is a good time to start thinking about how we grow BA’s to fill this business deficit?


Leave a Reply

Your email address will not be published. Required fields are marked *