A Manager's Role in an Agile World

Executives get coached to be nimbler within an ever-changing strategic landscape. Teams get coached by Scrum Masters and Agile Coaches on how to become more transparent, inspect and adapt on a routine cadence. But what about everyone in between; what does management look like for you?

This is where we figure out how to make the proverbial sausage. Senior leaders are driving the vision and strategic direction of the organizations. "ACME needs to be here in the next 2-3 years, and here are the great things we're going to do to get there."

It is up to the directors, senior managers, and managers to figure out how to make that vision a reality. But wait! Your teams are self-organizing, working directly with the product owner to determine what each of the things mean in the backlog, and when they're going to be able to get it done. "What do I do?"

The manager's role in an Agile world is to make efficiency and productivity a reality. Maximizing the teams' ability to deliver value. Agile managers do this by anticipating what their teams are going to need. In order to do this effectively, an Agile manager needs to:

• Manage teams within an Agile enterprise
• Manage through metrics and reporting
• Manage partners and suppliers
• Manage organizational change

Manage Teams within an Agile Enterprise

Management is an activity, while a manager is a role. The activity of management will always exist, but should adapt to continue performing what was originally expected. The concept of management has always been vertical, to align with the function area of the team members, (i.e., Development, Quality Assurance, Finance, etc.); however, in an Agile enterprise, management should be horizontal.

Our teams are cross-functional. They include developers, QA, business analysts anyone necessary to get the work through the value stream. An organization that aligns its hierarchical structure to the horizontal nature of value streams will see a common understanding of success across the value stream. Sales, professional services, product marketing, product management, development, QA, and operations all have a shared set of goals for delivering the highest return to the customers within that value stream. You will start to see product management having the ability to construct roadmaps that have a high level of reliability based on needs being driven by sales and the customer, and aligned with the work that can actually be delivered from our Agile teams.

Manage through Metrics and Reporting

Regardless of which Agile-inspired framework your organization has put in place, there is discussion around what is true progress, and what mindset to use when thinking about metrics and reporting.

• The Scrum Framework and Large Scale Scrum (LeSS) are "founded on empirical process control theory, or empiricism."
• The Scaled Agile Framework's (SAFe) first principle is "Take an economic view."
• The Disciplined Agile Framework (DAD) "is based on empiricism."

As an Agile manager, we want to be able to use this empirical approach to understand how our teams are doing, where they need help, and where they are excelling.

Peter Drucker said, "You can't manage what you can't measure." This is core to understanding if you are actually delivering the most valuable products to the customer. Agile managers must understand what we should measure, and what we should not measure. They must also not confuse activity with accomplishment, and ensure that what is being measured has a target that drives the intended impact.

All too often, performance goals are created that align with measurements that do not actually provide the intended result. As an example, as a senior manager for a group of Scrum development teams, I was given an annual performance goal to increase the teams' velocities by 10%. While the intent of the goal was to drive increased productivity and efficiency with better training, better user stories, and more effective scrum events; the measurement for the goal was misdirected. The goal should have been focused on delivering 10% more value in each sprint, as velocity is only a metric used for planning and forecasting. It is not a performance metric. Surprisingly, the development team's story sizes got a little bigger...about 10%. They didn't really deliver more value, but they achieved the performance goal.

Manage Partners and Suppliers

Outsourcing is a common practice for providing flexibility to ramp up and ramp down capacity with relative ease. The need for this flexibility can also be driven by IT budgets or a lack of the appropriate skill sets available within the organization. If there is a specific need for a specialized skill set for a short duration, and permanently adding that skill to the organization doesn't make sense, then finding temporary talent is your best approach.

In any enterprise, the traditional statement of work which focuses on locking down the scope, time, and cost doesn't work. We don't know everything we need to know at the very beginning of a project, so how are we expected to be able to clearly identify what the totality of the scope is for these agreements?

Scope, time and cost are all related. If any one of these factors changes, then the other two have to adjust. An Agile statement of work, which focuses on two of these factors, cost and time, will ensure the adaptability needed to change as requirements emerge throughout the process.

A statement of work that identifies a specific cost per sprint for a dedicated development team, and the scope loosely defined but remains open to adaptation, provides the flexibility needed.

It does create risk in understanding what, or how much, work will get done. This is why creating statements of work that focus on deliverables across a few 2-4 week iterations is required. The Agile manager gets to see progress in small batches; creating smaller risk containers and better flexibility to adapt to what is actually being delivered.

Manage Organizational Change

During an Agile transformation, the first thing discussed is the need for the organization's culture to adapt to an Agile mindset, and very often, the last thing that actually changes is the culture. This should be expected as the culture of an organization is built on the habits it has formed based on past experience and both past and present leadership styles.

This drives the need to understand the principles of the targeted Agile framework and Agile manifesto. Without these principles, organizations will continue to drive conflict and disagreement with how to adapt their process and practices because they don't have a compass directing them to the best answer.

If we don't agree that "working software is the primary measure of progress", then we begin to create metrics that reinforce anti-patterns driving activities that may keep teams busy but don't actually reduce cycle time.

If we don't have "continuous attention to technical excellence", we continue to take shortcuts to deliver things based on artificial roadmaps and then spend more time developing features that must work within the inefficient work created before. It also means having to set more time aside to fix the shortcuts and poor practices than we are focusing on delivering value to the organization.

In order to move towards an Agile culture, the Agile manager must take a lean-agile mindset. This is a mindset that takes an economic view of all decisions, and weighs those decisions against the principles and if they help meet the principles.

The Agile manager is one of the most important roles within an Agile enterprise. This group of leaders are the ones who take a grand vision and strategy and translate that into something that can be executed and deliver value.

This is done by managing their teams with a lean-agile mindset, taking an economic view on decisions, ensuring partners and suppliers have Agile and flexible agreements, and leading the change utilizing the principles as a foundation.