The last entry in my Going Agile series will look at the retrospective meeting.

The retrospective meeting is held at the end of every sprint/iteration, and it is the time to discuss what went well, and what could be improved in the next sprints. Some people will say the Product Owner should be in attendance, and some believe the PO should not. IMHO, the PO is a part of the team, and should be there…and in our case, I was. We weren’t sure how to solicit input from the team, so we decided that everyone should take a few minutes to write down their thoughts, and then the Scrum Master would read them out. This was a good way to eliminate the classic, “I was just going to say the same thing as Bob” response. After all the responses were collected, we realized we had 3 main things to address:

1)      Testing and documentation struggled…they were too heavily back-loaded

2)      Code reviews were determined to be essential but weren’t being factored into estimates, etc.

3)      Our team velocity was nowhere near what we thought it would be

From these things we made a few adjustments for our next sprint (again, these decisions were made by the team as a whole). Our developers stopped working on new stories 2 days before the end of the sprint, and would then focus on testing and documentation. This would help alleviate the avalanche of new functionality that would hit the testing and documentation team on Friday afternoons. Code reviews were added to the definition of ‘Done’ and were factored into to estimates.  For the 3^rd issue,  we found one of the key issues to be that developers just weren’t given dedicated time to code, and as such, could be interrupted at any time for an impromptu meeting, or discussion, etc. We decided to implement a Do Not Disturb mode for the developers, and if they had that DND sign up in their cubicle, or on IM, then they were not to be disturbed.

The retrospective is a crucial part of the continuous improvement process, and time must be dedicated to it. The first few are extremely important since that is when the warts are most obvious, but minor tweeking  may never stop.

I’ve enjoyed sharing my experiences about my first Scrum team, and I hope it may provide some ideas for your team. If you have any Agile/Scrum experiences you would like to share, I’d love to hear about them. Chances are others will stumble across the same problems at some point as well.

There was a recent blog on whether or not you should have bugs (that were not found during the most recent iteration) added to your product backlog, or kept in a separate bug backlog. Here at Klocwork we have a defect database that is closely monitored by Support, dev, PM, and so on…suffice it to say, it has a high degree of visibility within the organization and will probably never go away. Being an Agile company we also have a product backlog that is reviewed daily and prioritized regularly. Every two weeks (coinciding with our iteration planning) PM and Support get together to discuss the highest priority bugs, and to determine if those bugs should/need to be added to the backlog for the next iteration. A key piece to this process is using tools to maintain this backlog. The backlog tool, which also has an integration with our defect tracking system provides a tight correlation between the two, and a level of automation that makes life a little easier for everyone. Once added, these bugs are prioritized just as we do with all of the other features (stories) we have in the backlog. We also have weekly status meetings where the most recent bugs are discussed, once again to ensure they receive the proper attention.

Since we are in the bug-finding business, we take bugs very seriously and adding them to our backlog (and as a part of our iteration planning) helps ensure we address them quickly.

As a Product Manager, I’m a huge fan of Agile. Sure there are the obvious issues to contend with such as trying to nail down an exact date to release the product, or the fact that it doesn’t work real well with larger development teams, or that it can suffer the classic, “that’s not how we used to do things” syndrome. In my opinion, these all pale in comparison to the benefits that I, as a PM, get from Agile.

First, is there anything cooler than showing a totally awesome new feature to a customer and be in the position to gather their feedback (usually applause and cheers of joy…sometimes not so much…) right then and there…not after the release?  It is great to know that you are hitting the right notes so early on, and if not, then having the time to adjust. If you’re not able to demo to a customer liver, then take a few minutes and record a demo for each feature and post it somewhere they can retrieve it from. This is a great way to scale and while the feedback may not be immediate, it still comes in. Secondly, no more Requirements documents that are obsolete a week after delivery of them to development…again, requirements need to be well defined and communicated, but continuously revving a document gets old very quickly. Finally, I love the fact that people (whether internal or external) know stuff about the release. Try running Iteration planning meetings at the start of every iteration, and invite all relevant stakeholders. Here you can outline what is coming for that iteration, and for those unable to attend, post the decks for their review later. This is a great way to increase awareness and communication both within and outside of the team. Surprises are minimized (for those that paid attention), and if done right, these people have had their chances to provide feedback throughout the release cycle. No more Monday-morning quarterbacks telling you that you should have done this or that…

So, if you’re a Product Manager and you’re hearing rumors about your organization going Agile…jump on board, I think you’ll like it.