If You Are a Non-techie Manager, You Should Love Scrum

If you manage technical resources but are not very technical yourself, and you struggle to establish a workplace environment that leverages both skill sets while not interfering with with each other, I encourage you to consider adopting scrum. It provides a clear, minimalistic structure in which your developers can do their best work and you can do your best work, with each one respecting the other’s sphere of responsibility.

One fundamental rule of scrum is that the scrum team must be self-organizing. The Scrum Guide states, “Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” It limits the influence that the rest of the organization can have on the team: “For the Product Owner to succeed, the entire organization must respect his or her decisions” regarding how requirements are prioritized. It even establishes boundaries on how team members can influence one another: “No one (not even the Scrum Master) tells the Development Team how to turn [requirements into deliverables].”

This leaves practically no room for micromanaging the team. Managers who are used to directing the team in day-to-day scheduling and implementation details will find that they need to adopt a much more hands-off approach with scrum teams. Not because scrum requires managers to step back, but it because it requires the team to step forward and assume much of the responsibility for planning, design, and communication that might have traditionally belonged to other points of contact in the organization who were not as closely involved with the actual work of implementation. In this sense, scrum fosters a strong sense of leadership and accountability in the team members rather than relying on having a manager who possesses these attributes. (In fact, the word “manager” does not appear anywhere in the scrum guide as of this writing.)

Some managers consider this a relief, while others consider it nerve-wracking. I am in the former group. Scrum is a good framework for making both managers’ and developers’ lives easier. It frees developers to nurture and apply their creativity as they see fit, and it frees managers to focus on the higher-level issues that developers should be mostly insulated from, such as organization-wide planning and the accompanying politics. Scrum essentially lets people do what they should be doing, as best as they know how, without being distracted by people who don’t. Even as someone with a technical background, I find this extremely liberating. Why not give it a try?

Protecting Your Team Does Not Mean Protectionism

Protectionism is the economic practice of protecting domestic production and trade by making it more difficult or expensive to trade with other countries. It is also manifest in office politics when one team or department refuses to work with another because they’re afraid of losing control over their own little kingdom. Whatever the pros and cons of protectionism are at a macroeconomic level, it is almost always a bad idea in the workplace because it keeps you from building bridges with other communities within the company and isolates you from individuals with skills that can enrich your team. Enriching your team = higher quality of work = higher likelihood of success.

When I became the scrum master in one particular team, someone from the customer’s team was pushing to have one of their developers join us remotely. I wasn’t happy about it; not because I had anything against that developer (I hardly knew him), but I felt that the person who was pushing for it was overstepping his bounds and I wanted our co-located team to gel before adding another variable to the work. In the interest of good relations and giving that person the benefit of the doubt, I grudgingly agreed to have the remote developer join our team but kept him at arm’s length for a few sprints.

That was an immature mistake. The remote developer became a valuable member of our team and helped us identify issues in code that he wasn’t even working on. He was originally focused on QA tasks but made himself available to help with coding, which we needed more of, and having him on the team helped us learn more about the QA side of things through osmosis. Having him on the team also enriched our retrospectives as we looked for ways to use his role in our continuous improvement efforts. All in all, the benefits outweighed the logistical challenge of integrating him into our team.

As scrum masters, part of our role is to protect developers from undue external pressures and distractions so they can focus on doing the work in the way they think best. But we should not confuse protecting the team with isolating the team, or engaging in workplace protectionism. This can limit how cross-functional our teams are. Of the three pillars of empirical process control that are used in scrum (transparency, inspection, and adaptation), inspection and adaptation require us to objectively evaluate what is best for the team and how to integrate it into the team’s processes, regardless of where those improvements come from. Practicing scrum with that mindset of humility and willingness to accept improvements from sources outside of your immediate team will help your team do better work and make you a more effective servant-leader.