DevOps is a software development practice that specializes in the frequent delivery of software features and improvements. Through rapid integration of changes and receipt of feedback we build a culture of confidence and reliability in the software lifecycle. Additionally, teams that follow these practices are highly productive for their organizations and themselves.
Successfully employing “DevOps” is more than a technology change, it is a culture shift. Your entire team must work with a mindset and a method for learning, executing change and sharing knowledge. Today’s tidbit will help you understand the goals of these cultural shifts and provide some ideas on how it makes your team more effective.
Will a cultural shift benefit your organization?
First, ask yourself some questions about your team dynamics:
- Does your team toss problems “over the wall”?
- Do your team members often report being blocked by other people?
- Do you have a lone hero when problems are solved?
If you answered “yes” to any of these questions, then it’s time look at some cultural shifts. Here are some considerations to make with regard to shared responsibility and collective accountability, two pillars of a great team.
Shared Responsibility
It’s human nature for people to get laser focused on what they feel is the primary responsibility because it is their responsibility. Focus on software quality, team dynamics and knowledge are all secondary because of the tight schedules and high-pressure deadlines we face. It’s an important first step for your team members to realize that a product’s successes and failures are shared and their job is not limited to the assigned task.
In a team that shares responsibility, problems do not often get thrown ‘over the wall.’ A team member who discovers a problem will take point on the issue and see it through to resolution. Sometimes that means solving the problem themselves or engaging people with experience in the needed areas and working on it collectively. No longer should you have problems rotting in the backlog or waiting on Jimbob to come back from vacation. As an added benefit your organization will be better insulated from the Bus factor.
This pattern of behavior has benefits to the company, the team and the individual because issues are tackled head on, solved right away and knowledge is shared. Your company will have a reduced cycle time on bugs and deployments which means you can confidently deliver more frequently.
Collective Accountability
Collective accountability and shared responsibility are very similar. The idea behind accountability in your development teams is that there is no blame. It causes more harm than good to focus on the ‘who caused the problem.’ Retrospectives and war rooms full of troubleshooting engineers should be focused on solving problems and mitigating risks. You want your team to feel empowered to introduce change and not fear of retribution when some innovative idea doesn’t work out as planned.
Using Jimbob as an example, let’s say he merges a small improvement into Git. The peer review passes muster, the automated tests pass and it’s deployed into production. Now there’s a problem that wasn’t detected by our test suite. Ask yourself, how would your team react?
The most common reaction is for someone to engage the team’s lone hero and have them troubleshoot. It’s determined that Jimbob’s recent improvement actually caused the problems we’re seeing. The team’s slack channel is notified:
The problem may go unresolved for some time and your end-users are affected.
In an ideal case, whomever discovers the issue in production would immediately troubleshoot the problem and regardless of who’s change it was, fix it or revert it. Once the problem is resolved, feedback can be distributed to the team and new test cases written to detect these defects automatically in the future. The team’s slack channel is notified:
“Never Let A Good ‘Crisis’ Go To Waste”
In either case, we need Jimbob to be aware of his mistake – that’s how we grow and learn. However, it’s a fine line we walk between providing constructive feedback and assigning blame.
Conclusion
Teams that have a great culture and a structure for continuous improvement are going to get more work done. Those folks will be happier in their roles and your company will be more profitable. Whether you are already utilizing DevOps concepts or it’s something you’re considering to strengthen your team, remember that at its core it is a culture. A culture is something that is unique and doesn’t have an instruction booklet. There are no quick and easy steps to get there but simply ways to measure and develop those habits internally.
Stelligent brings these cultural concepts to every engagement to help your teams be more successful. Through people, automation, pipelines, planning and security we help customers delivery confidently and more frequently in the AWS cloud.
|
Stelligent Amazon Pollycast
 |
