The Role of Middle Management in an Agile World

When discussing Agile roles, there is much written about the ScrumMaster, Product Owner, Development Team, and Customer.  But there is less written about what the Middle Manager should do in an Agile World.   Note, when I talk about Middle Manager, I am talking about the Line Manager, Functional Manager, Manager, and Director level manager. 

I recently discussed the middle management roles within an Agile context to several different middle managers.  They each had an interesting perspective on what it was like when their teams became Agile. Here are two excepts:  

• The Functional Manager who was also the team's Line Manager noted that they spent much less time on directing the team on what to work on since the work was now coming out of the Product Backlog.  I told him that yes this is big adjustment.  He needed to focus on ensuring that his team members had the right skills, team impediments were removed, the Agile principles were understood, and the team were given the education they needed to become a fully cross-functional team.
• In talking to a Director who now has 3 self-organizing teams, she was telling me that she was having a hard time knowing what to do since she felt she had to get more hands-on.  She needed to help educate the team members around their new roles, and then allowing the teams to self-organize around the work was the right thing to do.  I told her by backing off, she could better provide more strategy level guidance to connect the organization’s strategies to the team or product visions.  She commented that this was very different from the more traditional management role she had been used too.  

Ultimately, it is important to understand that middle management are critical to the success of an effective Agile deployment.  They are the lynchpin between the executive’s vision for Agile and the team's ability to apply Agile as Middle management's willingness to allow Agile can help make it flourish or fail on a team. If they are engaged and buy into Agile, then the change may succeed. Even when executives buy in, if middle management does not do likewise, they can block a team's ability to succeed with Agile.    

If middle management don’t understand their role in the new order or feel threatened by the change, they may become Deceivers or Deniers and block the success toward Agile. Because of this, it is critical that middle managers are educated on Agile at the same time their teams are.

Middle management must adapt their role and learn to gently back away from their functional leadership, act more as a servant leader who trusts their teams, helps them remove roadblocks, and supports the agile principles and practices. They may attend the Sprint Review to see progress of the working functionality and the Daily Stand-up to gain a sense of team progress.   Middle management must also learn how to establish the concept of bounded authority where teams can make their own decisions and commit to their own work. The balance is that managers keep limited responsibilities to provide a vision and support their staff, while allowing teams ownership of their work.  Finally, middle management must be willing to be transparent about what is going on in the organization and be willing to communicate this information to the team. 

Other Roles that may suit Middle Management

Often middle management have less to do in an Agile world. The good news is that they may consider options such as changing their role to Resource Manager, where they manage more people but do not own an organizational functional area. They may consider a Product Owner role if they have been engaged in collecting requirements and interacting with customers. Although this role should no longer be managerial (i.e., not direct reports), a PO helps shape the product by collecting and grooming the requirements and collaborating with the team.   They may also move to another Functional Manager role where there is still a need for this role.  And some will remain their current middle management leadership roles.  If they continue to want to do the more traditional middle management roles, they may consider looking for companies that continue to look for the more traditional roles.  

How Middle Management can evaluate themselves in an Agile World

Here are a few questions  middle managers can ask themselves to see how aligned they are in managing teams in an Agile World.  These questions are based on material from "The Manager's Role in Agile" by Michael Spayd and Lyssa Adkins.  

• Are you allowing for self-organizing teams while still providing servant leadership? 
• Are you removing command and control elements while providing bounded authority?
• Are you supporting the Agile values and principles starting with marshaling a culture toward delivering value?
• Do you remove the language of false certainty, big-up-front planning and requirements, and big batches?
• Do you remove the significant roadblocks that hinder an agile team’s progress?
• Do your teams perceive you as a coach and leader more than as a manager?
• Are you helping the team with supporting their people and equipment needs?
• Are you adapting the performance objectives to support team accomplishments to ensure they are delivering the highest value?
• Do you help the teams when they have external team dependencies in order to get their work done?
• Are you fostering a learning organization?  Do you provide teams the time to get educated (training, coaching, etc.)? 

Gaining first-hand insight into Employee progress within an Agile World

In the Agile world, some people find the performance review process a bit challenging and in some cases feel that it is unneeded.  Because we are moving from a more command-and-control environment to a team empowerment environment, a person acting in the manager role (e.g., functional manager, resource manager, etc) seems to have a harder time understanding what their employee is doing. Also, the manager needs to realize that when we move into an Agile world, discussion of performance should occur in a more collaborative manner with a focus on progress and learning.

