f you’ve read Col Boyd’s biography, then you already know what I’m about to talk about, and if you haven’t read Col. Boyd’s biography, add it to your list. Col. Boyd was a fighter pilot, the creator of the OODA loop, and also the architect of the Desert Storm Battle Plan. After he’d already led a pretty full life of being one of the best fighter pilots in the Air Force, he started to study a problem that had nagged at strategists: Why are some fighter pilots successful and others aren’t? How can someone in a technologically inferior aircraft beat a pilot in a technologically superior aircraft? Through his efforts, he figured out a theory that drove success and failure in dogfighting, and it’s a lesson that applies to successful software development as well: Some teams win because they’re able to execute the The Observe, Orient, Decide, Act (OODA) Loop faster than their competition. This is the success that Scrum tries to replicate, and one of the reasons why Scrum practitioners are assigned Col. Boyd’s biography. The value in the loop is how quickly you’re able to execute the entire loop for any given problem. For small teams, this is easy, there are very few people to take part in the loop. For larger teams — teams that can be helped through process automation, it’s much harder.
You can read more about the OODA loop here, but for our purposes we’ll tie that loop to how current ALM software works:
Observe – Put in Jira ticket
Orient – Team prioritizes that ticket (manually)
Decide – Team moves that ticket into the “sprint” (manually)
Act – Team member(s) complete that ticket (and hands off to other team members, manually)
The loop itself drives how quickly a problem is manifested and acted upon — something that successful software teams do is that they’re able move through those steps faster than other teams. This is important for all types of teams, not just product teams. If you work in enterprise software, you have necessarily long sales cycles, and it feels like the impact of your work won’t be noticed for 6-9 months — but that’s not the case. Internal stakeholders see your work daily or weekly, and being able to respond quickly to their concerns is important to build and maintain trust in the organization.
So why is JIRA associated with slowness in teams? Why is it maligned by startups and small product teams? Theoretically, it should be the perfect enabler of executing the OODA loop quickly. It knows all the information. If you’ve set up JIRA properly to track that information it knows what the impending ticket affects. It knows who can work on it (who has bandwidth), and it knows based on your past efforts whether that item is likely to get done. All of that data is sitting beneath the surface, waiting to be queried, and yet JIRA hides it.
Our teams need the ability to make reasoned decisions; and JIRA contains all of the data we need to make process decisions, and JIRA can be automated to help your team execute the OODA loop faster.
If you’d like to know how to unlock JIRA to help you make these decisions, hit reply and let’s talk.