Way back in my first job out of university, I was working in Washington, DC, as a Navy contractor, helping manage changes to an electronic countermeasures system. Ah, those were halcyon days, when I was young and innocent green and scared of my own shadow. There was this one person I had trouble getting along with, not so much because he was a mean person, but mostly because he would make wild statements and push the team in directions that didn’t seem logical to me. Sometimes, he would advocate for decisions that seemed to me obviously to be bound for failure. He was overbearing and he was old.
(Actually, he was about the same age I am now; a disturbing thought as I look back.)
Because he was old and I was uncertain, I couldn’t bring myself to disagree with him out loud. I eventually was able to describe the situation to my boss, who responded with a statement that has never left me. He said, “There are people who have 20 years of experience, and there are people who have one year of experience repeated 20 times.”
Culture of the Agile Process
The big difference between the two kinds of people is that the latter have lived their lives, reflected upon the things they’ve gone through, and learned from it all. We often talk about Agile processes as being “empirical.” What I mean when I say that is a team makes its commitments, and structures its delivery model around reality. We don’t commit to delivering five times more in the next week than we’ve ever delivered in a week before. We don’t abandon a practice just because we’re bored with it. But the only way this reality-based planning and execution can work is if we go back and look at the reality we’ve experienced, review what worked and what didn’t and work to enhance the former and minimize the latter.
An excelling Agile team is continuously improving, and to do this it must be continuously inspecting. We expect scrum teams to perform retrospectives at the end of every release and at the end of every sprint. I encourage teams to also get into the swing of considering that every morning’s answer to the questions “what did I do yesterday?” and “what am I going to do today?” includes the implicit assumption that reflection on what you did yesterday informs what you are going to do today. I am advocating for daily retrospection.
In rolling out Agile, foster a culture of continuous examination of what you are doing weighed against what you are trying to accomplish. In addition to encouraging review of sprints and releases, continuously review your roll-out itself. As you roll out new processes, regularly hold retrospections with the teams that are implementing and being affected by the roll-out, so that you can learn from their successes and help other teams avoid their mistakes.
Inspect and Adapt
The buzz phrase for this kind of behavior is “Inspect and Adapt.” I see a lot of teams go through the motions of inspecting, but many of them don’t follow through with the second part. Don’t bother to inspect something if you aren’t prepared to act upon the results. An extended gripe session is nice to let off steam, but a team isn’t going to be enthusiastic about returning to the same old gripes sprint after sprint after sprint. This is what happened to “lessons learned” meetings in the olden days: somebody diligently wrote up a report about the things we supposedly learned and then tossed the result in a filing cabinet and we would return at the end of the next project with exactly the same complaints. When you are leading a team through retrospection, be prepared to act on the results (and make sure the team is empowered and resolved to act, as well).
However, if we come out of the retrospection with a prioritized backlog of improvement, we can plan that improvement into our practices and pull items off the backlog as we implement solutions. We can all make commitments to the non-development activities that might be necessary to make our environment a better place. If the backlog seems like it is filled with impossibly large problems, well, what do we do when stories are too big for our sprints? We break them down. Encourage the team to think of the smallest possible change they could make to improve their process. Then encourage them to break that down smaller. Then implement that first.
In this way, we can start being a team that has experienced 20 sprints instead of team that has experienced one sprint 20 times.