Why does it appear harder? First, the employee is not (or should not be) taking work orders from the manager any longer and instead, the work should be driven from the product backlog (via the sprint backlog from sprint to sprint). Second, the manager actually does have less visibility into what the employee is doing since the employee should be 100% commited to their Agile Scrum team. So what should a reporting manager do? I’ve heard about conducting a 360 peer evaluation, but this is basically second-hand information. The question is, is there a way to gain first-hand information? What I recommend are the following ideas that can help a manager who has folks who report to him or her that are on an Agile (or Scrum) Team.

Let us start by considering the areas along the Agile process where a manager could gain direct insight into what the employee is doing. The two Scrum practices where a manager could listen into what their employee is doing is the Daily Stand-up and the End-of-Sprint Review.

• During the Daily Stand-up (aka, Daily Scrum), the manager can quietly listen into the progress that the Scrum team members communicate during this brief meeting. Before you do this, contact the ScrumMaster and verify that this Daily Stand-up is an open meeting that you may quietly attend. If you do so, ensure you tell your employees that you may be sitting in on the Daily stand-up. If you have employees on multiple Scrum teams, you may not have time to sit in on all Daily Stand-ups. Instead of sitting in on random Daily-standups, a tip is to attend the same Daily Stand-up for 5 consecutive days so you get an idea of the work done by your employee for a weekly period (for continuity and consistency). Since the Daily Stand-up focuses on what the team member did yesterday, what they are planning to do today, and their risks, you will have some idea of how story and tasks are connected to the work of the employee and how well they are completing the work.

• During the End-of-Sprint Review, you can potentially understand the employee’s progress by seeing what they demo (assuming the team members conduct the demo and not the Product Owner). If you learn that your employee is demonstrating work software during the sprint review, then you can quietly listen in to see what the employee built and how it works. Before you do this, contact the Product Owner and ScrumMaster to verify that you may quietly attend the meeting. If you do so, ensure you tell your employee that you may be sitting in on the End-of-Sprint Review for transparency.

You may notice that I emphasize “quietly” a couple of times. The key is that the Agile practices that I am talking about are not meant for the manager per se but for the purposes of building customer value and making progress through the project. The Daily Stand-up is specifically meant for the team members to communicate to each other on their progress. The End-of-Sprint Review is meant to gain valuable customer and Product Owner feedback so that we can ensure we are building the right product for our customers.

Next let us discuss other opportunities to gain employee insight  I suggest using 1:1s with employees to collaboratively discuss challenges, progress and learning needs but evolving it to become a continuous performance review.  These should be a low-key sessions that replaces the "big-bang" performance review.  During the continuous 1:1s, there should be an effort from both management and employee to be transparent and this should avoid any surprises when ratings or compensation matters are discussed. Ultimately, I would like to see the performance review process move away from the stogy and often negative intrustive event and evolve into a continous and collaborative discussion on progress and employee needs.  

What do you think of these ideas? Are there other ideas you have seen work successfully where a reporting manager can gain first-hand insight into their direct reports without obstructing the progress of an Agile project or the employee themselves?

Robust Agile Organization - Core Roles and Beyond!

To establish to a fully robust Agile enterprise, it is important for everyone to play a role in Agile. I have found that being successful from an Agile perspective requires "core" roles and but must include the "across the enterprise" roles to ensure success.  Let's focus on each of these areas.

Core   

The core roles provide the nucleus for building customer value.  This starts with the Development Team. I prefer to use the term Agile Team (or something similar) since I want to ensure folks understand that it is not just development-centric but includes other key cross-functional roles and disciplines.  This cross-functional team is made up of around 7-9 members who can architect, design, develop, build, technically write, and test. This is commonly made up of developers (who can architect, design, and code, but preferably some who can do all three), QA/testers (who can build and execute tests), UX, DB, tech writers, and CM/build talent. The key is to ensure you have all of the roles you need to build an idea with sufficient skills to get the job done. You may also need a Product Architect which is a role that may not be considered full-time because they can support more than one team related to an idea.  However, it should be committed to the team(s).  This person ensures that the architectural related decisions are established and discussed with the team.

The servant leader for the team is the Scrum Master. The Scrum Master educates the team on Agile processes and practices, and helps them apply those practices. The Scrum Master takes the responsibility of a team coach ensuring the team stays true to the Agile values and principles as articulated in the Agile Manifesto including applying self-organization around the work. The Scrum Master helps the Agile Team and Product Owner remove roadblocks. This role also facilitates the Sprint Planning session, Daily Stand-ups, Retrospectives, and the Agile Release Planning session. Learn more about the Scrum Master in the Who makes the Best Scrum Master article.

