Part #9 The role of the Product Manager in Scrum

Scrum has three key roles:
#1 The team – who owns the sprint backlog and are responsible for estimating. functionality and fulfilling the commitment made at sprint planning meetings.

#2 The Product owner – who owns the product backlog and decides on product functionality.
#3 The scrum-master who owns the impediment log and is responsible for removing any blockages that hinder the team from performing and fulfilling their commitments.

So what's the role of the Product Manager in scrum?

Alyssa S. Dver writes in her book: Software product management essentials that: “The job title of Product Manager is vague…. Sometimes the Product Manager is the business owner. Some companies view Product Managers as the liaison between Sales and Engineering, helping to define and refine product requirements and specifications.” Other companies use Product Managers as the scrum-master in addition to being a liaison between the business stakeholders and technical stakeholders.

The software and publishing companies have different stakeholders who are responsible for profit and loss (P/L), user experience etc… If this is the case then the product owner (who sits on the business side of the fence and is responsible for the P/L and/or the user experience) should be the person in charge of defining the product and the Product Manager can facilitate the discussions and decision between the team (technical stakeholders) and the product owners (business stakeholders).

I tend to view the different roles in scrum as an allegory to help me consolidate the lines of demarcation:

#1 The team is the Rock band – people pay to attend concerts to see and listen to the rock band.
#2 The product owner(s) are the fans – who pay to attend concerts, pay for the music and therefore ultimately determine what music is popular and what music the band plays.
#3 The scrum-master is the bouncer cum manager – they protect the band from over enthusiastic fans, make sure that no harm comes to them – book the gigs and makes sure that the band turns up on time.

So if your a Product Manager in a company who is about to implement scrum you need to ask yourself if what you do ultimately determines what music gets played or do you make sure the musicians play the right music. The answer to this question will determine if your the product owner or scrum-master or even perhaps proxy product owner.

See also:

How Agile is your Product Management

What do Product Managers do?

How everyone can get involved in agile

Read More

Part #8 Tips on being an Agile Manager

The agile manager must be able to constantly inspect and adapt in order to keep pace with a changing environment and capitalise on the changes as they occur. Here are 6 tips on ways in which you can inspect and adapt in order to improve the agility of your management and/or Product Management.

Inspecting:
#1 Agile managers tend to have an understanding of what is coming up – this occurs either by information that is cascaded to them from the board or Chief Executives or by anticipating future directions of the company and/or the market place.

#2 Agile managers seek to know the 'strengths' and 'areas that need improving, (weakness) of their team and the teams they work with - whether it's a virtual team (if they are matrix managers - as in the typical agile Product Management role) or those who directly report to them.

#3 Agile mangers strive to be better thinkers: they have the capacity to hold two opposing ideas in their head at once and then be able, creatively, to resolve the tension between those two ideas by generating a new one that has elements of the others but are superior to both.

Adapting:
#4 Agile managers are adaptive managers, they put people before ideas – they value people and ensure that they are placed in the best position for them to succeed.

#5 Agile managers adapt themselves and their programme to ensure that they remove the obstacles that are either slowing down their team’s performance or preventing them from achieving company goals.

#6 Agile managers find out what their teams expect of them and they ensure that their teams know what is expected of them – they then seek to remove any areas of potential conflict between the two in order to ensure that there are no areas of ambiguity.

The world, the markets we operate in, the companies we work for are constantly changing – the agile manager must constantly adapt themselves and their teams to ensure that they continue to function successfully in the constant changing and turbulent environment.

Read More

Part # 7 Points to watch out for when converting from waterfall to agile testing

Agile can be a challenge for the Test Analyst who has been trained and is accustomed to working in the traditional waterfall, Prince 2 environments or using the V model. A tester who finds themselves as part of “the team” using the agile scrum frame work can find that they are out of their comfort zone and may feel a little exposed. We recently held a meeting with a group of Test Analysts and asked them to identify what areas of our scrum implementation the needed to be improved and what areas they thought were going well. The key points identified are listed below.
Possible areas to Improve
50% said there were:

