Fear plays an interesting role in how we develop applications. Fear of being blamed for project failure (when most projects actually fail) drives people to push the responsibility for decisions as high up in the chain as possible. After all, if your boss made the decision you can’t be blamed if something goes wrong, correct?
Many organizations handle this by creating Working Groups and Steering Committees, all in the hope that if someone else says “yes” then it is their neck on the line if the world falls apart. DevOps, however, says something different. DevOps pushes peoples buttons and gets them into an uncomfortable position. In essence:
There are no Working Groups / Steering Committees in DevOps.
OK, DevOps doesn’t explicitly state that, but it might as well. The idea of DevOps, the idea of creating a team that is responsible for a service / function / application and that it is that team that makes the decisions, flies in the face of this shirking of responsibility. There is no “working group” because the team itself is the working group. There is no “steering committee” as the team itself is the steering committee. The team has both IT people and the business involved. They know the problem probably better than anyone else. Let the team decide.
Imagine how many fewer meetings you know have to go to! I have saved you half of your working career so that you can now concentrate on something productive.
”But what about governance?” Ah, that favourite buzzword that people don’t understand. There is a difference between governance and management. The Wheel actually has an article on the difference between the two terms and I find myself appreciating it more and more.
The governing body must govern; that is, it must provide leadership and strategy and must focus on the ‘big picture’. Governance is about planning the framework for work and ensuring it is done. As such, it is distinct from management (organising the work) and operations (doing the work).
So, the governing body will say, here is our strategy, we want to do this. The team will take that strategy and utilize it when making the decisions as to what work needs to get done at what time to meet that strategy. The governing body can be the organization as a whole, a unique business area or a specific individual. But they don’t need to constantly meet with the team and approve directions, approve which work needs to be done. They set a direction, establish a goal, tell the team to accomplish that goal and let the team manage themselves.
Governance needs to be lightweight. If it is heavyweight it is not governance, it is management. We use the term governance because, well, it’s sexier than management. But let’s face it, no matter what we call it, it’s just another form of management.
Working Groups and Steering Committees are ways that people use to absolve themselves of making a decision because “it’s not in my authority” to make the decision. No, the person doesn’t want to take responsibility because in their culture of blame, the person responsible is penalized for making that decision. So instead they call it a working group or steering committee and give them the responsibility for making the decisions because of “governance”.
Until you are ready to come to grips with the idea that to be successful the people closest to the problem, the team working on the solution, are the best ones to make a decision, DevOps will never be as successful as it can be. Give up Command and Control and embrace the freedom that this gives you.