Scrum and the Product Owner – Can you do without one?

The Product Manager has always been an important role for any product development company, whether your product is a car or a piece of software. The product manager manages one or more products, and shapes its creation right from concept to design to creation and production. This is what Wiki tells us about the product manager.

Any software project has a customer or sponsor who hails from the ‘business side’. What this means is that this person knows the company’s line of business and products inside out, and more importantly has a direct line to the actual customer or end-user. That may be why this individual is sometimes referred to as a ‘customer proxy’. Knowing your customer then is key to establishing what your target market segment is, where your product should be positioned, and indeed this will not only drive what features your product should have but also what the product itself should be.

Agile or Scrum has the Product Owner to perform this function. As any basic text on Scrum will tell you, the Product Owner is an integral part of the Scrum team. The product owner is responsible for the success of the project and has to ensure that it delivers appropriate returns on investment (ROI).

Roman Pichler offers a pictorial depiction of all the duties of a product owner. He also suggests that the product owner needs to be in the driver’s seat all the time.

Jack Milunsky sums up the product owner’s activities nicely.

Following are what I feel are some of the desirable traits of a product owner –

1)      Be 100% engaged

It may not be feasible to physically be with the team a 100% of the time, but a product owner should certainly be available to the team via phone, email, chat etc. This will encourage the team to raise flags instantly and resolve backlog related questions early on, saving a lot of time – a critical entity in a time boxed sprint.

2)      Product backlog champion

The product owner owns the product backlog, and needs to know it inside out. (S)he should also work on it constantly to keep it up to date. The product backlog should reflect the latest customer priorities for the product, or critical product features at any given time. Ordering (or prioritizing) the product backlog is another crucial task for the PO. This should happen continuously even during a sprint, so that extra time need not be spent on the backlog during the next sprint planning session.

3)      Own the product, be tuned in

The product owner is ultimately responsible for what happens to the product and hence for the outcome of any sprints/projects of the Scrum team.  The product owner should be aware of all daily updates, burndown etc. and have a clear picture of where the team is headed at any given time. The product owner should be able to cancel a sprint if needed, and should also be able to steer the team so that they continue to work toward delivering the sprint, and hence the product backlog items.

4)      Subject Matter Expert

The product owner should know the minutiae of a given product line, its features, the importance of each feature, user behavior, drivers for certain product attributes etc. etc. In short, the product owner should be a veritable encyclopedia on anything related to the product. 

This is necessary to establish trust and rapport between the developers and the product owner. Just as consistent velocity and successful sprints will establish the skill of the developers in a Scrum team, in-depth product knowledge and ability to get questions answered will establish the skill of a product owner.

Practically, there may be a learning curve even for a product owner, assuming an otherwise skilled product owner who has taken on a new product.

5)      Willingness to learn

It is quite difficult to be as omniscient as Yoda! A product owner should exhibit a willingness to learn. He/she should not hesitate to ask questions as needed. They could be product related questions for which the product owner needs to elicit information from multiple sources, or could also be process related questions that a Scrum Master can answer, or something related to the dynamics of the development team.

6)      Collaborative and communicative

Collaboration is the cornerstone of any Scrum team. The product owner should be an eager participant in any discussions related to stories or backlog items, since their comments can change how a particular item is built. This can result in cost savings even within a 2 week time boxed sprint.

The product owner should not hesitate to deliver news – both good and bad – to the Scrum team. The product owner should be friendly toward the team, and be able to embrace the ‘everyone at par’ mantra of Agile. The product owner should also be patient and take a back seat when needed, allowing the team to self-organize.

The product owner should happily co-exist with the Scrum Master, and if needed heed to the SM’s feedback regarding workload, team morale etc.

This is by no means an exhaustive list. Jim Trott provides a good list of necessary attributes of the product owner. 

A product owner may need to apply different strategies for success depending on the industry, the product itself, timelines, a particular team etc. But one thing is certain. The product owner is the driving force behind any Scrum team and an integral part of one.

To sum up, a product owner is a liasion between the end-user or customers and the Scrum team, and serves as a nexus or conduit. A good product owner will have not only the pulse of his target customer, but also that of his Scrum team to deliver optimum value to the product/organization.

Collocation – how Happily are we doing it?

The Agile Manifesto values ‘Individuals and interactions over processes and tools’. Great importance is given to open and frequent communication in any Agile methodology such as Scrum. And a very effective way to bring it about is collocation. Webster’s defines this as 'the act or result of placing or arranging together'. Team members are brought together and placed in physical proximity in a room or closed area to break down the proverbial walls and foster camaraderie resulting in much higher synergies. A lot of studies show that collocation does hike productivity. Kane Mar at Scrumology writes about this here and also mentions a detailed paper that measured how radical collocation helped increase productivity in a renowned automobile company.

