Missing The Point of Agile, Part 2
Part 1 — When Agile isn’t “agile”…
One of the single most important and fundamental aspects of Scrum (that I’d wager half of the companies adopting the methodology don’t “get”) is that it is a team-oriented methodology. Scrum teams are expected to have the authority to do what they need to do to meet their commitments, the autonomy to achieve those commitments in the way they deem most appropriate, and the insulation to focus entirely on what they have committed to during each iteration. Most of the time when I see a failed Scrum implementation, this is one of the main reasons for the failure — the company and the culture have not accepted the autonomy of the team, hasn’t delegated the team the necessary authority to do their work, and/or doesn’t insulate the team while they’re working from the other goings-on in the company.
Further, effective Scrum work requires that the entire team be engaged from planning through to delivery — nobody should be allowed to sit by the wayside and let things steamroll through the team. Everyone should have the ability to “push the big red button” and stop everything if they feel things aren’t going the way they should. Scrum is an extension of lean production methods — and the most important concept to the success of the team is that…well, they are a team. Teams need to engage on estimation exercises; teams need to engage on backlog prioritization efforts; teams need to engage on what they can or can’t do in a given iteration; teams need to review their work with the Product Owners and Stakeholders. It’s the team that succeeds or fails to achieve their commitment, and the individual needs to support the efforts of that team. If a member of the team isn’t engaged or supportive, they become separated from the goals, and that’s a cancer within the organization that’s only going to grow.
THE ENTIRE POINT OF SCRUM IS TO PROVIDE THE TEAM WITH THE AUTHORITY, AUTONOMY, AND INSULATION TO MAKE THEIR COMMITMENTS AND TO ACHIEVE THEM ON A CONSISTENT BASIS.
The entire point of Scrum as a team-oriented process is that the team is expected to internalize the goals that they are committing to. They are expected to push each other and to hold themselves accountable for the work they’re doing (or not doing) to meet the goals. There’s a strong level of peer pressure (in a good way) that is supposed to make the team better — nobody wants to cause their team to miss their commitment. Nobody wants to be “that guy” that constantly over- or under-estimates the amount of work something’s going to take. The dynamics of a strong, successful Scrum team are those that serve to reinforce good behavior, punish bad behavior, and strive to achieve — all without the external oversight of a traditional management structure. The team matters, the team establishes their norms, and the team reinforces and polices those norms. Self-direction is more than just a buzzword; it’s essential to a successful Scrum transition, and absolutely required to scale it beyond a few teams.
The other 99% fatal flaw in poor Scrum implementations is that the “business” dictates to the “developers” what gets done, and/or how to do it, and/or what timelines “have to” be met. These behaviors are entirely antithetical to the concept of Scrum development and often to Agile principles themselves.
First, when commitments are dictated to the team — when they’re told “you have to do X in Y time with Z resources,” you’ve emasculated the team’s authority. They’re no longer buying in to the work they’re taking on, and once that happens, the necessary internalization of the goals falls to the wayside, and they’re just taking orders again — no better than what happens in the old Waterfall world of “check-the-box” requirements.
Second, by removing their input and commitment, you’re setting them up to fail. The purpose of high-level estimation and sprint planning in Scrum is to act as a check against the common practice of the business underestimating the complexity of technology problems. It’s intended to give the developers not only a voice in the discussion of priority and difficulty, but to give them the ultimate veto power to say, “No, we can’t do that in two weeks. Let’s do something else and come back when you’ve broken that down more.” This level of empowerment makes sure that the team not only feels heard, but that they feel understood by those above and around them who are “telling them what to do.” If all you’re doing is handing them a list of things to do and expecting that they’ll get them all done when you’ve told them to…well, you’ve missed the point entirely.
SCRUM IS A COOPERATIVE, COLLABORATIVE PROCESS THAT ALLOWS DEVELOPERS TO VETO UNREASONABLE COMMITMENTS BEING FOISTED UPON THEM BY PEOPLE WHO MAY NOT UNDERSTAND THE COMPLEXITIES INVOLVED.
No, this is not to say that there aren’t clear business priorities, or that the developers only get to work on the things that they want to work on, and the business can be damned if they want something shiny and pretty. The power, authority, and responsibility of ensuring that the right things are being built in the right way lies on the Product Owner, who is the representative of the customer to the developers, and the representative of the developers to the customer. It’s up to the Product Owner to create stories in a way that the development team sees the benefit to the customer, and it’s up to the Product Owner to take the developers’ feedback out to the business and make those stories better. If you’re doing it right, there is little tension in these planning meetings, and they can take less than 15 minutes from beginning to end. The corollary there is that if these meetings are more than a half hour, you’re probably doing something wrong. Terribly, terribly wrong if they’re taking more than an hour.