Agile transformation success stories are not as common as you would expect considering the promise Agile approaches hold. Yet, in my experience in working with many organizations, I have been amazed by how much more they could have achieved if only the various roles involved in the transformation were understood and implemented the way they were intended to be.
One of my previous blogs highlighted the role of a Scrum Master in an Agile environment and where the role is headed (http://pm-powerconsulting.com/blog/role-scrum-master-headed/). Management’s role as an enabler was briefly highlighted there. It is a difficult transition for managers from what they have been used to doing all along, but without that transition, success with Agile, in my opinion, will be extremely limited. Let me elaborate a little bit more.
First a bit of context – most organizations have separate dev and QA set-ups and have functional managers running each of those groups for different Business Units (BUs). Some have a central QA set-up while some mature agile organizations have combined dev and QA set-ups under one unit with multiple managers handling different areas or components under one BU. They are typically called functional managers because delivery is handled by Scrum teams with different levels of Scrums (Scrums, Scrum of Scrums and so on) and there is a release management team coordinating the delivery efforts working directly with Product Management and customers as the case may be for delivery. Many organizations implementing Agile get into a challenge by making functional managers also responsible for delivery, often making it difficult to implement the true spirit of Agile.
Most organizations are confused about the real role of a Scrum Master (SM) and often make a transition to a dedicated or a focused SM role half-heartedly. They allow the SM to run the Scrum ceremonies and work with the team to resolve basic issues that they may have. The functional Manager is made accountable for delivery and the SM is made to report to the functional manager. While they may have implemented the letter of Agile/Scrum by having an assigned SM and ensuring the ceremonies are run as per defined guidelines, the person in the background controlling things ends up being the functional manager since he/she is made accountable for delivery. So while the manager is not expected to attend most of the ceremonies – such as the daily stand-ups, planning and retrospectives – they invariably end up attending many of them to ensure they know what is going on and apply corrective actions as and when they deem appropriate. All this ends up undermining the role of the Scrum Master and the team, and any talk of self-managed teams goes out of the window.
The problem with the above situation is the clear lack of separation of responsibilities between the SM and the functional Manager roles. In Agile/Scrum, the SM and the team are the roles that are clearly responsible for delivery and they are accountable for this to the direct customer/product management, and where there are multiple teams delivering a single product, all teams work with a release management team coordinating and working with the customer directly. The manager has an enabling role in this process and needs to ensure he does everything to support the team in their execution for delivery. This could include technical support (in terms of reviews, inputs and so on), mentoring individual team members, providing support to them for needed competencies/skills to do an effective job and so on. The managers are also responsible for the team members’ performance planning and evaluation and for ensuring that the team members stay motivated. They help the team with the product roadmap by working with the concerned Product Management (Product Owner(s)). They will be involved in medium-term to long-term planning processes to drive the technical product direction and roadmap. The only scrum ceremony that they typically attend is the sprint review/demo where the product increment developed during a sprint is demo’ed to the users. The feedback from this session is important for them to enable and support the team better in their delivery.
This brings us to two very pertinent questions – what is the difference between enabling delivery and being accountable for delivery? Who is accountable for delivery if the functional manager is just an enabler?
Being accountable for delivery essentially means team members holding each other accountable for commitments made amongst themselves as well as to the external customer/product owner as the case may be. This also involves active working by the SM on a day to day basis with the team on issues that they face. When the functional manager is accountable for delivery and is also the team’s people manager, every team member looks up to the manager for all instructions on a day-to-day basis. A self-managed team as a concept becomes very difficult to accomplish. Often the managers get into a command and control mode once they are made accountable. On the other hand, an enabling role is supportive. If the team needs help with code reviews or design reviews or assistance with test strategy, the managers should be able to step in and help them. If the team has technical dependencies with other teams the manager can help resolve some of them. If one of the team members has issues with specific skills, the manager needs to provide appropriate support or replace the person with a more suitable person. In essence, the functional manager should not disown delivery but play an active supporting role in ensuring the team succeeds. And this, he/she needs to do without stepping on the shoes of the Scrum Master, whose role it is to coordinate delivery and resolve the day-to-day bottlenecks of the team. And in this process, the SM and the team clearly are accountable and answerable for the delivery. The role of the SM is indeed very influential as we saw on the blog we referred to earlier.
Which brings us to one final question that I have personally found an important one to address – who does the SM report to? There will be some conflict of interest if he/she reports to the functional manager that the rest of the team reports to. The SM needs an independent line or an escalation path to ensure the interest of delivery is not compromised in any way. One of the recommendations is to have all SMs report into a delivery organization head or the BU head whichever is more appropriate. The need for a separate delivery structure and organization that is primarily focused and accountable for delivery is desirable and will be the subject of a future blog.
I must say that this model is not an easy model to transition to for most organizations moving into Scrum from waterfall but my own personal view is that it is necessary if the full benefits of Agile and Scrum are to be achieved.
In our experience as coaches, we have seen this model will work if implemented in spirit. It takes time – sometimes 1 to 2 years to get the full benefits but if done right, it is a sustainable model and one that will not only increase productivity but enable the organization to scale more easily in the future.
Do write to us about your own experiences – it would be a great learning for all of us!!