I was recently working with a consulting client who was suffering from a productivity decline in her organization over the past year. My client, a VP of a software development organization, recently adopted Scrum as its Agile software development process. When I conducted interviews with key team members, a common complaint emerged: “Management is always ignoring the process!”
Most organizations follow some form of process, regardless of the domain. These processes range from lightweight (almost nonexistent) to the draconian. The amount of process varies wildly based on number of employees, clarity of roles and responsibilities, compliance requirements, degree of risk tolerance, and so on.
What’s interesting is that management are usually the ones beating the “follow the process” drum, not the staff. My client was different.
Why Agile is different
Since adopting Scrum and Agile practices, my client’s team has come to rely on the safety net the process offers over traditional methodologies. Controlled iterative development, empiricism, and autonomy have all contributed to higher quality software at a faster pace, with dramatically reduced defects. And then suddenly, this all started falling apart.
A new CEO joined the organization, and with him came new priorities, new customers, and a focus on new revenue. Management, strangely less empowered than the teams they manage, followed the leader.
The high velocity, high quality performance the team had been enjoying was disrupted by some unwelcome old symptoms from management. See if any of these situations resonate with you:
Out-of-band high-priority requests
One team member explained to me that their planned work (two weeks’ worth) had been hijacked to accommodate an executive’s pet project, with no explanation as to why this work was important to the organization. Management followed orders and pushed this work down the line.
When everything is a priority, then nothing is a priority
Scrum, the process adopted by my client’s team, employs a prioritized Product Backlog to plan upcoming work, and a Sprint Backlog to plan work in progress. The goal is to constantly deliver maximum value to the organization, while maintaining quality.
One manager began to nitpick certain subjective “spit and polish” issues, demanding the team to correct these while other prioritized work was already underway. If the process were followed, these changes would be welcomed by the team, and given the attention they deserved. Instead, the team was distracted by the curveball, and failed to complete a key feature on time due to the distraction.
Priority via intimidation
While sometimes overt, intimidation by management can often be subtle. Managers who try to act as part of the team, often effectively, sometimes leverage their position in the org chart to influence priorities. One team member, a Product Owner, shared with me that her manager, while acting as part of the team in most instances, sometimes reverted to subtle “bullying” to get a feature prioritized. The problem here is that the Product Owner directly reported to the manager, a clear indication that the organizational relationships didn’t support the level of empowerment and autonomy needed.
Lack of mission or purpose
Teams need a purpose in order to deliver effectively. Simply being told to “make widget X run faster” often isn’t sufficient to engage teams in a solution. Team members might ask “why I am working on this?” A better approach would be to frame the feature request in context: “We are losing $250,000 per year in productivity because widget X is slow.” Here, we can align the organizational objective with the technical solution.
How I can help
I worked with my client to bring these issues to light, much to her shock and dismay. We agreed that the organizational structure was not conducive to Agile software development. We instituted a number of changes to get back on track. First, the role of “manager” in the context of product development was deprecated. Instead, the Product Owner was empowered to make feature priority decisions, and in cases where conflict occurred with a manager, the Scrum Master served as arbiter. Next, the Scrum Master role was charged with the “check and balance” of ensuring that the Product Owner groomed only those Product Backlog items whose value was clear. I also encouraged skip-level meetings between my client (the VP) and individual team members, which can be used as a tool to bring to light any concerns the team might have, but have been previously uncomfortable raising.
Results
It’s been about six weeks since we made these changes. The realignment has been energizing to the team, as evidenced by unsolicited feedback from my client. While sliding back into old habits often happens, overall team productivity and morale are dramatically improved.
How is your process helping you?
© Mark Richman 2015