5 Minute DevOps: Happy Teams Deliver Quality
Nathan Nicholson contributed to this post.
Delivering new solutions for business problems is fun! The more fun something is, the more motivated you are to do it frequently. Delivering more frequently requires disciplined and a focus on quality. Together with Lean process teams are enabled to accelerate delivery and have even more fun.
There are several important key performance indicators (KPIs) used to measure how effective we are and where we may have constraints. Install success rate, lead time, cycle time, test coverage trends, Mean Time To Recover (MTTR), and deploys per day per developer are excellent objective metrics. However, there are some metrics for team morale we’d like to propose that may predict future trends in speed to market.
ChatOps tools, such as Slack or HipChat, are powerful tools for team communication. They enhance automation to keep the team informed about the status of the product and teams can engage in quick discussions on features without stopping everything to meet. They are also powerful tools for team building.
The constant communication between team members broadens the communication channels in the team and builds relationships. As the team talks on shared goals and shares experiences, trust increases. This allows team members to trust that “my silly idea” can be discussed openly without fear. Many silly ideas just aren’t that silly and collaborating makes those ideas even better. In addition, the bonds that are created within the team are exceptionally important during times of high stress. At 3:00am, when the system is down and the pressure is high, a trusting team pulls together to handle things. MTTRs drop and sleep is optimized for.
The Memeometer measures how frequently the team responds to each other with fun, optimistic, ChatOps reactions. It indicates how relaxed the team is and how secure they feel about their quality. Enjoying daily work is just as important as delivering daily work.
Mean Time To Innovate
Teams who are frozen in reactive mode do nothing except work to fix old problems that weren’t fixed the first time. New problems are FUN. Old problems just aren’t. Reacting to poor quality, poor requirements, or poor process will cause teams to be focused only on the current issue instead of how to improve for the future. We know that if we are not improving, things are getting worse. We’ve seen this. Teams who focus on quality and then are driven into reactive mode can get by for a time, but eventually the quality runway ends, and MTTRs increase, and hours of unplanned work skyrocket.
Mean Time To Innovate is how often experiments are run to find better tools and processes to remove waste from the system. A team who is able to focus on product strategy and goals will increase automation and reduce process because innovation is FUN. A high performing team will spend a significant portion of their time on experimentation and innovation.
In 2008, Gary Gruver at HP focused his teams on improving how work was done and the innovation dividends were dramatic.
An optimistic team can do things a pessimistic team just isn’t capable of. An optimistic team asks “why can’t we?” instead of assuming they cannot. An optimistic team doesn’t require a perfect environment, they only need to know that they have the power to improve imperfection. A team that feels they have true ownership in their product, that their actions can improve their lives and the company’s performance, will be optimistic about the future. They will drive to make things better because they know they can.
The Milliopt is a measure of optimism expressed by the team. Is the team asking questions? Is the team challenging direction and proposing alternate solutions? Is the team “swimming upstream” and challenging the status quo? Are they asking “WHY?” These are all good indications of an empowered team who feel optimistic that they can make their world better, and that’s really what drives a high performing team. They can be challenging to work with sometimes, but only order takers are easy to work with. Order takers struggle with accelerating their value delivery.
Deploying changes quickly isn’t enough. Even bad, untested code that “works on my machine” can be deployed rapidly through automated deploy pipelines. If you only measure velocity, you have a poor indicator of value delivery. Happy developers do not deploy terrible code quickly because happy developers optimize for sleep. Sleepy developers are not happy!