Implementing Agile and Scrum at scale in an enterprise setting is not easy. Scrum does not recognize titles for a functional manager or a project manager for any of the four roles on a Scrum team, yet those titles are very common in enterprise settings. Where do these managers fit in?
The first thing to recognize is that this rarely means the organization should start jettisoning these people in a knee-jerk reaction. These individuals rose to those ranks because they possess one or more of the following qualities:
- Intense knowledge about the workings of the organization. They know how to get things done.
- Intense knowledge about what the products do for the organization. They know how the work products of an organization create business value for the company, and why.
- Intense knowledge about how the products get built. They know how to make the products that the organization needs.
However, they face two real issues:
- In Scrum, it is not beneficial to have team members matrixed across many teams at once. It is better to foster an environment where team members can focus on getting to working on software, not merely moving the documentation about what the software will be or how software will be done when there is time.
- Because the positions of project and functional managers were designed to engineer the matrixing of team members at an organizational level, those positions are now at cross-purposes to what we want to achieve with an Agile adoption using Scrum.
So, looking at the roles on a Scrum team, the only "pig" roles to fill are product owner, Scrum master or delivery team member. Unfortunately, there isn't a simple checklist to follow that tells you which of the new roles your old managers fit into. But it is helpful to review why matrixing is evil from the Scrum point of view and figurw out what to look for in the roles for the Scrum teams.
Why Scrum teams consider a matrixed organization evil
Back in the 1980s, the Partnership for a Drug-Free America had a very popular public service announcement. The entire script, voiced over the image of an egg being fried in a pan, was: "This is drugs. This is your brain on drugs. Any questions?" Too many software development organizations in the same era got hooked on another sort of addiction. They got hooked on matrixing their organizations. It all started with a 12-page article from Jay Galbraith called "Matrix Organization Designs: How to Combine Functional and Project Forms," published in the February 1971 edition of Business Horizons.
Faced with shrinking budgets and expanding workloads, organizations became enamored with the simple solution that the matrix provided. They managed their "doers" into functional silos (database administrators, developers, business analysts, etc.) that reported to functional managers. Then they selected resources from the various silos, placing them on "teams" on a project basis; these teams reported to project managers. These organizations thought they would gain efficiency by only employing the appropriate amount of the required matrixed resources to get the project done.
However, in Scrum, this approach does not work because of the following reasons:
- The team doesn't know the complete requirements of a project before starting or who needs to be involved to get the work done. That's why Agile uses an adaptive process.
- The amount of time spent performing task switching between projects can drive out all of the cycles needed to actually get work done.
On a humorous note, even mild task switching (just performing one's normal work while checking incoming email and answering phone calls), has been shown to reduce a worker's IQ by more than twice that from smoking marijuana. Imagine what your brain would look like on five projects at once!
What Scrum requires from its "pig" roles
Instead of giving you a simple-to-use (but impossible to construct) checklist of matrix titles for Scrum roles, let's first review what the Scrum roles are and then discuss how to apply this to your organization.
- Determine "what, when and why" for every detail of a product.
- Negotiate with the team on these details when faced with estimates of cost and risk.
- Empowered by the organization to make decisions on what and when
- Capable of making those decisions in a way that is compatible with team dynamics
- Negotiate with the team on these details when faced with estimates of cost and risk
- More or less constantly available to the team to answer questions and make decisions
- A great communicator, always able to explain, "Why now?"
- A leader that people want to follow
Delivery team member
- Determine "who and how" for every detail of the realization of the product.
- Negotiate with the product owner on these details when faced with estimates of value and risk.
- Generalized specialist -- really great at some things but willing to stretch sometimes to do whatever it takes
- Comfortable with ambiguity -- can keep making progress even if requirements will change
- Willing to play well with others -- lone wolves with large egos need not apply.
- Be the servant leader that the team needs -- not the overlord manager that will kill delivery team cohesion.
- Do whatever it takes to make things happen -- including all the dirty administrative jobs that the team needs done.
- Coach the team and the organization in how to continually improve the use of Agile.
Now that the roles are better defined, let's see what happens when you apply individuals in your organization that used to have the titles of functional manager and project manager:
- Many role alignments are easy. Project managers that are very product- and business-savvy will easily transition into product owners. Of course, to be effective they may need some delegation of authority from the product side of the house.
- Other role alignments are less clear. Can a project manager become an effective Scrum master? Possibly, but they may have to lose the "I'm in charge here" attitude or the "Here's your next thing to do" style of interacting with the team.
- Other role alignments may be difficult because of the culture. For example, if your organization has pressured great technical people to become managers (most probably functional managers), the right role for these people may be on the delivery teams. But if years of technical idleness have dulled the technical savvy of an individual, the painful reality may be that this person no longer has the value for the organization that they once held. Even if they do fit in, the perception of lowered esteem in the new assignment may not be something that the person is comfortable with.
In any enterprise setting, there will always be a need to administratively manage the members that formed the functional silos that you probably had functional managers fill. In small settings, these are normally handled by competent Scrum masters who just do what's necessary. But in larger organizations, corporate concerns may require special security, risk or compliance training based on functional role. Also, simple things like salary reviews and career counseling may well be different for people filling different functional roles.
You may find it necessary to maintain functional managers for people to report to. But these functional managers will probably be able to manage far larger groups of individuals since we no longer require them to handle the activities that are currently handled by the rest of the Scrum teams that are now operating.
Having your teams focus on getting work done in a manner consistent with what portfolio management tells you needs to be done, and when, is a difficult thing to do when employing Agile at scale. But consistent with the Agile values of openness, transparency and truth, we need to throw away those convenient lies that used to tell us about how matrixing our organization was all that we needed to do. Figuring out how to apply the talent that you already have on board by using them in the right Scrum roles is the way to start achieving the high performance that you and your organization need.