Overlooking the Value of People Over Processes

About a 7-minute read

One of the core tenets of Agile, a foundational piece upon which the whole concept of Agile is built, is valuing people over processes. Repeating the positivity of the Agile Manifesto, “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools…,” just feels good. Those words take the cold, cog-in-the-machine feel out of project work and infuse it with an approach that promises opportunity for happiness in the work one does. Alas, the project world, a world rooted in the pursuit of peak efficiency and meeting businesses’ need for increasing capacity, laughs at the cuteness of such words. Agile practices, therefore, are perpetually at risk of becoming the implementation of process rather than a lightweight key to unlock the power of an organization’s workforce. When this occurs, the true strength of an organization, the people, suffer the greatest disservice. This post shares a story of such an occurrence, looks at what went wrong, and examines how positive outcomes were eventually achieved.

As a new middle manager tasked with leading an organizational Agile transformation, I spent hours meeting with leaders and peers espousing the potential benefits of migrating from traditional (waterfall) project management to Agile. One of the best selling points I emphasized was the empowerment of team members and how nurturing such potential would pay dividends for years because of the growth potential for individuals having more investment in the work being done. Such a conclusion was easy to draw – if someone has more control over their actions, and then can see those actions relate directly to customer and business outcomes, they should be able to find greater purpose and satisfaction. Scrum facilitated the implementation of this idea with its self-organizing teams that assume great responsibility in planning, estimation, and execution. In theory and concept, as it was trained and outlined from the start, Agile was met with cautious excitement for what it could bring to the organization. People, however, are unpredictable.

Despite all the conversations, training, and hours spent building consensus for how the organization was going to approach Agile, success depended on leadership. As in anything, if leadership breaks down or abruptly changes course, success is going to remain at the far end of a long road. All Agile truly needs to succeed is for leaders to actually “be” leaders, which brings us to the moment where valuing individuals and interactions over processes and tools broke down. Faith and trust in the organization’s knowledge workers evaporated once team managers and senior leadership realized they would no longer be present in every meeting, dictating every course of action, or seeing an immediate path to stay abreast of their teams’ work. There is likely a library’s worth of books written on management basics in the vein of staying engaged with team members and how too much management involvement, or overengineering, can choke the joy and productivity from a workforce. Yet, it is an easy trap to fall into. For this organization, the beginning of Agile brought about requests for new reporting processes, installing managers in scrum master roles, and, somehow, forgetting everything that had been arduously discussed and planned for months.

Scrum, inherently, has more opportunity for engagement and updates than the organization’s traditional project management methodology, by a significant margin. Because of the increased transparency, it is conceivable that a self-organizing team can operate with a high degree of freedom while the organization still has acceptable oversight. In the organization’s traditional project management, managers were in every meeting making every decision. Takeaways were relayed to their direct reports, and those reports were instructed on what action to take. One should be able to see how this approach stifles a person’s ability to grow and get better at what they do. You can hire the most talented and capable people, but if you then do not allow them to exercise their abilities, you are wasting years of their lives and wasting money that could have been saved by hiring less experience. Again, Agile puts great focus on people to create a snowball effect, where abilities grow and grow so the teams continuously improve. Eventually, the organization should be blessed with dream teams, powerhouses of throughput and customer delight.

Here, many teams were doomed to practicing iterative waterfall. Managers in the scrum master role continued to dominate conversations. Team members would remain quiet, waiting for the “scrum manager master” to direct, or they would default decisions to that manager, hindering team progress to chase down unnecessary approvals. Daily stand-ups and backlog refinements were scheduled around managers’ calendars so these individuals could attend for multiple teams. Spreadsheets were created for team members to document where they were spending their time down to the minute. The output from these spreadsheets was used to establish team capacities so they could be filled by meticulously estimated work. Accommodating one manager’s arbitrary need would create a pain point that required the creation of something else and on and on. Instead of a snowball effect of talent building, there was an avalanche of nonsensical thinking that focused on numbers and the unvalidated concerns of a few loud and persistent voices. Where we could have reinforced Agile values and stripped back to scrum’s very simple basics, leadership acquiesced to the loud voices and pushed for more process, more control. Leadership could have stayed the original course and guided the organization through the pain of change and transformation. Instead, the target kept moving and changing sides. Worst of all, team personnel did not get the opportunity to shine; they became cogs. That feeling, of being an overlooked piece of a larger machine, saps any enjoyment and purpose from one’s work.

Now, there is a happy outcome to this story. Agile transformation is hard, can be painful, and is never-ending. Agile will find the pain points of an organization and dig its fingers in until there is enough collective growth to release the tension. This requires patience and steady guidance, and it is important to never lose the perspective that continuous improvement is a goal and need. For this organization, they eventually rose above the clouds and were able to get teams practicing Agile as intended, with positive results and great satisfaction from team members and customers. How did they get there?

There was no magic elixir that suddenly changed people’s mindsets or reframed Agile so it miraculously clicked. The two biggest factors were persistence and patience. There may also have been a few personnel changes that got the right people in the right spots to affect change. Once adjustments were made, however, whether that was to the teams themselves or their practices, the focus became coaching through change and learning, waiting to see what things looked like when the dust settled before jumping into more upheaval. Individuals were also held to a greater level of accountability for their team’s success, so blame was less likely to be passed and solutions were sought rather than waited for. Convincing leaders and team members to be patient was one of the most difficult components of this transformation. However, happy endings are not always perfect. Despite the positive use cases, a number of teams were never given the opportunity to evolve and continued practicing with command-and-control management oversight. Unsurprisingly, there was noticeable disparity in team efficacy and happiness from their higher-performing peers. That is why the Agile transformation was never considered complete – the opportunity to improve always exists.

Given time, the empowerment to act, and the right skillsets, self-organizing teams can settle into a high-performing state and be the beating heart of the organization that Agile intends them to be. Over-engineer Agile with processes and control, and you take away any of the positives Agile aims to bring about. In those moments of change, when individuals are being stretched or forced into something new, the immediate reaction can be to create structure that is familiar and stable. This is not inherently bad, but a better reaction would be to lean into strengths. Most times, these strengths will be the people, where their knowledge, experience, and skills are more than enough to overcome the obstacles of change. When individuals have the opportunity to learn and grow from those challenging moments, they come out stronger on the other side, which benefits everyone.