The Importance of an Agile Process
written by Paul on December 28th, 2010 @ 12:02 PM
Over ten years ago at the start of my career I was vehemently opposed to “process” and mostly thought that a process was for those who could not be independent and relied on slowing down to mediacracy in order to ensure that the whole organization was synchronized.
Now that I am looking back I realize that I was right and wrong. I have learned that processes are the only way to breakout of mediacracy. I would like to share what has changed my outlook and discuss the pitfalls of applying processes the wrong way.
A process must…
1) be changeable by everyone who operates within it:
Everyone within the process must use their observations and power of perspective to “own” of the portions of the process that they interact with. Nothing is more destructive to a team’s productivity or an employees morale than seeing opportunities to improve, proposing them, and then being told by “the powers that be,” that their ideas are good, but [put traditional management smoothing line here.] This is what caused what Frederick Taylor referred to as “Soldiering” in his paper, The Principles of Scientific Management—people, when “put in their place” will do the minimal in order to get paid but avoid “punishment.”
2) be seen as a way to instill discipline within a team:
Lets face it, we are all different and some of us have more discipline (or other kinds of discipline) than others and even the most well-meaning and disciplined person can quickly become derailed when under the pressure from investors or the excitement of a new idea. Because of this normal tendency that each of us have, a process can ensure that rational thought and perspective is continuously applied.
In XP there is a notion of pair-programming—this tool does much to keep two minds around the same problem, where one might slip off into an interesting but unnecessary deviation within a project, the other can pull the reins and so the pair become more productive because they are guiding each other as a team.
Looking back on my life the times when I was int he best physical shape and frequented the gym was when I had a friend to train or work out with. The dynamics of a process or team culture can take a team very far.
3) allow and even encourage experimentation and testing:
When a potential opportunity for making the process better arises, proposals for improvement must be respected and the ideas should be tested. Like all empirical process, the results should speak for themselves. In fact there is a powerful side effect of testing that is not to be ignored. The Hawthorne Effect illustrates how by simply knowing that you are being measured you perform at a greater level. The idea or process change itself may not directly increase productivity, but just like how a pedometer can get one to move more to lose weight, knowing that you are being tested increases ones focus.
4) not driven top-down or bottom-up, but both:
Right below being told you can’t do something (referenced in #1 above) on the list of productivity killers is being told what to do. In a perfect world your whole company would all have the same epiphany on exactly how to conduct the their agile process, but in the real world, we need to share our ideas, persuade, and be persuaded. Kent Beck has said “The best architectures, requirements, and designs emerge from self-organizing teams”, and when people are empowered people care-less about position warfare and individuals are more likely to take feedback and ideas from the “top” and vice-versa. Processes that evolve on principles of efficiency and are aligned with organizational goals are always going to be more successful than those that are imposed.
5) increase productivity:
If any aspect of a process does not contribute to the productivity and health of an organization or team then they should be changed. One of the beauties of Scrum is the focus from the team and organization on “Inspecting and Adapting.” Process changes should always result in greater productivity!
When I was younger and more allergic to the word “process” I was right to feel that way because many of my observations of what “process” was presented as were indeed dysfunctional applications of agile (or not) “processes.”
Some companies like 37Signals denying the existence of a “process” because of their “process” allergy. They often talk about not having a process, but what they don’t convey properly to their audience (and I think its unfortunate) is that they DO have a process, though not written down, that is deep within their culture. It’s great when the process is natural and doesn’t require a wiki page to describe it, but for most teams and organizations a common vocabulary and understanding of the what, when, and how’s is important because some people need to adapt to a new culture.
Now that I have experienced the benefits of having just-enough process to get hyper-productive my allergies to the word itself have ceased.