Engineers have long had a poor relationship with managers. There are the stories long told of engineers unconstrained by management executing high stakes skunkworks projects, or more modestly using guerilla tactics to sneak unauthorized features into products that delight users. There are popular caricatures such as the pointy-haired manager in Dilbert, or Ford Motor’s management as portrayed in the movie Ford v Ferrari. Historically, management has never been loved, and in fact is often loathed, by engineers.
This all seems different in Agile. Management appears to be well integrated in Agile teams, not an overhead, nuisance, or encumbrance as it is in traditional project management. If we accept the fact that Agile is a value system and not a set of mechanical processes, it stands to reason that there must be something different about the norms and behaviors of Agile managers vis-a-vis traditional managers. What is it that makes Agile management different from traditional management?
A good place to start is by looking at the fundamentals of Agile team dynamics. First and foremost, as Paul Hammant is fond of saying, there are no passengers in an Agile team.
An Agile story is an expression of end-to-end business need. Although completing a story may require contribution from people in different roles - QA analyst and developer and experience designer, for example - each person is still responsible for the entire outcome of the story. Each person is responsible for the outcome because team performance is measured on collective output (specifically, stories in production) as opposed to the sum of individual output (tasks completed by individuals). Every member creates the most comprehensive understanding they can of each story, which they express both through artifact (story narrative or code for example) and collaboration with other team members (story walkthroughs and desk checks). A person driving goals orthogonal to the team goal, or not driving at all, does not last for very long in an Agile team.
A less charitable corollary to Paul’s statement is that nobody can hide in an agile team. What every person does and how they do it is fully exposed to every other member of the team. This is why safety is a key characteristic of an Agile team: by making it safe for any person to admit they don’t know how to do something, it is easier for the team to collectively adapt and make the most of the strengths of the people it has. It does mean, however, that mismatches - people who overstate their skills and competencies - will be exposed very quickly.
Combined, this means that no individual can phone it in. One person who does a substandard job affects the performance of the entire team. Consider a team using story narratives to surface complexities in business requirements. A business analyst who consistently does a lackadaisical job will effectively export the analyst responsibilities to a developer. Developer productivity - and therefore story card throughput - will suffer as developers compensate for substandard analysis work.
The obvious conclusions are (a) every individual drives to the collective output of the team; (b) every individual must strive to perform a high state of excellence; and (c) a team cannot maintain a level of performance any higher than the level of excellence achieved by its weakest performing member.
For people working in roles directly related to creation and evolution of a software asset - experience designers, developers, QA analysts - this is easy to understand. We all understand the consequences to an Agile team trying to compensate for inadequate design artifacts, vague requirements, poor quality code, and ineffective tests: rework cycles, additional handoffs, and poor quality, among other things.
But what do these three things - drive, excellence, and minimum collective effectiveness - mean for people in management roles?
I was fortunate to have worked with very strong Project Managers in my early Agile projects, people who understood the Agile value system and knew how to apply it as managers in a delivery team context. They all had characteristics that are applicable to all management roles. Among them:
Managers advance the understanding of the problem / opportunity / solution domain. The best Agile managers are outstanding at scope definition and scope control. They do this by intelligently questioning different people in the team: business partners to ascertain what is truly important to the near-term business goals and is not, developers to ascertain what is tech goldplating and what is not, product managers on how can a story be split and part of it deprioritized, and so forth. It’s worth noting that codified accounting standards treat managers as overheads, for the simple reason that management is largely administrative work. By demonstrably working the details, some portion of an Agile manager's time is spent genuinely advancing the understanding of the problem/solution domain as part of a team collective. For this reason, a portion of an Agile project manager’s time can be capitalized, unlike traditional project managers who are purely expense. Traditional PMs create project plans, staffing plans and reports, schedule meetings and facilitate ceremonies. All useful, but not directly contributory to the technology asset itself. The difference is that the Agile project manager is hands-on with the problem and not simply performing tasks of administrative convenience - contracts, meetings, project plans - on the periphery of those hands on with the problem.
It’s worth pointing out that this doesn’t happen by accident. Previous experience in a do-er role such as business analyst or developer certainly helps the manager to know the types of questions that need to be asked. But the key characteristic is both the ability and willingness to immerse and comprehend the details of the stories, the architecture, the code, the design, the tests. Good managers know how to work the problem and solution space. This applies to all levels of management, because “ground truths” always triumph over abstractions, right up to CEO and activist investor. Conversely, the manager who lacks the will or skill to internalize a domain is completely beholden to (and subsequently held hostage or simply played by) those in the team who do. This manager is the textbook definition of “overhead.”
A symbiotic relationship with the do-ers in the team. PMs have to provide a variety of status reports to various sponsors and buyers. In the early days of Agile development, there were all kinds of new and novel measures: velocity for measuring throughput of stories, load factor for assessing the actual capacity available to the team, story points (or equivalent) for measuring relative story sizes, and many more. It was easy - and very satisfying - to nerd out on the management metrics, creating forecasts of scope expansion and capacity and so forth. But one thing that distinguishes the Agile manager from the traditional manager is that the team drives the metrics. The metrics are only very rarely used to drive the team. The Agile manager uses the metrics to detect a change in the situation such as domain complexity that was not previously understood, or team member skill that was over- or under-stated. Project management metrics are used by managers to ask “what has changed”, not “why are we off plan”. The objective of the Agile metrics has never been to keep the team on a plan and held to a plan. The objective of the Agile metrics is to increase the understanding of how execution is unfolding and make the necessary adjustments in one of the four variables - time, scope, capacity or quality - to respond. That’s a big difference between traditional project management and Agile project management.
Metrics being all the rage among the management class these days, this bears a bit of analysis. Of course there are instances where metrics are used to drive the team, such as when three of the project management variables - time, scope and quality - require compensation from the fourth - capacity. By way of example, when the number of sev 2 and 3 defects escaping to production rises a bit - not unsustainable or threatening, just something that stands out - while the team focus is still on new story development, it isn’t uncommon to ask everybody in the team to try to resolve one defect every day before finishing up. True, in this case a rise in defects exposes something about how execution is unfolding, and the team needs to adapt (put in a little additional time to address quality). But in practice, this is an instance where the metrics are used to drive the team (e.g., to maintain story velocity while paying down defects), if for no other reason than the optics of few defects to go along with story throughput puts stakeholder minds at ease.
The same nuance applies to measuring story throughput. A release plan that slots specific stories for specific future iterations sounds like a fixed delivery plan, but when scope and time are the priorities this is a reasonable exercise. It helps to answer the “will the team make it“ question, and as long as capacity and quality variables can be relaxed it is a way of depicting scenarios and anticipating responses. However, when stories are slotted to future iterations and all 4 variables are held constant by the manager, we no longer have Agile project management, we have traditional project management that has co-opted Agile terms in the pursuit of control. Obviously, this is not Agile.
The four variables combined with appropriate interpretation and application of the metrics enable the manager to have a symbiotic relationship with executors. This manager is an Agile manager. However, when the metrics themselves are used as drivers, management has a one-way relationship with do-ers. This manager is a tyrant.
Create and adapt the mechanical processes and social systems through which the team gets things done. Roy Sigham, the founder of ThoughtWorks, used to refer to the company as a “social experiment.” All teams are social experiments, random strangers brought together in combinations of varying skills, capabilities and personalities. There will be tension and conflict. There will be misrepresentations and misunderstandings. There will be volatility.
Traditional project managers reach for plans against which they can hold people accountable. But this is not how managers fulfill their primary duty of “getting things done through people.” A high EQ allows a manager to recognize how people interact with one another. Professional experience allows the manager to recognize the skills people have and aspire to have and will never have. These and other factors let the manager create the circumstances for the right type of interactions and format - workshop, fishbowl, small group exercise, etc. - for the right subject in the right sequence at the right time to enable the team to get things done. Among other things, this takes listening and observation skills, the ability to design the mechanics and visualize how various activities will go, plus the ability to prioritize, facilitate, coach and intervene. This is management. This is how managers “get things done through people.” People who manage a plan are curators of documentation, not managers of a team of people.
Protect the execution of the team. Creating a functional team is one thing. Protecting the team’s execution is entirely another. There are constant challenges to the integrity of the workings of a team. People ghosted to work on multiple teams (a “10% allocation” of a person’s time to a team is utterly meaningless). Stakeholders with differing and highly volatile priorities. Fear - or just tepid commitment - to an Agile way of working. Corporate politics. Low trust corporate cultures. The Agile manager manages upwards and outwards, keeping these threats and many others at bay, preventing them from invading the team.
There are times when external forces must invade the team, such as changing stakeholder priorities. The Agile manager creates a constructive framework and mechanical process for the team to ingest and respond to things that cannot be deflected without creating chaos with how the do-ers are otherwise do-ing. The manager who does not protect the execution of the team from external drama is a puppet to any and all external stakeholder.
I wrote above that each person in an Agile team drives to the team outcome; that each person must strive to achieve excellence; and that the team will move only as effectively as their weakest performing member. We’ll look at patterns and antipatterns of management behavior in the next post.