• No proper test management processes.
• Not enough sharing of information across the different groups (group = testers, product managers and developers).
• No re-use of test scripts across the different on-line products using the same backend systems.
• 25% said that:
• Being left out of emails containing relevant information to the sprint.
• Changing requirements half way through a sprint and not being clear on the actual change.
• Test work not being prioritised enabling the tester to know what order to test tasks in.
• Tester work is 1 to 2 sprints behind the development. (....Need to read the what done really means)
• 100% stated that:
• There was a lack of written requirements to test against, not enough detail in the requirements resulting in no real understanding on how a feature should work. Also a lack of forethought on features causes problems later on in th sprint.
• No formal tracking of defects: only the tester is using the defect log and changing the status.

Areas that are going well:

• 100% agreed that:
• Definition of sprint cycle.
• Sprint planning and pre-planning meetings.
• Communicating daily with developers.
• Good visibility as to what is coming up .
• Agile process being well implemented- everyone understanding the business benefits of agile.
• 75% agreed that:
  Close working with developers and business owners
• Good use of the impediment log
• Agile process being well implemented: everyone understanding the pros and cons of agile.

Tips for those new to the test agile role

If your thinking about joining a company, as a tester from a waterfall/Prince 2 background, that works in an agile way or your current company is planning to implement agile then I would recommend that you think about the following:

1. Make sure that you attend the sprint planning meetings and wear your 'Business Analyst' hat – make sure you gather requirements that will enable you to write short test scripts and therefore test each backlog item and task. If need be arrange (with the Scrum Master and Product Owner) a follow-up meeting to clarify the requirements.


2. Don’t be shy in raising impediments – it’s the Scrum Masters job to ensure that all impediments are removed so that “the team” can successful carry out their work. Impediments can include "I need more details on how this function should work."


3. Review, on a regular basis, the product backlog and create and maintain a query log that maps each backlog item – this will help you when your in the sprint planning meeting to ask the right questions at the right time.


4. Keep a defect log during each sprint - add those defects that are not cleared at the end of each sprint to the product backlog.
   

See also:
Agile Testing is not for Dummies
Agile requirements are barely sufficient!
Agile Testing
Why Testers should be in at the start

Read More

Part #6 How Everyone Can Get Involved in Agile

I mentioned in an earlier post that I was adopting scrum (an agile development frame work). At first implementing scrum identified quite a few issues (mainly bottlenecks) with in the organisation. However the past few weeks have witnessed a turn around – all of a sudden it seems that everyone wants to get involved and be part of the scrum process.
So how do you (as a ScrumMaster/Product manager) broaden the influence of scrum so that all the product stakeholders have the opportunity get involved at the appropriate points in time?

1. Make it easy for anyone (Sales, Product Marketing, Information Architect etc..) to contribute to the product backlog. This can be done by placing the backlog on a shared drive or document management system. I’m currently using SharePoint 2007 as an interim solution before we implement Team Systems.


2. Communicated the dates for sprint pre-planning, sprint planning and reviews along with the start and end dates for the sprints.


3. Invite those stakeholders whose backlog item(s) have been selected (during the sprint pre-planning meeting) to the next sprint and the daily scrum meeting.


4. Invite the same stakeholders to the sprint review where the selected feature(s) will be demonstrated along with the other features.

Some may ague that all the business stakeholders should communicate their ideas to the product owner and he/she alone should attend the various sprint and scrum meetings. However it has been my experience (to date) that the product owners are often too busy (not to say that Product Managers/ScrumMaster are not). Therefore assisting the Product Owner by implementing the 4 steps above will go a long way to ensuring that your implementation of scrum will be successful. The one key point is to ensure that the product owner takes full responsibility for selecting and prioritising the product backlog items.

Read More