Breaking your Organizational OCD
Regardless of the agile methodology you practice, continually improving should be your goal. We want the product to be better, we want better quality, we want to work more effectively. Agile development practices, and retrospectives in particular, are effective in helping us improve because of the tight feedback loops and team ownership. How are we doing outside the team though? Does your company have strange rituals that no one understands and no one can seem to change? Do you have organizational OCD? Say for example…
A team wants to deploy their software to another environment for testing…but they have to fill out a form and wait for a DBA to execute the SQL script to update the database. That person executes the script and walks away, leaving the team to flail with questions. ‘Did all of the data update? I don’t know, I can’t see it.’
Scrub scrub scrub
A young developer wants to try out an open source job scheduling library that would save him from writing his own. But wait, that library isn’t on the approved library list – so the options given are to either use the approved library (that isn’t thread safe and doesn’t support eventing) or come present why he should use his library to an approval board.
Scrub scrub scrub
Your deployment process is not automated, rife with handoffs, and full of opportunities for ‘waiting for email response.’ Someone is willing to create a prototype showing how deployments could be automated. Ok…but create a committee before you do any work.
Scrub scrub scrub
If any of these examples sound familiar, then maybe your organization has some form of organizational OCD. You are not alone. While I am no psychologist, I want to see you get better.
Teams working on adopting agile practices will uncover large organizational impediments, well beyond the responsibility of the team. These impediments have been there for a while – Agile practices are just making the cost of them much more visible. For example, I have seen a team track 11 days to deployments over four two-week iterations. Some of these problems are real – distributed agile teams are challenging and will require changes to the way we address projects. Other impediments fall into a ‘ritual’ stack. Rituals are more than just ceremony; ceremony is an elaborate, time-consuming means to achieve a valid goal. Rituals are progress distractions. Rituals are sinkholes of time and money with little if any value.
Organizational rituals are often steeped in historical significance (8 years ago this one real bad thing happened). More often than that, rituals come from a lack of trust. Breaking a ritual that happened in response to an old event is far easier than breaking rituals based on a foundation of mistrust. While I would recommend the below steps in both situations, when there is mistrust the lack of solid leadership must also be addressed. When there is smoke, there is fire; and when there are politics, silos, and dubiety there is weak leadership. That is a topic for another time. On to your recovery.
- Identify the ritual. Don’t think you have any rituals? Just listen. Wait for the question from the new team members – ‘Why do we do this?’. Large recurring meetings, committees, and the famous POST-MORTEMS are also nice places to start.
- Identify the issue the ritual is trying to solve
- Ask “Does the ritual really prevent the issue,” or is it something else?
- Imagine the worst case scenario that could happen if you stopped the ritual, and quantify its cost and its probability.
- Commit to not doing the ritual once and see what happens. Have measurable expectations to compare “with ritual” and “without ritual”.
- Realize that not doing the ritual wasn’t the end of the world and may have just made our work more enjoyable / product more successful.
Let me give an example.
A sharp young tester joins our agile team. We have some stories complete and are ready for some cross-cutting testing to take place. The tester wants to pull the application into his environment for testing…but has to file a ticket for the deployment team to push the code to his testing environment. He says “I’ve worked with the team, I understand how the application is put together and know how to get application up. Why can’t I deploy to this testing environment?”
- That’s the cue – someone has seen a potential ritual – inability for a team to control their own environments for testing.
- What issue are we trying to prevent by not allowing a team to control their environment? Well, we share environments and we don’t want someone to accidentally affect another team or break their environment.
- Ask “How does restricting access stop a typo?” Isn’t it still possible for someone on the environment team to make the same mistake?
- Imagine the worst case scenario. What would be the impact, and what’s the probability of it happening? In this example, the worst case scenario is that another team’s environment would be affected. This would cost that team 2 hours to redeploy their latest build and reconfigure. The probability of this happening is small as long as people pay attention to their directory.
- Commit to allowing the team to control their environment once and measure results. Was anyone else affected? How much time was saved, both on the product team and on the environment team?
- Was not doing the ritual that bad? Could we address the original concern differently – in this scenario with separate accounts per project?
As more companies embrace an agile development culture organizationally, they will not only need to ask themselves if there are rituals that need to be broken, but they will also need to create an environment that will challenge rituals from being formed.