A non-IT executive’s guide to Agile Coaches

Agile is an almost management-philosophical idea that is about getting better at delivering valuable working software. There are people calling themselves agile coaches who try and help do this. In this short article we’ll go through one aspect of the agile coach role, inspired by a recent experience. Thanks to those who were involved in this journey, you know who you are!

Agile Coaches aren’t Project Managers

A lot of “agile” is around motivational leadership techniques that you may be familiar with, for example Stephen Covey’s “The Seven Habits of Highly Effective People” or Dan Pink’s “Drive”. If you get a good agile coach, they will help your other leaders and managers to shape and grow a motivated and capable team. Because coaches operate without the rank of a people-manager, changes can be deep cultural changes (if we use the definition of culture to be “what happens when no-one is looking”). The general focus you might expect from an agile coach is one of delivering value quickly and incrementally, failing often and cheaply, learning quickly, working creatively, collaboratively and transparently. With an experienced and capable agile coach or scrum master, you would also expect the capability and delivery of your team to measurably improve – something you may not expect from a Project Manager. That’s all well and good, but there are things you expect of a Project Manager that no one seems to be doing…

You want a Project plan

There are two separate points here, the first about Projects and the second around plans.

A Project can perhaps be considered a resource bucket (time/cost/quality/scope) which work takes place within. The “agile” way of thinking involves considering not fixed time Projects, but rather continually living Products. Instead of having the wrong thing delivered late and over budget, instead agile relies on the ability to have transparency and change direction quickly, resulting in less wasted time, money and effort. Despite what some evangelists may say, I’d argue there is no inherent problem with constructing things as projects, though it may be slightly misleading in that it can create an expectation that the product development will be “done”. There is often new work to do to make the customer happy and to remain competitive, and it’s fine to spin those up as new Projects or as new Product Epics. The language matters, but perhaps is not as important as the underlying sentiment of iteratively satisfying or delighting the customer. If the format of Projects works better for your business, keep with it, though please do try to make the projects small.

When thinking about plans, I find it helpful to think about what we are trying to achieve through having a plan. Often the thing executives want from a plan is transparency and dependability. As people-centric agile practitioners, we want to help provide what you (and the business) need. There are a few well established techniques for achieving this that are part of the standard agile toolkit, for example using story points, and articulating outcomes through a Product Roadmap. Arguably the smartest planning techniques rely on lean (from Toyota Production System), and more recently Monte Carlo simulations. It takes a while to implement lean forecasting, since the usefulness of any of these measures relies on having a reasonable amount of historical data to work with. For this data to be meaningful, it needs to be the same team, similar work, etc. As a rule of thumb, I’d say 3 months is possible, provided the team are stable and get good at breaking things down small (which gives even more data points). The required time depends on how variable the team’s work is, and additionally requires someone like a coach, scrum master or project manager to help support the team, Product Owner, and/or Business Analyst breaking down of work into small chunks. For a plan, we also need to know and articulate what we want to do and why, even if it is just a best guess. In my experience, it is helpful to have one person deciding what-to-do-in-what-order, and they are likely to naturally lead the planning efforts with the support of a Scrum Master or Agile Coach.

From any of these we can get a visual way to show historical and expected progress, with an understanding that we encourage change if it helps deliver more value. “Plans are useless but planning is indispensable” and “No battle was ever won according to plan, but no battle was ever one without one” come to mind. A final message to the executive reading: If you are open to trying new ideas of what plans look like, that is great!


Why doesn’t this article mention “sprints” or “velocity”?

Sprints (the idea of delivering a fixed scope over a short time) is a metaphor taken from Scrum, a very popular agile framework. Scrum is one of many agile frameworks, and an agile coach is often not constrained by approach, technique or framework. As such, nor is this article.

Velocity is another idea often implemented in Scrum environments, which is “Average Story Points completed per Sprint”. Often this is used for planning, though for some technical reasons I personally prefer not to use this in most cases. I recommend lean and customer-focused metrics for performance self-assessment and future planning.