Taking Time to Think
Engineers are funny – when we get wrapped up in building something, the rest of the world tends to fade away. Just ask our significant others; they’ll give you a knowing look and roll their eyes. It gives new meaning to the word “obsession”.
It’s not a bad thing, at least not in healthy doses, and the Scrum process and sprints tend to bring us up out of our collective reverie as we pause briefly to observe what we have wrought, and then plunge back into it for another two weeks. My current project team has been flirting with the transition to ship mode for a while now – I actually declared it too early and had to rescind it when the scope shifted on me. The focus has been evident in the last couple of sprints – long days and nights and lots of work left to do.
Unfortunately, for teams new to Scrum, this is also when fresh habits already start to fail you. No sooner did we start to get into the heat of battle when we stopped doing our retrospectives. Now, on the surface that doesn’t seem to be such a bad thing; maybe everything was going reasonably well and we didn’t really need them. However, as the coach for the team, my job is to to try remain more objective about the state of the project and the team and to make sure that good habits are sustained. There is no good excuse – we were simply all too busy to think.
On a personal level, this also became clear as I watched my once frequent writing habits lax into near nothingness. Every once in a while a thought would fire, but no action resulted – the pressure to produce in other areas was too great. Whenever I have some time available, my mind runs through a quick triage – the one hundred unread emails in my inbox, the project designs that are incomplete, the urgency of the next team milestone and the developer that is stuck and needs help, or even the code that needs to be written. All of these are more important than taking the time to think, reflect, and to write.
It reminds me of the frog in hot water – the temperature keeps rising until it approaches dangerous levels, but the frog is unaware. Retrospectives represent a chance to take the frog out of the water, adjust to new surroundings, and then find out what it will take to get it back into the water again. By doing this, we keep our expectations of ourselves realistic and we create the culture of learning that make Agile so great. After all, no matter how much pressure you are under, do you really not have the time to see if you can fix it?
There is always pressure during the final stages of any project, but a retrospective will help you tell between normal pressure and unrealistic expectations that need to be fixed. As the leader in the team, you are more susceptible to this than most – you set your course and sprint out ahead to lead the team. While doing this, it is so easy to get absorbed in the immediate issues of the day that you don’t realize that you have lost your team. Retrospectives represent a chance to stop, let everyone catch up, and to figure out if they are all still with you to the end.



