This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.
Managing the Middle Manager Conundrum
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
- Clearly defined role and responsibility
Tasks 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. Reporting 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.