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.

Steps to break your organizational OCD

  1. 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.
  2. Identify the issue the ritual is trying to solve
  3. Ask “Does the ritual really prevent the issue,” or is it something  else?
  4. Imagine the worst case scenario that could happen if you stopped the  ritual, and quantify its cost and its probability.
  5. Commit to not doing the ritual once and see what happens.  Have  measurable expectations to compare “with ritual” and “without ritual”.
  6. 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?”

  1. That’s the cue – someone has seen a potential ritual – inability for  a team to control their own environments for testing.
  2. 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.
  3. Ask “How does restricting access stop a typo?” Isn’t it still  possible for someone on the environment team to make the same mistake?
  4. 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.
  5. 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?
  6. 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.

This entry was posted in Agile Development, Agile Management. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>