Most of you have tried this and probably reached a steady state where you are at peace with where you sit, in how much space, next to whom etc. and can finally concentrate on your work. But we all remember what an uphill task it was. So imagine you are used to sitting in your own fair sized cubicle, you’ve got your stuff around you making you happy – the wife and kiddies smiling from a silver frame, glimpses of that Hawaiian vacation, the memorable Disney cruise, a nice bamboo or fern you gave a home to, coveted books for ready reference, snacks stashed away in that bottom drawer, maybe you even make your own coffee at your desk (yes) – you get the idea!! Then you are suddenly transported to a 12x15 ft room, with no windows (shudder), shared with 10-12 people and a bunch of whiteboards for walls. It’s a tough transition for anyone, and can rattle the best among us.

Some of the typical teething problems newly collocated teams face are –

-          Lack of personal space, sudden proximity to a lot of people

-          No ‘privacy’ and ‘under the radar’ all the time

-          Lots of discussions that may not be relevant to you leading to noise

-          Lots of chit chat and trivial chatter – enjoyable to some, others, not   so much

-          Put ‘on the spot’ several times a day, need to give constant and instantaneous input on any questions

-          Risk of infections, people picking noses, sneezing on you etc. ( sad but true)

-          People making personal calls incessantly etc. etc.

               

The list can be a mile long, but as your neighbor becomes more familiar to you, you don’t notice the clashing elbows so much. Your sprint reviews show you how much work you are getting done in a miraculously low amount of time, and you get so used to thinking out loud, extrapolating and constantly questioning everything that it becomes second nature.

As trust builds up, people come up with their grievances at retrospectives and eventually this leads to better and more spacious workspaces, common team rules, core hours, off hours etc. making you happier.

I have faced this trial by fire ( what else to call it?) myself several times and would like to share my experience and my two penny worth. Here are some small ways to ease the transition into collocation and minimize some of the resistance and problems people face –

• Food, food and more food!! Yes, lots of talk means lots of munchies coming on, and any customer that provides it is a hero. Here is a blog post that talks about it.

• Team events where people get to mingle – maybe a day out having fun, or Happy Hour or an evening at the bowling alley or movie night. This gives folks a chance to interact away from the office environment and connect at a personal level.

• Name your team – cheesy? Not really! Be it the Lakers or Man United or the Kings XI, each team has its own identity, values and reputation to live up to. This certainly fires up the troops and they are ready to take on any battle (backlog) that comes their way.

• Team Rules – some basic stuff like no cellphones during meetings, core hours, person missing the Scrum gets Donuts, work remotely when sick etc. – anything that makes sense to you as a group.

• Information radiators – loads of whiteboards, flipcharts, colored pins, markers, post its, index cards, colored dots to portray your backlog, your work in process, your work ‘done’, burndown charts etc. etc. Frequent looks at what you have achieved so far is a HUGE motivator.

• Fun stuff – who said you can’t have a bit of fun? Dart boards, mini baskets, stress busting gizmos, silly toys – anything that lightens the mood and makes you laugh.

• Headphones – a great way to tune out some of the ambient noise and focus on something. They can also indicate that you would like not to be disturbed for a while.

• ‘Do Not Disturb’ or Silent zones or enclaves close to your team space, for those times when you just need to be heads down and work on something by yourself.

• Windows!!! This may not be possible all the time, but they are really your window to the world, especially when you work in a wooded campus with tall trees, really tall trees, with leaves turning in the fall, and snow sticking to the bare branches in winter…ok, I digress, but anyone will agree, even a small window is better than no windows!

This list can go on and on too. This is what is my experience and what made sense to the several teams I worked with, and this definitely did not happen overnight. It took a lot of angst, tears, patience, retrospectives and last but not the least, Scrum Masters and Agile coaches who carried our voice over to the top, to the folks who dish out goodies like prime retail space.

And you will need to be bold too. You will need to speak up, bond and come together as a unit and decide what spells utopia to you! What’s going to make your workspace so warm and fuzzy that you will feel like the Energizer bunny?

So how are you handling collocation? Are you still running the rapids or in your happy place? Whether a Scrum Master or a team member, how are you dealing with resistance from your team and peers?

This post deals with collocation for teams that are mostly in the same location. How do distributed teams handle this? Thats another topic for another day.