Agile Product Management 101.

Alas, it is always painful dealing with product management that always changes requirements in near real-time.

It is worse when product managers only give very vague requirements and either don't elaborate on the requirements in detail or worse create requirements on the fly as a system is being built and expect these requirements to be implemented as they emerge in a strange real-time like fashion.

The above is quite normal for teams delivering ‘Green Field’ products/projects that start of as prototype technologies and are initially vague at best until certain technology concepts have been proven.

Now the best way to deal with the above scenario in an Agile manner. At a high level is to take the following very basic steps.

• Create a high level feature list
  • Normally from any source that the Product Owner/Manager has access to.
• Decompose high business value items into a little more detail. Good to involve an implementation team to do this.
• Get the Implementation team to say what it feels it can implement and demonstrate effectively as implemented within a time box. I prefer every 2 or 3 calendar weeks.
• Do not interrupt the implementation team as they deliver what they committed to.
  • If a new requirement is discovered save it til after the time box is complete and the team has delivered its [promise or not.
• Evaluate implementation teams deliverable via a retrospective meeting
  • Highlight anything that is wrong
  • Highlight the good
  • Be constructive
• Plan what will be delivered in the next time box

Rince and Repeat.

Now the key here is how you manage change and deadlines.

A few key things that affect deadlines follow:

• HR related
  • Illness
  • Personal Issues
  • New Staff Hires
  • Politics
  • Staff Skill limitations
• Technology related – issues in working with technology to implement a feature in a system for example.
  • Bugs
  • Technology limitations
• Business Related
  • Budget changes
  • Custom Demo’s for sales/pre-sales/etc.
• Added requirements, Missed requirements
  • Never add this to a running time-box
• The list goes on

 

There will always be commercial deadlines but this is where compromise comes in.

Compromises can be any of the following:

• Add a requirement by dropping another
• Stop current time-box and re-plan a new one

Never add features to an existing implementation teams committed work for a time-box.

It is always better to stop a implementation teams work, and re-plan a new time-box of work team can commit to, Rather than trying to force a team to deliver.

Always, demand to see a demo of what was promised by an implementation team at the end of a time-boxed implementation

Never act as a project manager when you are a product manager.

Never act as a Scrum Master when you are a product manager.

Always be available  to the implementation team if they have questions on the product requirements they are working on.

always have a retrospective meeting reference the time-boxed implementation

Always look for good and bad in a time boxed implementation.

Always respect the implementation team, never demand, ask and discuss/negotiate.

You know the product and the business, the implementation team knows the technology and what can be done to implement the product. Both sides have to listen to each other as an equal.

That's it for now.

There are plenty of examples of the above on google if you search for “Scrum Product Management” and “Scrum Product Owner”.

I will do a more defined and clear guide to agile product management later.