The other day I was working with a product owner, let’s call him John, for a team that had been using Scrum for about 10 weeks and was becoming proficient with the framework. Compared to some of his peer teams within the larger program, they were doing quite well. They were effectively planning iterations, managing a backlog and consistently increasing velocity. Everything was looking good as we were putting together the agenda for iteration planning the next day, when John asked if we really needed to set aside time to do a retrospective.
The team is working effectively and seems to have a good grasp on what’s going on. We have a lot of work to complete, he explained. Wouldn’t it make sense to use the time simply to start the iteration?
I can’t begrudge John for his sincere question, and I know that I have personally fallen into this trap myself. While eliminating regular retrospectives is a clear violation of the rules of scrum, the criteria for an effective retrospective is more than simply holding a meeting to discuss “what went well, what didn’t go well, and what can we improve”. I can think of numerous such exercises that were unable to penetrate a superficial level excusing challenges as unique instances that are not indicative or larger patterns and concluding that things are running pretty well, much as they have been for a while.
In fact, I learned the real value of retrospection before even becoming Scrum Master. I had just started a job working as a BA & PM for a financial services firm and was teamed up with a few senior developers to build a new application. I had just joined the company and was careful to understand the dynamic of the team I was working with. I reached out to the business partners to understand what they were trying to do and we frequently checked in with the end users to get feedback as well. While I didn’t appreciate it at the time, my uncertainty in the domain led to frequent inspections and adaptions. Fortunately, the project was a great success and management funded a follow up project to further improve the feature set. They gave us more time and kept the original team together. I was even promoted to a “Senior Analyst”. Expectations were very high; that’s when the problems began.
In hindsight, I can see that we were intimidated by the amount of work. Consequently, we quickly jumped into the task at hand without discussing closely with the business unit. I naively felt we understood the business domain based on our prior successes; after all, I was the veteran team member who had led us to success the first time. We assumed the team’s dynamic would be consistent and our business domain was unchanged. Small, but important, requirements were missed, people began arguing over features and our objective looked farther and farther away. Looking back I can’t think of an huge mistake we made, rather it was a number of small things adding up over time. I didn’t appreciate the senior developer was hoping to leverage this second project into a promotion, and as such he was too eager to demonstrate leadership that at times was seen as bullying. I failed to see we were now offering premium capabilities that brought in better premiums but needed to be customized. Indeed it was a steady stream of small bumps like these that wore the team down. The most frustrating part was that we had been so successful the first time. In our minds, it was the same team working in the same domain; why was the second time so different?
In the first project, we were a new team and I specifically was new to the business area. As such, we spent a great deal of time trying to understand both what the business needed as well as how the project team was interacting. This level of inquiry and adaption revealed various insights that helped the project succeed. Unfortunately in the second project, we assumed it was those specific insights which resulted in the successful project and not the actual process of inquiry and adoption. Closed to inquiry, we were mentally attached to a set of rapidly expiring assumptions. Ironically, it was success of the first project that was most responsible for the failure of the second one.
So how do we avoid these situations? What do we say to those people like John who earnestly ask about simply avoiding retrospection? To his credit, John was much more aware and open about his perspective than many of us. Most of the time, we don’t say we’re going to stop reflecting on what we do. We simply close our minds, stop looking for patterns and go about however we are already comfortable working. Indeed, this is one of the values of scrum: it forces the team to go through this ceremony on a regular basis.
But more than the consistency of the ceremony, I believe it is the mindset of the team that matters most. It is patently obvious there is no such thing as a perfect team. As such, whether a team has formally embraced Scrum, Agile or no such framework, we are all on a journey. There is no real end to this endeavor where our execution will be flawless, or even “good enough” that we can stop reflecting upon how we go about the nature of our work. Even if such a “perfect” team were to exist, the exponential increases in computer processing power and relentless stream of new software tools to use it would render the carefully calibrated balance of such a team obsolete in no time. We must avoid the trap of assuming there is a best way to do things and look at our endeavors simply more as a journey. As with any profound journey, its how you get there that matters more than the destination.
