The Hungry Ant

I have a lot of respect for Marty Cagan and read his blog at SVPG.com regularly and I use a lot his of suggestions in my work. So I was very pleased when his new book “Inspired - How to create products customers love” was kindly gifted to me.

I came across Marty when I switched from running agile software teams to becoming the product owner. After about a year in the role, I came across Marty’s blog and he was talking about a lot of the problems I was facing and were not really focussed on by the agile community.

I voraciously read the blog and the first thing I tried was to create a product manifesto with the team. I was pretty nervous taking our heavily development team away from their desks to think about a manifesto. However, my doubts were unfounded, the team thought it extremely useful, we printed the manifesto large and put it on the wall next to our open plan space and I immediately noted the difference. Little ways that we behaved differently and the way that being reminded of what we were about as a team and product focussed our attention. Since then I have tried many tips from Marty and get similar results.

In this book, Marty explains the role of the product (development) manager, which in agile speak, is often the product owner, giving great practical tips and examples of how to create great usable products. He describes useful techniques, that I regularly use, like product opportunity assessments, personas and high fidelity prototypes, amongst others. But more importantly he describes where the product manager fits into the whole product development process and defines what product development is.

In fact I managed to get the BBC bring Marty over to do a workshop and he made a really big impact (even if annoyingly I had left by the time he did it!).

If there is one criticism, it is that this is essentially a digest of Marty’s blog postings. But hey, I much prefer having it to hand on my desk, and the content is very well structured.

If you are in charge of a product or starting one then I recommend you read this book. It has definitely given me a whole suite of tools that I use for every project I work on whether in a small startup or large company.

• Le formiche di Fabio Vettori - Homepage
  This has nothing to do with agile or product development, but it has a lot of nice ants. Really cool.
  (tags: ants)

When organising a sprint I would advise that there are only one or two goals. Sprints are not very long and by having few goals the team is never in doubt what needs to be done. It is also satisfying to think that something substantial has been completed. It improves motivation and projects seem to move along faster.

If the team is trying to do 5 big goals divided over 5 sprints it is better to do one goal at a time. It means you can also release early, keeping customers, stakeholders and teams happy.

I tend to write the sprint goals when doing the sprint planning meeting and have it visible next to the sprint backlog. This way everyone is clear on what needs to be done.

• Python Vs Ruby
  A good source for those that have this ongoing debate in their brain. Python and Ruby are very similar and I will program with either depending on the projects needs , but so far Ruby wins for its elegance, pure coding haiku.
  (tags: ruby python comparison)

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.

• Pleasure is Not the Absence of Pain | SVPG Blog | Silicon Valley Product Group
  Reinforcing my theme of the day of creating products that have something more than being usable.
  (tags: design emotion)
• Gaming the Web: Using the Structure of Games to Design Better Web Apps
  A great presentation about using game design to help create web apps. As I get deeper into flex and flash I am finding that I want to create something that is emotionally engaging as well as usable.
  (tags: games)

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…

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…

• User Testing Scenarios and Tasks - Fluid Project Wiki
  How to create scenarios
  (tags: scenario testing)
• Uploader User Testing - Round 1 Protocol - Fluid Project Wiki
  examples of scenario testing
  (tags: scenario testing)
• scenario2.pdf (application/pdf Object)
  This is a nice introduction to using scenarios when testing a complex interaction with your system.
  (tags: scenario testing)

• Tasty Cupcakes
  A very good site showing different games that can be used to explain agile. I have used a few of these when giving agile workshops and they have really helped me to explain the subtlety of agile.
  (tags: agile)