What are we doing when we put “Agile” ideas into practice? Let's limit the discussion to a subset of “work.” With Agile, we are employing limited human resources in ways that produce the most useful, valuable, new thing. We are taking advantage of one particular set of instinctive human behaviors for solving mutual problems. Whether this set of behaviors is more biologically or more culturally based is irrelevant. There are some patterns of interaction within small groups of people that are extremely effective. I speculate that such patterns of behavior repeatedly and reliably produce optimal results because they have been advantageous to the survival of our species. They work because they have been refined over millions of years. Our existence is testimony to their utility. Your narrative may differ.
The modern place where people assemble to work is organized by habit and custom. As proof of the existence of these customs I submit that admittedly dysfunctional working conditions and methods are much the same in many independent organizations. These organizational patterns developed for many reasons other than to create the best products. At worst they result in a group of people appearing to have a common purpose but spending most of their energy doing something else. Often that is fighting each other: Competing for limited rewards. Dominating and resisting. Passive and aggressive. Shifting alliances. Lying and betrayal. Illusion and misdirection. Smoke and mirrors.
For my purposes, “Agile” is about doing what really works to solve business problems based on fundamental small team dynamics. The team becomes an organism much more effective than all of it's members operating in parallel. The team can become “hyper-productive” with perfectly ordinary individuals. If you have never experienced hyper-productivity nothing I write will re-create the experience in your imagination. I ask that you suspend disbelief and resistance and ride with me for a while. Work does not get any better than hyper-productivity. Been there, done that, want to do it again. Want to teach you how to do it without me. Having done that before, having former associates create their own, I can say it's very satisfying.
Hyper-productive teams can be quite fragile if they are not knit together by kinship, religious, political, sporting or similar external ties. This is why we see them so seldom in modern life. Perhaps that is why we like observing team sports. Good teamwork beats all-stars. Clearly the dysfunctional behavior outlined above is utterly poisonous within a team. Good teams can be structured around a leader, but the best teams are collaborative and require no day-to-day leadership. This is partially because really effective leadership is harder to learn than collaborative teamwork. The most effective leader virtually disappears. The easiest way to disappear is never show up in the first place. In collaborative teams, everyone leads, everyone follows.
Work teams are rewarded for fulfilling someone else's vision. If the vision originates within the team, then it is not work, at least not the kind of work most of us do for our livelihood. Scrum is one approach to providing the structure and safeguards for hyper-productive teams to work fairly reliably on vision originating elsewhere. Since every team and every vision is different, Scrum is structured empirically. As the team works within the Scrum framework, they adapt their process (how they work together) to best fit their circumstances. The team periodically adapts it's work direction to best fit their customer's evolving vision. A role is established, Product Owner, to represent and focus the customer's vision. Another role is established, ScrumMaster, to keep the process on track, to be responsible for all the people stuff, and to keep the team thinking hard about what they are doing. The ScrumMaster role does not require being expert in solving these problems. It requires noticing “impediments” to hyper-productivity and mobilizing resources to remove them.
Scrum establishes a minimal framework necessary to protect the team from internal or external dysfunctional behavior. There are certainly other effective Agile frameworks. Scrum is simply what I know best. Nothing is included in Scrum that is unnecessary. Scrum is one complete idea. You cannot pick and choose the Scrum practices you are willing to do upfront. If you never get to hyper-productivity please do not ask me why. Are you actually doing Scrum or something equally complete and effective? Did you cobble something together and call it Agile? How are success, knowledge and courage coupled in your head?
Scrum as described within the past fifteen years is mostly about software development. Because Scrum is really about hyper-productive small teams in the workplace, it is much more widely applicable. Because it is empirical, Scrum will find a way to be useful implementing vision in more places than we can currently imagine.
You could successfully hunt elephant with a Scrum team using handmade tools the team creates, and that is not the least bit coincidental. If men hunted this way, you can bet the vision was from their mothers and wives.
No comments:
Post a Comment