Attending Agile 2012 and meeting many practitioners and soon-to-be practitioners of agile development was an awesome experience. The opportunity to network and talk shop with a wide range of individuals cannot be duplicated. Many of the conversations re-opened an age old question when organizational change is involved: “What is lurking that will make us fail?”

As a coach, I struggle with this question. There are many potential failure points, but with a solid plan, measured rollout and a lack of fear to tweak your process (continuous improvement), you can change potential failure points to mere nuisances as you move down the agile adoption path.

If there is an Agile Boogeyman lurking, however, I would focus on the role of the middle management post-transformation. I have seen the middle-manager conundrum stall and reset more than one attempt at agile.

So, what exactly is the middle-manager conundrum? Simply put, their day-to-day activities will change more dramatically than anyone else in the organization. There are three common areas to monitor:

  • Task assignments
  • Reporting
  • Clearly defined role and responsibility


Today, a manager may be delivering daily task assignments to his/her team in a command-and-control environment. In a post-transformation environment, this will no longer be the case. The team will take their cues from the business and determine their own tasks each sprint. Cutting this activity from the manager may create a rather large hole in their day.


One of my biggest regrets working in waterfall projects was the amount of time spent on reporting. The extent that project managers go to (I am equally guilty) to use numbers and statistics to convince everyone that a project is “healthy” is absurd. Oftentimes, middle managers are the hub of this reporting. I have seen more than one manager work 8 to 14 hours per week to compile a 30- to 50-page reports detailing all of the projects in the portfolio. This level of reporting with MS Project schedules, EVM, % complete, etc. will largely fade and be replaced by a few simple charts (chiefly, burndown). In a paper-based agile environment, compiling this reporting might take no more than 10 to 15 minutes for a portfolio of 8 or 10 projects. With a tool like VersionOne, this may take seconds if you have the custom reports built and ready to run.

Roles and Responsibility

This brings us to roles and responsibility. If shifting the burden of task assignment and reducing reporting opens free time in your manager’s schedule, it needs to be addressed. Human nature will prompt your managers to fill that time. If you do not outline how they should do that, you run the risk of a manager regressing back to more comfortable habits (i.e., the happy cocoon of task assignments and reporting) or spending time on activities that provides minimal value to the organization.

So what are some valuable activities for these managers? First, I would ask if they want to remain in that role. I have met more than one technical manager who regretted their decision to enter management. Modifying their role to be a leader for the newly set agile teams might be a win-win. Shifting an individual to an architecture role allows him/her to remain a leader, eliminates administrivia, and keeps his/her skills fresh.

If they would like to remain in management, have them contribute at a strategic level. Many of the tactical fires they used to fight will be reduced or handled by a ScrumMaster. Having the middle managers assist with strategy prepares them for future promotion, and keeps them engaged and interested.

Remember as you begin your agile transformation that it takes a team effort from all levels of the organization to structure and roll out a change of this magnitude. Ensuring that your managers are not left behind will not only improve the speed and quality of the transformation, it will relegate one more boogeyman to the myth pile.

Join the Discussion

    • Wayne

      As a person who walked into a middle manager position in a company that had recently transitioned to Agile, it was a bit different. I had come from a role where I was more of a product manager/architect but because of my ability to effectively work with people (i hate the word manager) and still being technical I accepted this new challenge. After being promoted, you are correct, my role has become more strategic. My group is largely responsible for development and my role as i see it is “making it possible for people to work…and have fun while they are doing it”. I provide mentoring, guidance, coaching to younger devs. I’m responsible for hiring, training and overall productivity. I help set the vision for where we want our dev staff to be down the road and how we will get there, while the Scrum Masters and teams are worried about day to days tasks. This has worked successfully at my company. But, I also believe that as a “manager” or non-functional person, your job is to get to a point where you are not needed and then you move on.

    • Arun

      The second part of what the manager can do says “If they would like to remain in management, have them contribute at a strategic level.” This is practically difficult thing, there are already people contributing in strategic level.
      My thoughts are during the transformation they are the game changers. Make them the facilitators of the change process. Some might wish to play the servent leadership role of SCRUM Master. In large development teams there are multiple challenges in terms of dependencies and engagement with Product Owners. The managers can help Scrum Masters resolve these impediments.

    • Mike

      The reporting capabilities of Version One eliminate a lot of what has traditionally been done manually at the PM and C level. Trust in your teams and visibility rule the day!

    47 + = 56