The use of Adaptor in organizational transformation
Project management is done differently in Scrum
Project management work still exists when adopting Scrum. Traditionally, project manager plays key role for project management work, and it is done in a centralized manner. While in Scrum, project management work is done in a distributed manner, split among Scrum roles - PO, team and Scrum Master. What if project manager role still remains in the same context, in the meantime of introducing Scrum roles? Conflict and confusion ensue. When project manager wants to do his/her job, it impedes Scrum roles from functioning. Surprisingly, it's not uncommon to see that project manager (probably in a different name) and Scrum roles co-exist in the same organizational context. That must be addressed, in order for a successful Scrum implementation.
"Distributed project management" exercise is an effective way to help understand Scrum roles and see the problems. To do this, you will gather all relevant people together. The exercise works roughly as below. First, people come up with the project management tasks, assuming that all of them will still be needed after adopting Scrum. Second, people need to learn carefully about Scrum roles, e.g. from Scrum books, articles or any Scrum training material. Then, we look at each task to see whose responsibility it is in Scrum. When different parts of the task go to different roles, we split the task into parts, so that each task is taken by only one role. In the end, we discover that project management is well distributed among Scrum roles, without the role of project manager. The problem by having both Scrum roles and project manager in the same context becomes obvious.
Introduce adaptor
Now that the problem becomes visible, the next question is, how shall we transform? Suppose that you are working in a big organization with multiple teams, it's likely that you are not able to transform the whole organization at once. The situation you face is that the part, probably the big part, of the organization runs in old mode based on program and project structure. Program manager interfaces with project manager. Project manager sets up the project team (often a working group with only project manager being accountable for the overall project results). If we introduce one Scrum team with PO, Scrum Master and Team, how does it interface with the rest of the organization?
From Wikipedia, Adaptor is defined as a person that adapts attributes of one system to those of an otherwise incompatible system. Applying it onto this situation, we can implement an adaptor towards the rest of the organization, without causing any incompatibility in interface.
Who can be the adaptor?
- Product Owner
Product Owner is responsible for the release content, schedule and cost. In this regard, if PO plays the adaptor, he/she interfaces well with some counterparts, e.g. program manager. However, others may expect adaptor to be exactly the same as project manager. The expected level of control is often lower than the level, at which Product Owner is working. Product Owner sees Product Backlog Items, rather than Tasks; Teams, rather than Individuals; Sprints, rather than Days. While traditional project manager may manage at the level of Tasks, Individuals, and Days. There is an inherent conflict between doing the job as Product Owner and working as an adaptor. Moreover, being a Product Owner solely is already a demanding job. The adaptor role will most likely distract his main focus, thus, an impediment preventing him from well performing.
The variant is to transform the existing project manager to PO role. Besides the same drawback, it gives the perception for the rest of the organization that nothing changes. While this is exactly the purpose of having adaptor, if project manager thinks of this way, and he/she remains as project manager in the name of PO, the change is doomed.
- Scrum Master
One of Scrum Master's responsibilities is to ensure the supportive environment for Scrum implementation. If we see the purpose of adaptor as creating room for Scrum team within the large context to succeed, it fits Scrum Master's job well. I was the Scrum Master while implementing Scrum in the pilot project within my former company, and kind of played the adaptor to interface different parties in the rest of the organization. The advantage was for me to have the opportunity of influencing them and moving the change forward. Remember, Scrum Master is supposed to be a change agent. However, the rest of the organization often expected me to report status and make decision as other project managers. Anyway, that's what adaptor means. This creates a couple of major problems. For release management, since PO is not visible to the rest of the organization, while he/she is the person having the knowledge and authority to inspect and adapt, having the adaptor different than PO slows down information flow and decision making. It also creates the big misunderstanding about Scrum Master role close to project manager.
The variant is to transform the existing project manager to SM role. Believe it or not, among the three Scrum roles, Scrum Master gets the least part of project management responsibility. I like the comment given by a project manager who attended my CSM course, "only atypical project manager may transform into SM".
- One team member
How about having one team member as adaptor? Team is responsible for committing and delivering potentially shippable product increment every sprint. Being adaptor is certainly a distraction. Furthermore, the role division between PO and team gets confused. The information flow between PO and team gets awkward. One argument for this is that great team shall be able to define itself in the organizational context. I would say that this goes beyond what's expected for team in Scrum framework towards more self-designing team [1]. Regardless, for a newly formed team, the clarity in roles is very important, thus, at least the timing is bad.
- One person outside Scrum context
The former project manager acting as adaptor, without taking any Scrum role, is another option. However, for any capable project manager, he/she would either try to have the same influence as early, which creates conflict and dysfunction, or step away from this soon after he/she realizes that adaptor role does not add much real value. It could also be that other body being adaptor. This will not be a rewarding role anyway, unless people seek the title of "project manager". It ends with a waste of human resource. Program manager is a good choice. It is actually closer to no adaptor that i'm going to describe as following.
How about no adaptor?
No adaptor means to expose Scrum roles for the rest of the organization. Here are a few steps I suggest to do.
- list all parties, with which project manager has interface
- list tasks each party is concerned
- bind Scrum role and the tasks to create new interface
- discuss and agree with each party about new interface
The last step is most critical, since it creates both understanding and action. There will be change for the counterparts, in terms of the number of interfaces, the content, etc. If they are not familiar with Scrum, a brief introduction should be included into the discussion. Though it takes more time to define, agree and get started, this has a few advantages. It doesn't introduce overhead. It creates solid understanding for new roles and prepares better for the further change. It's closer to our ultimate goal of transforming the whole organization. Scrum Master should lead the efforts to define and agree on the interface change with all relevant parties, since it fits the change agent role well.
This is actually my preference. Try no adaptor, before considering to introduce adaptor.
Adaptor towards which part of the organization?
So far, we have explored about using (or not using) adaptor to make Scrum team compatible within traditional organization. In fact, another chance of using adaptor is to make traditional team structure compatible within Scrum organization. In our vision, big product development organization will be organized into requirement areas, each of which has Area Product Owner being responsible, meanwhile, Area Product Owner is the member of the whole product PO team [2]. Since organizational transformation does not happen overnight, chances are, some part of the organization runs in Scrum mode, while the other part remains in traditional mode. In this case, an adaptor in the name of Area Product Owner is useful technique to keep the whole organization operating in Scrum mode. In fact, the adaptor goes beyond the person and includes sprint and backlog interfaces. Later, we gradually refactor to our vision.
Reference:
- Richard Hackman, Leading teams: setting the stage for great performance
- Craig Larman, Bas Vodde, Scaling lean & agile development: thinking and organizational tools for large-scale Scrum
