“Improving daily work is even more important than doing daily work.” — The Phoenix Project
Your development team needs to deliver quickly and consistently. Without a plan to deliver features to your market, you’re giving your competition the opportunity to beat you out of your own market. In order to swiftly deliver products to market, your team needs to make sure that they have the right tools in place, and — equally important — that the team can learn and improve with each delivery.
During my development career, I’ve worked in unmanaged development teams and agile teams that used sprints to time-box development. In either case, the teams still got work done, delivered increments, and found a way to track work — either by writing tasks down on a whiteboard, or keeping track of tickets in JIRA. But there were large differences with the quality and the consistency of those deliverables.
The good teams worked on stories and made sure that delivery of features was simple. These teams were cross-functional. The took the task of DevOps into their own hands and made sure that taking the feature from local development all the way to production was straightforward, well documented, and fast.
The best teams did what the good teams did, but they made sure that with every delivery, the team learned and improved their processes. This goes beyond just having weekly or bi-weekly retrospectives. These teams introspected at every step of their delivery process. Were the stories too vague? Did we not have enough tests? What type of test would have caught this bug? Why was deploying to production so difficult this sprint?
The Phoenix Project
While reading The Phoenix Project, the fable details the turn-around of a dysfunctional company that has been trying to launch a large, new initiative aptly titled “The Phoenix Project.” Throughout this fable, the main character, Bill Palmer learns the reasons why the project is failing, and learns techniques to turn The Phoenix Project around.
At the end of the book, the development and IT teams work together to create a system of fast flow of work and fast feedback that real development teams can imitate to create consistent and quality product deliveries.
The Four Types of Work
To understand how to have a team work consistently, we should first identify the types of work that these teams regularly perform:
- Business Projects — These are tasks set forth by the business to deliver to customers or to provide value to the company.
- Internal (IT) Projects — These are projects that do not directly provide value to the business, but must be done nevertheless. Perhaps IT needs to roll out security patches to all the database instances. Or maybe a development team needs to tackle technical debt that needs to be performed.
- Changes — This type of work consists of deploying changes to an environment or smaller work like server configuration changes.
- Unplanned Work — Work that the team did not plan to do.
While The Phoenix Project was about DevOps and IT, many of these types of work can be applied to cross-functional development teams. These teams typically work on products, have their own internal projects, deploy changes, and have a load of unplanned work that they end up having to take care up.
The greatest time sink and most important type of work to identify during development is the unplanned work that the team does. A team should introspect their own development and find unplanned work that they did and ask themselves: Why was this unplanned?
Typically, unplanned work comes from poor scoping of a ticket, or poor quality when working on and delivering a ticket.
If your team is constantly firefighting and working on squashing production bugs that weren’t planned to be worked on, the team should get to the root cause of these bugs and tackle the cause, not the symptom.
Getting to the Root Cause
Fix the cause, not the symptom
When dealing with unplanned work, it is important to uncover the root cause and make a plan to track that work or prevent it from happening again.
A simple technique for getting to the root cause of a problem is to use the 5 Why’s. Deep dive into the problem by constantly asking “Why?” in order to get to the root of the problem.
The key to fast flow and fast feedback is have your team pay attention to the work that they do that wasn’t planned for. It is important as a team to track this work and find out why it is happening, otherwise, the team will eventually spend more time working on unplanned work, then on the work that matters.
The best teams I have worked on made sure that before a ticket was worked on, they would write a list of potential steps based on a team discussion, then after a ticket was completed, the ticket would be updated with the actual steps. Teams should regularly review the discrepancies to make sure that future work takes these steps into account.
Sales and marketing often have checklists that are constantly updated to make sure that salespeople and marketers don’t miss crucial steps. Development teams should create similar lists to create shared understanding of the potential hurdles they face.