Scrum organizes people in classical ways to solve complicated modern problems. Humans have prevailed on this planet because they can work together in small groups to feed and shelter their families under extremely difficult conditions. Working together generates unexpected, useful solutions. Most of us no longer live and work in such collaborative groups. We don't have to. We forget, as a species, how we got to “now.” Current civilization is just fact, few of us question how it happened to be this way. "Natural Law" is a fairly disreputable concept in the sciences, but seems to fit in this context.
Scrum brings the small collaborative group into a modern context. We face complex problems at work that resist resolution given our quaint ideas about how work is naturally organized. Modern managers order employees around like so many tribal functionaries: build bricks, train warriors, distribute food, allocate irrigation water, collect temple offerings or levy tribute. This mode of business operation assumes most jobs are simple and the whip will motivate the lazy or enslaved.
Scrum works the really old fashioned way with a few defensive practices to keep enemies at bay. Scrum provides a structure that teaches and reinforces the classic values that humans employ to collaborate successfully. These are the identical values early men and women developed to collaborate because the survival of their kinfolk depended on it. All are necessary. You may not leave anything out. You will all know what I mean when I list the values. We, too, are people and we carry those instinctive ways of working within us. These core Scrum values are quite simple, but industrial management may consider one or more to be silly and naïve. This can put Scrum culture and "normal business culture" in conflict. That conflict is the source of resistance to Scrum. It is the reason many Scrum implementations fail to live up to expectations.
The Scrum (and small team) values are: Openness (aka honesty, transparency); Respect for others (meaning people) and their ideas; Commitment, accepting responsibility and then doing what we say we will; mutual Focus on achieving common goals. Finally Courage, that well-honed risk management tool that tilts a little toward sacrifice. If you are not going to be trampled by the Mastodon, you'd better have the courage to kill it. Even if you die in the attempt, your family will probably eat. That is where the behavioral parallel begins to break down. In life and death situations, your genes are very interested in the outcome, so to speak, and express their own values. We leave the elucidation and implementation of those values to others.
Cynicism, inertia and the trappings of power should not be underestimated. If we accept a paradigm of powerlessness, we can devalue or deny our most useful behavioral wiring. This is powerful stuff and we are conditioned to control it tightly. Mass rage is powerful. The utility of mass rage does not mean we are to pillage and burn. We are unlikely to align our interests perfectly with powerful instincts in the best cases. So we apply the classic principle of empiricism, inspect and adapt. We don't have to re-invent the method, just notice with discernment and act accordingly.
The small collaborative team pattern is neutral on a good-and-evil scale. You could run a criminal enterprise under the Scrum framework. How many examples of the good and the perverse utility of small teams can you think of? Many of us are wired to work collaboratively as surely as we find comfort gazing into a campfire or a television screen. Scrum is not the solution to every problem. If your group is lost and has a guide who knows the way, better to follow the guide than ramp up Scrum. Do only what makes sense.
“Scrum” was developed and first proved successful for managing software development. The best implementations of industrial theories were disasters managing software workers. Managers failed to realize they were dealing with something new: groups of knowledge workers, legions of software developers. When knowledge work was an individual game, say writing books, professional management ignored it. But now they were dealing with problems so complicated that it was impossible to think through the solution, write up a comprehensive plan and just turn the crank to produce whatever flavor sausage.
Complex problems throw off a continuous stream of questions and new ideas as you work them. You must continually incorporate new information and ideas into the emerging solution. The more carefully you plan up front and more rigorously you stick to the plan, the worse the outcome. Anyone who understands why centrally planned economies collapsed in the late 20th century should get this and vice versa. Even the near future can unfold with almost infinite possibility.
Actually, the problem is even worse. Any process you can imagine for solving complex problems will become dysfunctional over time. The process itself must adapt to local conditions and the changing nature of the problems it solves. This was no problem for our hypothetical prehistoric team. They were not hung up on process. They looked at what worked and did more of that; noticed what foods made them sick and quit eating them.
So Scrum is less a method or process than a mindset which propels an adaptable framework. Scrum principles and values change the way individuals think and interact with one another at work. Scrum teams self-organize to do the work. They deliver a bit of the finished product regularly so anyone concerned can see if it's as useful as they expected and suggest improvements. The team works in regular cycles, called “Sprints” At the end of each Sprint, they meet to discuss their process. What worked? What made us feel sick? They decide how to modify the process so it might work a little better in the next sprint. Notice that the people who actually do the work decide how to adapt the process, not their managers trying to figure out what really happened and factoring their own bias in.
This illustrates a curious and central bit in Scrum. The Team have to work their way out of their own problems. They have to get collaboratively creative to eliminate some common irritation. They can ask for help. But if they can do the project work, which is challenging and creative, they are smart enough to fix their process itches. If you help them too quickly, the never learn how good they can be.
Sprints repeat in whatever seems like an appropriate cycle. They tend to range from two to four weeks. After a short time, the process develops a rhythm or cadence. If new work is demonstrated every other Thursday, it's easy to make that a recurring item on the VP's calendar. Other structural rhythms are built into Scrum, like the festival seasons of the year. We plan at the Vernal Equinox and take stock at the Autumnal Equinox. The festivals and holy days remind us to do all the necessary things in the right order.
Two individuals playing different roles keep the team on the tracks. You want the team to be as outrageous as possible, but you'd like all that creativity channeled in the right direction. These two are the Product Owner and the ScrumMaster. I'm sure both are personifications of ancient gods, but I'll let you work out which ones.
A Product Owner makes sure the team has a vision of what they are bringing to life so they can all move the same direction. The PO is the single point of control for what gets built and what does not. The PO tends to win when the team is maximally productive.
The Product Owner keeps a list of all plausible product features and organizes it so the ones that should be done first actually get done first. Business judgment is required here, not just quantitative data. Remember that lies sometimes come with statistical reinforcement.
The ScrumMaster guards the process and the team. The ScrumMaster either teams with the PO or opposes her, depending on the issue. The ScrumMaster is responsible for group dynamics, for modeling and teaching the values and key practices. Above all else, the ScrumMaster keeps the inspect-adapt loop working well. Both the ScrumMaster and the PO find it in their interest to shield the team from outside interference. The relative contribution of each role to the result varies. Be careful not to skimp on either one. Future not predictable, right?
The new thing in Scrum, to the extent there is one, is the suspension of this selection of classical cycles, teams, principles, characters and holidays within the Scrum framework. The combination is encircling, reinforcing, conflicting and supporting. It all hangs together; it all works as a system. This is why neglecting some practice might make the values fade or fail to germinate at all. Scrum, it has been observed, is how we used to do things when our backs were up against the wall. More true than you might first suspect. Just once more: the values make Scrum work. More precisely, people imbued with the values do all that astounding work. The practices, principles, ceremonies and artifacts just manage space where humans can practice the values while working. It's just how nature works.
No comments:
Post a Comment