Recently in Experience Reports Category

Since I started working at Embotics in 2007, we have always used an iteration length of 3 weeks.  I don't know why three weeks was chosen, though I suspect it provided a convenient trade-off between the amount of planning required to track the project and the amount of knowledge about where the project was going.  As we increased our level of agility, we continued to use 3 weeks since it worked for us.

I've been talking with a number of others in our community and doing a lot of reading and it seems like we are an outlier here.  Almost everyone else appears to be operating on 1 and 2 week iterations.  The The Wisdom of Crowds indicates that we may be missing out on something here.

I recently wrote about some planning that went into our first FedEx day.  Now that we have run this experiment, it is time to share the results.

The day started in a slightly chaotic manner as we were completing our move from our old offices.  However, we were able to quickly sort out some minor issues like power and get started more or less on time.

Atlassian recently ran the Ultimate Wallboard competition where individuals and companies were invited to send in pictures or videos and descriptions of wallboards that they use to make their lives and jobs easier.  Embotics submitted our Scrum wall to this contest and came away with an honourable mention in the Old School category.

The timing of the contest was a little unfortunate for us as we were nearing the end of a release and simultaneously preparing for a release.  As a result, I was only able to provide a little colour to our entry but now have the opportunity to elaborate on what our big visible board contains and how it evolved to its current shape.

The idea of introducing free time to explore ideas and foster innovation at work has a lot of appeal to me.  Evidence from 3M, Google, Atlassian, and others suggests that many new product features and workplace improvements can be discovered if people are given some slack time to explore.

Coming off a difficult and demanding release, Embotics will be spending some time next week on our first FedEx day.  The timing is great: the release is out the door, we are moving into our new office space, and everyone has a to-do list of things they thought about during the release but didn't have time to investigate.

During our November meeting of the Ottawa Scrum Users Group, I talked a bit about how retrospectives should be used to do more than just discover things that aren't working well and ways to improve them.  Often a team can identify problems but do not have the ability to make the changes to correct the problem for various organizational reasons.

The alternate approach is to instead concentrate on the bright spots.  These are the things that are working well and overcoming challenges.  If you can replicate the conditions and settings that produce these successes, then you may not need to address the things that are getting in your way.

The Ottawa Scrum Users Group recently held a Meetup on the topic of retrospectives.  I presented a number of ideas (Powerpoint) that have led to our successful implementation of retrospectives at Embotics and discussed those in the context of some ideas from books on retrospectives and change.

Whenever we talk at these Meetups about adopting agile practices, my first response is that it all begins from the retrospectives.  If an organization can examine how they are doing and find ways to make steady improvements, then they can greatly change how they work in positive and highly productive ways.  There are simple ways to kickstart this process and then adapt locally as things begin to click.