Equally important is the role of Product Owner (PO), the driver of customer value. This Agile role should be played by someone within each product team that is customer facing to ensure everyone understands customer needs. This is often played by the Product Manager, Business Analyst, or someone who provides the business perspective and engages with customers to ensure the Agile Team is building something that is of value to the customer. Identifying the right customers for validation is the job of the Product Owner. To scale this PO role, the lead PO may introduce Product Owner Proxies (POP) who may be architectures, lead developers, or functional managers (the latter role may now have much less to do). The POP takes direction from the lead PO via the Product Owner Scrum of Scrum sessions to ensure all POs and POPs are on the same page. Then it is important to bring the customer into the picture to validate that what the team is building is something that the customer actually wants.  Learn more about the PO in the Who makes the Best PO article.

The final core role that is often forgotten in many Agile environments is the Customer.  The customer is core to determining what is value.  With the customer, you are not really enacting Agile. The customer is where many of the ideas of value come from.  The customer provides the valuable feedback along the way that validates (or adapts) what is considered value.  The customer may be in the form of multiple personas depending on their motivations and pain points. 

Across the Enterprise (aka, Beyond) 

If this is your first foray into the Agile space or you want advance in your state of Agile, it is important to have an Agile Coach who possesses deep Agile deployment knowledge to ensure teams are implementing Agile effectively. It has been established that training will only provide initial knowledge but team members can easily revert back to old traditional habits. The Agile Coach understands both the short-term and long-term pitfalls of adopting Agile, that Agile is a culture shift and will take time, and can help the team move to Agile is a more effective and efficient manner.

We then turn to management. Middle Management must play their role where they gently back away from command-and-control and act more as servant-leaders where they trust their teams, help them remove roadblocks, and support the Agile practices. They must realize that their direct reports are now on Agile Teams so they cannot be assigned any additional work. They may attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality) vs. getting a status report. Often times middle management have less to do in an Agile world and may consider changing their roles to either more of a Resource Management or Product Owner Proxy.  Learn more about Agile and middle management by visiting the Agile and Middle Management article.

Executives/Senior Management needs to play a leadership role as Agile champion. They must support Agile and understand that its primary intent is to build customer value which can ultimately mean more revenue for the company. They must also understand that they must get the Agile teams to feel ownership of their work and this requires leadership and not command-and-control style managers. They may need to adjust their staff if it already laden with too much command-and-control. They may also attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality).  Learn more about Agile and the Executive role by visiting the Agile Executives Playbook article.

Then we bring in roles like Sales and Marketing, Finance, and HR. These roles should adapt toward the same concepts of agile leadership, self-organizing teams, collaboration, streamlining and eliminating waste. Sales and Marketing are involved with bringing a product to market. They need to help the Product Owner with requirements input and clarification to ensure we are building something the customer needs. They need to understand that the Product Backlog and Release Goals are owned by the Product Owner, they must funnel requirements to the Product Owner, and avoid making commitments without the Product Owner in agreement.

Finance needs to be flexible in understanding that they can still manage to cost because it is the scope that is the important variable.  Finance and Portfolio should adapt to a continuous budgeting approach where ideas are continuously added to an enterprise kanban prioritized by value instead of fixing the work at the beginning of an annual budgeting process. You can learn more in the book Beyond Budgeting. 

If performance objectives are part of the organizational processes, then it is important for HR to establish a performance process that allows for team goals. This is because as part of the Agile mindset, it is important to establish that it is the team’s responsibility to ensure the release is a success and not specific to individuals.  HR can also help the enterprise move from an annual performance review to continuous review and feedback. Learn more about this in the Agile is creating a new horizon for HR article. 

If an idea or product is made up of more than one Agile Team (e.g., for a team of twenty you would want to break them into three teams of around 7), then there may be a need for an Agile Project Manager (APM) to help manage the dependencies and risks across teams, remove roadblocks, and ensure they work in a concert.  They may support a Scrum of Scrums (SoS) or similar.  The APM also handles the interaction with the business governance of the organization.  If your organization is large, you will need an Agile Portfolio Management Leader or team.  This leader focuses on providing visibility to the highest value work so that the organization (and teams therein) are building the highest value work to the customer.

Ultimately everyone within the organization should be focused on understanding and delivering customer value every step of the way. Getting to that value oriented mindset is critical to the success of Agile. It takes teamwork to get there and that team is the entire organization.

----------------------------------------------------------------

You can see a presentation that covers many of these roles at: http://www.boston-spin.org/slides/boston_spin_slides_2010_09.pdf