Twelfth in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can’t) be applied or adapted to technical writing.
*****
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
At my first technical writing job, at the end of every release cycle, we held a post-mortem. Each department would discuss what worked and what didn’t in the last release cycle, and management would meet and discuss what we reported. But during the next release cycle it seemed like we’d do the exact same things, follow the same process, and compile a very familiar list during the release port-mortem meeting. It seemed like no matter how many times we listed things we’d like to see change, we always maintained the status quo.
Some find it easier to list their complaints than to work towards making changes. I suspect that many of my coworkers were too set in their ways and too comfortable with the way things worked to make any major changes. And I suspect that even those who wanted to change found their old habits were just too hard to unlearn. I know that I find that habits are hard to break, especially when I don’t have real motivation to do so. This is why I believe that the most important part of this tenet is the second half – “then tunes and adjusts its behavior accordingly.” The reflection is absolutely useless unless you actually act on it.
Several years ago I came across the concept of kaisen which is a Japanese word for continuous, incremental improvement. Small changes over a long time eventually add up to big changes. It is something that I’ve tried to apply to my life, because if you’re not improving, you’re either standing still or falling behind. This is one of the reasons why I belong to several different STC special interest groups (SIGs) and a couple of technical writing mailing lists. If I’m not keeping up with the industry, I’m falling behind.
Agile tenet #12 puts kaisen to work. The team regularly checks in with itself and examines their own processes. At my company we have a retrospective at the end of every Sprint. We list things that are working (and that we should keep) and things that aren’t working (that we want to change).
One of the benefits of Agile is that you can experiment with changes. A Sprint is a relatively short period of time, typically 30 days. You can try out a change, see if it works, and if it doesn’t, you can easily abandon it. For example, our team has shifted the time for our morning Scrum meetings around a bit. They’re still in the morning, but the times have shifted around between 9:00 and 10:00 a bit depending on the needs of the team (and the season, we’re in New England after all).
I keep reading articles about how important it is to risk failure in order to succeed. So often we are paralyzed with fear, afraid of doing the wrong thing, not sure what the “right” this is, so we do nothing. But the short time span of a single Sprint lets makes it easier to risk experimentation. You can try something new for a month, and if it doesn’t work, you can try something different. Short term commitment is one of the benefits of Agile. And it can free up the creativity of the team, let them take risks (OK, maybe small risks, but risks nonetheless) and work on developing new team habits.
And there may also be an accidental genius to the three or four-week sprint. Convention wisdom holds that if you want to make or break a habit, you need to practice the desired behavior for three weeks. So if the team is trying to break in a new work habit, the length of a Sprint should be long enough to start building the new habit.
And at the end of the Sprint, you can reflect on your changes, decide if they’re an improvement or not, adjust accordingly, and start the cycle all over again.
HeraTech 