Agile and Product Management

craig — Wed, 07 Oct 2009 20:50:25 +0000

Agile should be the product managers friend, but at times it can feel like you’ve lost all control especially when you can’t work on product development 100% of the time because of all the other things you have to get done.

So what should you do, do you hand off your other responsibilities to the marketing team or do you bring in someone to work full time on product development. From our point of view it depends on where you are in the product lifecycle, how your organisation is set up and what your strategic priorities are.

The folks over at Pragmatic Marketing talk about 2 different types of roles. A product owner (a scrum term) who sits within the agile development team and defines requirements, removes roadblocks and researches new functions and a product manager who sits outside of the development team but who has ultimate responsibility for the product being brought into the market place. In some cases they feel the 2 roles can be covered by an experienced agile product manager and in other cases they are split.

If you do take on the role, agile product management is not for the faint hearted. You may not be used to being so close to the development team, delivering your product in an iterative manner or not fully knowing what will be delivered until it is, but don’t worry you’ll get there in the end and it always helps to have some one around who’s been through it before. Some of the pitfalls to avoid include being tempted to change requirements or drop in new features during an iteration, spending too long documenting features or not planning what you want to deliver a couple of iterations ahead remember of course your plan may change.

In the end, agile won’t solve all of your problems. You still need to get out there, talk to your customers and shape the information you gather into something that your team can deliver. What it should do though is bring you closer to your product sooner than you would have normally been, which hopefully means you don’t get that confused feeling at the end of a project where you wonder why on earth the team built what they did.

Here are few articles, presentations and books we have come across that should help you out:

Can Agile Work With UX

craig — Tue, 29 Sep 2009 07:59:53 +0000

We find this is one of the most common questions asked within the companies we have worked and with the people in our teams.

The typical view of agile is that its all about hacking the code, no documentation and developers going off and doing their own thing, whereas with UX and User Centred Design (UCD) in particular the view is that it all takes too long, the design has to be perfect, we have to check with all of these users and we could have built and launched it by now…

The key issue seems to be how do you fit some of the fundamental UX methods into the small iterations that Agile develop teams work. A lot of teams run parallel design and build iterations, so that the design team has the time to create concepts and test them before handing them over to be built. This approach works but doesn’t really fit in with the agile principles of a team working together on discreet pieces of functionality within the same iteration

Another way to bring the teams together is to extend the scope of iteration 0 by not only looking at planning but also defining a high level information architecture, because changing this halfway through a project is very painful. We are not talking about Big Design Up Front (BDUF) but just enough so that you can understand how the product fits together.

In the end we think it comes down to the people more than the process, if the team wants to make it work they will find a way, just as the Agile Manifesto says it should.

We don’t think we have the perfect answer and there are lots of resources out on the web on this subject, below is a list of links to other articles, presentations and blog posts that we’ve read along the way.

Agile Bench » Agile

Agile and Product Management

Can Agile Work With UX