Process retrospective in a nutshell

While teaching a CSM class last week I was asked to spend some time on the current software development process in the company I visited. Since I had the retrospective as the next topic on my training agenda I decided to do an ad-hoc exercise with the team. After explaining the principles of a retrospective (setting the scene, collecting data, prioritizing and deciding on actions) with created a timeline of the current process. Four flipcharts on the wall represented the stages in a waterfall: analysis - design - programming - testing. All the people in the room wrote post-its with their positives and negatives in this process and posted them on the timeline. The pattern didn't show much of a clustering, the experiences were normally distributed along the timeline. So we decided to prioritize the experiences: each team member got a sheet with garage sale stickers (the pre-printed ones with values from 25ct to $10). They put money on the practices which they either wanted to keep or wanted to change. High values on the keepers indicated practices which they valued and wanted to keep using after their move to Scrum. High values on the negatives indicated practices which would be of a lot more benefit to the team and organization if they were changed. The exercise took app. 45 minutes, including a few discussions (not completion) of the solution design. I loved the clear display of the value of a retrospective, and the team was excited about the amount of work they could complete in just 45 minutes. The force of silent grouping!

Starting with Scrum

A good explanation of starting with Scrum without being perfect: it's like teaching people from India to play baseball. Tell them it is like cricket, you have to hit the ball with the club. We'll talk about the rules after every match. Thanks to Allen at MySpace.

Best excuse

Heard yesterday from attendees to my training course: "Sorry I'm late, there is this stripclub on fire on Sunset Boulevard and now the city is blocked". Much better than the Dutch version of "the bridge over the canal was open".

Scrum leads to change or change incorporates scrum?

While preparing to work with the exec team of a client I had to make a tough decision. While convinced of the idea that Scrum is part of the organizational change process, I could not create a talk that would present that perspective. The client is wrestling with Scrum concepts (good) and expects answers to their problems (also good). I'm fearful that they're missing the bigger picture, the full change process incorporates more then the early wins created by Scrum. John Kotter is my hero here, reading his books "Our Iceberg is Melting" and "Leading Change" brought me passion about change and the role of an exec committee in the change process. Yet how hard can you push a client towards the big picture. I'm going to try, using Kaizen as the entry point to the conversation. Scrum has feedback at it's core - product feedback through the demo and process feedback through the retrospective. If I can expand that concept to the whole process of delivering products to market then I may achieve two goals. I'm lifting the team out of the small and into the larger concept of continuous improvement. And they may see that Scrum is an important step to achieve that nirvana. One step is the start of a journey.




Our Iceberg is Melting (John Kotter, Holger Rathgeber)


A Sense of Urgency (John P. Kotter)


Leading Change (John P. Kotter)


The Heart of Change(John P. Kotter et al)

What's cooking

I've been trying to catch up with long overdue reading, having received some great tips from Chris Spagnuolo and Ben Carey - both great colleagues in the Rally

Services team. I started "Tribes" by Seth Godin, and although it reads like its written by a person who was writing two blogs and three articles at the same time as the book - besides cooking dinner for his family - it is an inspiring little book. Without the book you wouldn't find me on Twitter or Facebook, and this website wouldn't be here. Comes recommended.

What is also an interesting read is "Building the Empire State" by Carol Willis, a reprint of the 1930s notebook of the builders of the Empire State Building. Tom and Mary Poppendieck brought it to my attention, and it is interesting to read how the then largest building got erected in less then a year. It helps when teaching software architects that you don't need a big upfront design for a complicated project. What one does need is a good understanding of the trade-offs of the important limiting factors for the new product. Interestingly enough the building variables (like amount of steel and concrete) weren't the most important factors for the Empire State, it was traffic - having a truck arrive every minute on-site, and not being able to store the goods anywhere. The architects solved this problem by designing a new set of transportation solution on the building site, thus avoiding the need to store materials. These trade-offs, caught in an A3 (see elsewhere on the site) are an interesting topic for study in our software development world.