Just Calling it Agile Doesn’t Make it Agile

Scrum.org’s Scrum Open Assessment includes a question on what would happen if an organization tries to adopt scrum processes without changing their traditional terminology. One correct answer is that management may feel less anxious. While I don’t doubt this is true, my experience suggests that the converse is also true: management will feel less anxious if they start using agile terminology but do not change their processes accordingly. This can leave the teams in limbo as to which methodology they should follow, and lead management to believe that the organization is practicing agile when it really isn’t.

I once attended a meeting with other scrum masters where we were told that management wanted us to sync up on how we were going to do estimates; e.g. whether we would all be using the Fibonacci sequence. It seemed that management wanted to be able to compare apples to apples when viewing charts for the different teams’ work. This would be a sensible request if we used absolute time units like hours or developer-days to estimate work, but story points are a relative unit of measurement with a completely arbitrary scale. The definition of what a story point represents is unique to each team, so point comparisons between teams are useless at best and misleading at worst. The managers’ request also did not take into consideration alternative sizing methods like t-shirt sizing, which are not number-based and would be an even worse idea to try to compare with another team’s story points.

This is an example of management’s trying to shoehorn the traditional way of doing things into agile terminology. Without a proper understanding of how estimates and velocity work, as was the case above, it is easy for them to think that the traditional way of generating and reading metrics, and comparing performance across teams, will continue to work in an agile environment. This reveals a gap in their understanding that we, as agile practitioners, have the responsibility to address. Even though the final decision on how to run the organization is not ours, if we do not give managers correct information on how agile processes work and why, then we become part of a problem that could lead to disillusionment with agile and make it harder for the organization to reap its benefits, thus decreasing or removing value from the organization instead of adding it. In this case, we needed to help them understand that comparing estimates across teams is an apples-to-oranges comparison, and that’s okay.

More broadly, managers need to understand that agile adoption will change not only the developers’ way of doing work, but also theirs. And they need to be at least cautiously comfortable with that. Agile development is a very different paradigm than what many companies were built upon, and it requires a correspondingly large change in managers’ mindsets for it to be executed properly. As we patiently and clearly explain agile principles to decision-makers in our organizations, we will be more likely to gain their support for the change. And even if we don’t, we will still have added value to the organization by helping them make the most informed decision they can.

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.