Ready, Fire, Aim is often used disparagingly to describe how incompetent operators perpetrate disastrous projects on the dime of the companies for which they work.  Such people become attached to ideas and then pursue them to a catastrophic end.  Sort of like New Coke, though that turned out better than it should have through a twist of serendipity.

However, I think that by viewing it through a different lens, I can show that Ready, Fire, Aim is the only way to achieve real agility.

Ready, Aim, Fire

In a previous article, Is Detailed Design Anti-Agile?, I suggested that too much up-front design was anti-agile.  This results from:

• The need to produce a product design and implementation workplan (which will become something of a contract) in sufficient detail to obtain approval and funding for a ‘project,’
• The need to adhere to the approved scope, schedule and budget allocated for the ‘project’ combined with the need to report on its status on a regular basis,
• The human proclivity to cling to ideas we work so hard to develop and incorporate as part of a project proposal and then become inflicted with confirmation bias that causes us to resist conflicting or contradictory ideas and information that emerge in the course of executing the ‘project’ and
• The fear that advocating for or accommodating changes that impact any of the triple-constraint project parameters will call into question whether the proposal was adequately thought out when it was submitted.

All of this is described in two previous articles: Can Starting With Waterfall Lead to Better Agile?Parts I and II. 

Traditional project management wisdom says that Ready, Aim, Fire is the only way to do it.  You must envision what you want to deliver, design it and the project to deliver it and only then start working on it within the triple-constraint envelope you have defined for it.  Of course, most companies have adopted Agile frameworks, such as Scrum or SAFe, and therefore believe themselves to be immune from this particular syndrome.  Unfortunately, they persist in applying traditional governance approaches to ‘projects’ executed with Agile frameworks, and this renders them not agile.  I have discussed this in a number of previous articles, as well.

Simply put, any time that you encapsulate an agile initiative within a triple constraint, you are obviating a great deal of the agility that will improve your chances of realizing the business outcomes you’re targeting.  These outcomes are predicated on deliverables that are both commercially viable and technologically feasible. 

It’s somewhat understandable that companies do this; managing really agile initiatives requires executives’ time and exerts a larger cognitive load than managing traditional projects does.  Traditional project management approaches were designed to comport with a hierarchical command-and-control model that is parsimonious with managers’ time and attention.  It allows them to assimilate the maximum amount of information about the status of initiatives they’ve approved in the minimum amount of time. 

Project dashboards are a good example of this thinking.  They allow executives and senior managers to consume information at their convenience and lead them to believe that they are keeping up with their investments.  Sadly, the processes and practices supporting these things lend themselves to gaming and all too often everything looks as if it is going to plan just to run into a major snag toward the end of the delivery schedule.  Often that snag results from the first collision between the product and its intended market when the reality of commercial viability versus initial assumptions rears its ugly head.

Ready, Fire, Aim

Before exploring this approach, it is worth saying that I do not want to throw out the baby with the bathwater.  There is nothing wrong with dashboards and collaboration tools when they reflect accurate and valid indicators of initiatives’ health.  I also do not believe that agile initiatives should be funded on the basis of whim and allowed to meander and pivot without oversight or question.  Executives with accountability require and deserve accurate information about their initiatives’ status so that valid decisions can be made about their continued viability.  The problem is that the practices and mechanisms often employed rely on an approach that doesn’t account for the inevitable learning that takes place over the course of every implementation.  This inhibits making changes that could produce better outcomes.  

In point of fact, I believe that implementation of initiatives should start before you know everything that would normally be required to obtain funding under a traditional model with the expectation that information will emerge to inform the path of the effort throughout its life.  I also believe that your company should fund initiatives iteratively, with the intention of discovering answers to relevant questions about viability and feasibility at each stage before funding the next.

Why is this?

• At the outset of the initiative, there is quite a bit that you probably don’t know, much of which will ultimately influence your deliverable design and your implementation plan.  If you wait to request approval for funding until you have all this information, then you will waste time you could have put to good use.  You will have also inevitably established a deliverable definition and workplan that you can improve with mid-flight modifications, but this will expose you to all the resistance issues we’ve discussed previously.
• You need to allow for learning to influence both the deliverable and the path you will take to realize it.  It’s highly improbable that you will be able to discern how these two things will influence each other until you can experience their interaction out in the wild.
• You need to sequence your implementation path to prioritize answering questions that you had at the outset or confirming or refuting the assumptions and hypotheses that you started with.  You also need to be willing to act on what you learn whenever you learn it.  If what you learn leads you to believe that you are not on a viable path to success, you need to be willing to shelve and rethink or terminate the initiative.

So simply put, you need to start initiatives on the assumption that you will find confirmation and answers as you go, and you will refocus your efforts based on what you learn along the way.  You’ll accelerate your response to the opportunity or threat you are focused on and by staging the initiative strategically and being funded iteratively, you will put less at risk than you would with a traditional ‘project.’

Sound scary?  It might but if you think about it, it is the only way that you can keep pace with the VUCA environment we’re operating in.  Trying to do that by making a number of large bets based on incomplete knowledge is clearly a high-risk strategy, one that is more likely to impair your success than get you where you need to go.

Success at adopting this approach requires that you adopt some organizational changes and develop a comfort level with the idea of operating more like a venture investor and less like a large, bureaucratic company.  I will have more to say about this in forthcoming articles.