Chapter 2: Add value as an Agile team leader
To help your team succeed, your Agile Team Leader (ATL) role borrows heavily from the ScrumMaster role, traditional project management, and pragmatic management and leadership. You undertake a wide variety of activities and responsibilities, which seems to be asking a great deal from a single person. In true Agile spirit, though, context is everything. Customizing your role to fit the actual needs of the real live team in your very real organization is far more important than sticking to a formal role description.
2.1 Who is responsible for value delivery?
Several times a year, I give talks about the Agile mind-set and the human side of Agile. A question I like to ask is, “Who is responsible for value delivery in Agile?”
Many people in the audience are used to the traditional organizational model, the hierarchy (“command and control”), which gives rise to a certain power structure. On the bottom are line workers or “individual contributors,” who are supposed to spend their time performing their duties and specialties. They have limited access to information and possess no formal authority.
Line workers report to managers, who report to their own managers. Managers have the authority and responsibility to decide who will do what when. They design the work and its environment. They are privy to more information than individual contributors. To varying extents, the same is true for project managers. In matrix organizations, individual contributors answer to people managers as well as to project managers.
In the command-and-control structure, managers are under the gun to deliver results. If something goes wrong with a project, managers can take “corrective action”: add or shift people, mandate overtime, and the like. Delivery responsibility lies with managers.
Others in my typical audience are actively using Agile frameworks, wherein teams are empowered to make most of the decisions that affect them and their work product. By self-organizing, communicating openly, and taking a value perspective (as opposed to a task perspective), they are supposed to produce more meaningful results. Therefore, managers and project managers are actively discouraged from telling an Agile team what to do and how to do it. The Agile team’s experience sometimes resembles that of the cars in this picture :
Team members are like the car drivers: They know the rules of the road, they can operate their cars, and they communicate their intentions to other drivers. The drivers self-organize to share the road and reach their separate destinations without colliding. Notice the two police officers at the top? They could be the managers. From where they stand, they can mostly influence drivers into compliance, and maybe call an ambulance if an accident happens. (In newly Agile environments, managers are in an even tougher spot, because sometimes their teams know the rules better than they do!)
When I ask, “Who is responsible for value delivery in Agile?” one common answer is “the project manager.” Sorry, no.
Another common answer is “the product owner.” Not quite; the product owner is responsible for choosing and defining the value to build, but she can’t cause any of it to be developed or delivered.
Other answers include “the ScrumMaster” and “the development manager.” At this point I say, “Whether you are the project manager, the ScrumMaster, the manager, or the team leader, you personally are not on the hook to deliver. After all, you don’t tell the team what to do.”
After a pause for dramatic effect, I continue: “The team is responsible for delivering value, and your responsibility is to facilitate their commitments.”
At this point, someone in the audience will shift nervously or give me a “yeah, right” look. The reality of many Agile practitioners continues to be the opposite of my description. They may have a few Agile teams, but the managerial hierarchy still hands down responsibility, and the chain of delegation stops at the project or functional manager.
If your organization thinks you are solely responsible for value delivery, it is not implementing Agile properly.
But what if the team is unable to deliver? What if they are understaffed, or their technical skills are unsuitable for the job? In a proper Agile environment, the team would clearly communicate their abilities, apply themselves as best they can, and consistently improve over time. If they can’t possibly accomplish what’s expected of them, you help them renegotiate commitments, escalate the issue, or seek management’s support.
In the old structure, you communicated to the team what the organization wanted them to do. Communication went mostly downward and through you. By contrast, in an Agile environment, you also communicate to the organization what the team needs from it. Communication is now mostly upward. You no longer serve just the organization; you mostly serve the team.