July 14th 2010 | Jimmy Bosse
Agile, Scrum: Always Require the Retrospective
If you’re thinking about bringing Agile, Scrum, etc. into your development organization, I have one important piece of advice: always require, and never stop doing retrospectives.
I don’t care if your team is made up of brilliant developers who resist a new process, or project managers loathe to try something new. In my opinion, the retrospective is the single most important element of the Agile process. Implement it early, and keep it even if you scrap everything else.
The power of the retrospective to a development team is immediate and relevant change. The practice of developing software is littered with beleaguered development teams, exhausted from consistently delivering the impossible and getting very little recognition in return. When they express a desire to change things that effect their daily life but don’t provide immediate business value, their requests fall on deaf ears.
In Agile development, the team is paramount and their concerns are of great importance. The retrospective is the vehicle for improvement for both the team and the software it produces. When you provide a team with a forum to express their concerns, and commit to implementing their recommendations, the result is a motivated, productive team. As a developer, I always get an opportunity to engage in a dialog with my team to decide if my concerns are valid. Not every request or suggestion will be granted, but knowing my opinion is being seriously considered makes this easier to accept.
Without the retrospective, my recommendations and those of my team become a morale sinkhole, demoralizing the team and compromising the quality of the software we deliver. Issues and bugs become a game of CYA and everyone points fingers at everyone else. But in an open, collaborative environment the team as a whole takes responsibility for issues and bugs, responds to them quickly, and has an opportunity to discuss how to keep them from happening in the future.
The retrospective is a time for the team to discuss what is working and what is broken; decide what incremental change is most important; and commit to fixing that one thing. At the next retrospective the team evaluates whether that change made things better or worse. Surprisingly, sometimes an item that was considered an improvement a few month earlier might now be identified as broken. It doesn’t matter if it worked well before—if the team decides it’s not working, they scrap it and keep on moving. Who knows, it might just be back again in another three months, but I am content in the knowledge that every two weeks (or whatever your iteration cycle might be) I will get the chance to make things better.
That makes me a happy developer, and happy developers make better software.
If you have any questions about this series of posts or about DevConnections, feel free to send me an email (jimmy.bosseATthycotic.com) or message me on Twitter @jimmybosse.