The Hungry Ant

Thoughts on product development in an agile environment

Tuesday, April 28, 2009

End of Project Retrospectives

I place a lot of importance on retrospectives, especially at project close. All projects have good points and bad points and it is important to learn from them so that the next project benefits. Retrospectives also provide the team an official closure and isolate problems to the scope of the project.

Project management processes like Prince 2 find this so important that it is a key phase for all projects.

If you are thinking of having an end of project retrospective, I recommend reading Agile Retrospectives. It provides a list of patterns for running retrospectives, whether at the end of the project orĀ  sprint/epic. My particular favourite is the “Timeline” method for analysing a project. I have had great success with this as it provides an obvious and simple way to gather information about the project and it helps people focus on what actually happened.

Here are some tips for running a retrospective:

  • The key skill is to manage the behaviour of the group and to keep the group to analysing the facts and not starting a blaming session.
  • Warm people up by starting with introductions or a game. Some people are louder than others, your job is to help everyone be heard, this helps their tongues loosen.
  • Have house rules for behaviour during the retrospective, and see that people stick to them.
  • Follow a structured approach to extract data, like using the “Timeline” technique. During this phase try to avoid analysing until the next phase. This part is hard as the group wants to talk about the most pressing issues straight away. Although common sense is required.
  • As long as you know the group well, keep rolled up pieces of paper to throw at people (gently) if they start deviating from the rules. It seems to help lightens things up when it is needed.
  • If there are any action points as part of the retrospective, make sure that they are documented and that someone in the group takes responsibility for each action with a deadline.
  • Have a fixed time for the different sections of the retrospective.
  • Make sure that you write up the retrospective within a couple of days and circulate while the points are still fresh in people minds.
  • Take a digital camera for taking pictures of the timeline and all the materials like post-it notes and pens.
posted by Dharmesh  

Wednesday, April 22, 2009

links for 2009-04-22

posted by Dharmesh  

Tuesday, April 21, 2009

Taking a shorter breather sprint can be a good idea

I have been reading “Agile Estimating and Planning” and there is a chapter where Mike Cohn mentions about taking a breather sprint which resonated with how I have been feeling on our current project.

When you are sprinting along in an agile project sometimes it is a good idea after 5 or 6 sprints to take a little 1 week breather to let the team reflect on where they are in the project and maybe do refactorings and look at the product from a distance. Sometimes it is not necessary, but if as a product owner or scrummanager, you notice that there is need for a break, don’t be afraid to take some time to reflect. Sprinting can be quite intense and can feel like you are on a treadmill (especially with 1 or 2 week sprints) so a short refactor/reflection sprint with no planning can be a great idea.

This week is one of those weeks…

posted by Dharmesh  

Thursday, April 16, 2009

Speak to the customer then assess the product opportunity

I am currently working on identifying new product areas that we could go into and have been using the product opportunity assessment as a basis for extracting all the current ideas we have into a form where we can decide which we should be working on.

As Marty says, it is the first question that is the most difficult and I think it is extremely important not to try to guess. Our assessments have already helped in giving us a much clearer sense where we should be putting our effort, but I think that we are lacking input from the potential customers. I strongly believe that before you start off on a new product you should speak to the potential users and understand if you are really solving a problem. If you are then the yes or no decision becomes a lot easier. If you are not then the risk of failure becomes a lot higher.

So off I go to find some users…

posted by Dharmesh  

Tuesday, April 14, 2009

links for 2009-04-14

posted by Dharmesh  

Powered by WordPress