Detect and Eliminate Bureaucracy in Geographically Distributed Large Agile Teams!

One of the many great things about working in Agile teams is the lack of bureaucracy. Agility and bureaucracy do not and cannot coexist. In general, bureaucracy is a system of government in which most of the important decisions are made by state officials rather than by elected representatives.  

Management guru Gary Hamel says,

“Strategy gets set at the top. Power trickles down. Big leaders appoint little leaders. Individuals compete for promotion. Compensation correlates with rank. Tasks are assigned. Managers assess performance. Rules tightly circumscribe discretion. This is the recipe for “bureaucracy,” the 150-year old mashup of military command structures and industrial engineering that constitutes the operating system for virtually every large-scale organization on the planet. It is the unchallenged tenets of bureaucracy that disable our organizations—that make them inertial, incremental and uninspiring.”

In our context, bureaucracy is with reference to geographically distributed teams working together to run Agile projects. When there is bureaucracy in geographically distributed teams, you will find powerful forces setting the rules, defining practices and mandating criteria. And there will be several followers who are ready succumb to the pressure. When this happens one may witness specialized definitions, measurement criteria, and rituals that define the software lifecycle to be followed by distributed teams. Decision making will move up in the hierarchy. Teams will practice practices just for the sake of practicing. Many of the team members will eventually forget the purpose, essence and sprit of processes. That is a slippery slope! In geographically distributed teams – especially when multiple organizations and powerful leaders come together, it is very difficult and challenging to guard against bureaucracy.   When that happens, we cannot have true Agile enablement.

This session will present the ground realities seen in distributed Agile projects and techniques to overcome bureaucracy in geographically distributed teams.

 
1 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  1. Introduction/Context Setting – 5 minutes
  2. Patterns of Ground Realities or Signs of Bureaucracy (with multiple examples) – 30 minutes

Pattern-1: Practice Bureaucracy   Example: ‘For us these four practices are mandatory’

Pattern-2: Innovation Barricade - ‘New ideas? Let us focus on what we are doing now. We will look into all these new ideas in the next project!’

Pattern-3: Development Hurdle - ‘All new training requests will have to go through Mr. Brown’s approval which takes about three to four weeks.’

Pattern-4: Infrastructure Blockade - ‘Our Video Conferencing facility is for board meetings only.’

Pattern-5: Methodology Obsession: ‘We are an XRXM house.’

Pattern-6: Tools Dictatorship: ‘You may be in the middle of this project but it is our organizational decision to migrate from tool X to tool Y.’

Pattern-7: One-upmanship: ‘We will do the Root Cause Analysis here in our location and announce the results to the rest.’

Pattern-8: Bureaucratic Governance: ‘We are very busy unless there is an escalation.’

3.  Techniques to overcome bureaucracy in geographically distributed teams – 15 Minutes

Examples

Learning/Building Awareness

Agile Coaching

Principles-First Approach

Servant Leadership

Leadership-level Retrospectives

 

  1. Discussions and Wrap-up: 10 Minutes

 

Learning Outcome

The attendees of this session will understand

a)      How bureaucracy sets in when we initiate and run distributed Agile projects

b)      Why this happens and how it impacts agility

c)       What are the signs or symptoms

d)      How to overcome bureaucracy in geographically distributed teams

Target Audience

