I’ve moved!

http://allintheplanning.com/wp/ if you’re intersted…

At our last retrospective meeting, one of my developers hinted he wasn’t liking the routine. He said he felt like Bill Murray’s character in Ground Hog Day, where every morning he woke up and it was the same thing over and over again.While this seems like a bit of an extreme comparison, there was an element of truth in what he said. While the framework of Agile dictates a certain amount of repetition, it also gives those involved the flexibility to work on different things each day, and decide as a team what’s most important.

The rest of the team disagreed, expressing they liked having less surprises and more structure to the working day / week. In my experience, this is the general consensus, but I’d be interested if anyone out there thinks differently.

What is a Product Manager?

This question has been a hot topic at work of recent times as this role has evolved (and some may say distorted) since the implementation of Agile. One of my colleagues passed on this article which added more fuel to the debate.

It would seem there is a greater debate about what a product manager is in terms of role definition. If you’re a product manager I’d be interested in what you do compared to others, like myself in the same field. Here’s a bit of what I do during each stage of the development cycle.

• Daiy: Scrum master, incident manager, problem solver
• Sprint: Facilitor & manager , manage requirements (high level / detail)
• Release: Facilitor & manager, communicator
• Product: Innovator, manager requirements (high level)
• Portfolio: Roadmap and planning (product backlog / release plans)
• Strategy: Roadmap

Definition of done

When you’re starting out with a new team, or just wanting to review your existing process it’s always worth making sure all the team understand what “done” actually means.

Is a work item done when the code is complete on the developers local machine or is it when it’s been tested and deployed to your QA environment? For some of you, done might mean when fully shipped to live.

My team define done as

• Feature from product backlog coded in entirety
• Code reviewed by another member of the team
• Functionality tested in QA (or System Test as we call it)
• Functionality tested as part of regression testing in QA

Then, and only then will it move into the done swimming lane of our sprint board and be included in the build for the next release to production. How about yours?

Is working Agile a bit like ground hog day?

At our last retrospective meeting, one of my developers hinted he wasn’t liking the routine. He said he felt like Bill Murray’s character in Ground Hog Day, where every morning he woke up and it was the same thing over and over again.

While this seems like a bit of an extreme comparison, there was an element of truth in what he said. While the framework of Agile dictates a certain amount of repetition, it also gives those involved the flexibility to work on different things each day, and decide as a team what’s most important.

The rest of the team disagreed, expressing they liked having less surprises and more structure to the working day / week. In my experience, this is the general consensus, but I’d be interested if anyone out there thinks differently.

Can you tell me why?

Failure to put the time aside to discuss requirements can leave gaps of understanding of what’s actually needed. The knock of trying to “save time” by not including this in your planning can be catastrophic to your product development and budget!

Making sure your development team has a clear understanding of what your client requirements will save time and hassle when you get to your planning and sprint stage.

To do this, meet with the business to discuss their new ideas and get involved. It might be there is already something on the site that could be modified to accommodate the new idea or you might need to suggest a meeting with other interested parties to discuss. 

If you’re lucky, the business will have a cost / benefit stage before going down the road of development. As I product manager I like to get involved here, before it’s too late. Knowing what’s in the pipeline and what’s most important to the business will assist your feature planning and flag any potential risks to other projects you’re currently involved in.

Recently I held a session for a home page redesign. We were lucky enough to have a full set of persona’s to work out user stories from. Each persona raised new questions on why the changes were required and helped us create a list of user stories to begin our planning with the development team. 

By meeting with the all the stake holders I got a clear understanding of the requirements (Commercial, Marketing, SEO & UCD)  which were easily translated back to the development team for further analysis. 

If you don’t know where you’re going, how will you know when you’re going to arrive?

All in the planning, not in the plan

I first came across this quote when I was cramming from a job interview at The Guardian a few years ago while reading Mike Cohen’s book Agile Estimating and Planning.

Unfortunately I didn’t get the job that time. What I got was far more valuable as it opened my eyes to effective planning techniques. This lead to me getting a job with a large publishing company who were in the throws of implementing Agile, using Scrum.

So, why the blog? I thought it might be a good place to discuss what happens using this framework on a day to day basis and hopefully get some of your views and experience.