Practitioners of agile in onsite-offshore model, team members working with geographically distributed large agile teams, business analysts, business users, coaches, senior management

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Naresh Jain
    By Naresh Jain  ~  2 years ago
    reply Reply

    Hi Raja,

    Thanks for the proposal. What you've highlighted as patterns seems really only the problem definition (smell.) Can you please take any one problem and help us understand the solution, forces and other parts of the pattern.

    Also in the 8, there seems to be quite a bit of overlap. Can we reduce the list down?

    • Raja Bavani
      By Raja Bavani  ~  2 years ago
      reply Reply

      Naresh,

      You are correct. These are the problem definition.  Let me attempt to take one problem and describe it in my reply here.  Some of these 8 are interrelated and have some overlap, we can reduce the list if there are time constraints or group them or sequence them in such a way that they are presented together.

      Pattern-1: Practice Bureaucracy    

      Context:

      You are part of a large distributed project.  Your delivery organization announces that three or four practices are mandatory in all projects in order to be qualified as ‘agile’ projects. These practices are ‘Pair Programing’, ‘TDD’, and ‘Story Point Estimation’.

      Problem:  You want to deliver value to customer by improving code quality, eliminating defects and improving estimation accuracy.

      Forces:

      Improving Internal Quality of Code – You want to ensure that code delivered by your team is of acceptable quality.  You want to understand what acceptable quality is and set expectations with your team and customers.  You understand what attributed are critical in terms of product lifecycle –  for example,  Security, Scalability, Maintainability, Customizability and so on. You establish an understanding on how this will improve the lifecycle of your product.  And you want to select practices that will help you accomplish these goals.  

      Removing Defects at Unit Level within Iteration:  You want to identify and fix defects early in the life cycle. You want to identify the right practices that can suit various parameters of your project such as proficiency of your team, technology platform and so on.  You want to pick and choose the right practices that can help your team meet acceptance criteria.

      Establishing an approach for estimation and improving estimation accuracy:  Your goal is to improve estimation accuracy at team level.  In order to do this, you want to select a feasible estimation technique.

       

      Solution:

      Follow Principles-First Approach:  Begin with understand Agile Manifesto and Agile Principles. Next, relate various Agile Practices to Principles.  

      Invest in Agile Coaching:  Seek help from an expert who can play the role of Agile Coach.  Let this expert interface with your delivery organization, build awareness, improve flexibility and help you eliminate bureaucracy.

      Upgrade Your Organizational Policies:  If these mandatory practices are being governed by your organizational policies or process repository, upgrade your organizational policies so that this smell does not impact future projects.

       

      Consequences:

      A. Benefits:

      You understand your project needs first and follow the essence of agile software development instead of blindly following certain practices or imposing practices on your team.  This will result in both team satisfaction and customer satisfaction.

      In your next project, you will not impose a practice just because it worked well in your previous project.

      B.Liabilities:

      You need to put efforts in identifying practice bureaucracy.  Also, you need to be mature enough to avoid ad-hoc development approaches by avoiding agile practices.

      Questioning organizational policies will pose challenges such as conflicts with your peers or superiors.  In your attempt to identify and eliminate practice bureaucracy you must be able to deliver results in the project.

       

      Any questions, please let me know.

       

       

       

    • Steve Ropa
      By Steve Ropa  ~  2 years ago
      reply Reply

      Hi Raja,

       

      I like what you are saying here, and agree.  I wonder, is there a such a thing as a "right level of beaurocracy"?  In other words, how will you answer the folks who say some structure must be in place, especially for a distributed team?

      • Raja Bavani
        By Raja Bavani  ~  2 years ago
        reply Reply

        Steve,

        Interesting question!

        We know that every organization has some level of bureaucracy. Those who are used to it - and those who have basked in that fire - will argue that some level of bureaucracy is required.  I read the article 'Why Bureaucracy Must Die' by Steve Denning in Forbes website. The URL to this article is http://www.forbes.com/sites/stevedenning/2014/11/07/why-bureaucracy-must-die/  - It is worth a read.

        Yes, some structure must be in place.  And that has to be a structure that can exhibit the right behavior to nurture Agile teams.  We need structures that can foster discipline, commitment, ownership, collaboration, transparency and so on. We do not need structures that do not foster all these but bring in bureaucracy. Bureaucracy does not bring in discipline.   Bureaucracy is not discipline.  (Scott Ambler mentions this in one of his blog posts (Link - https://www.ibm.com/developerworks/community/blogs/ambler/entry/bureaucracy_isn_t_discipline?lang=en ). 

        That would be my short answer!