Is the Product Owner part of the scrum team?

Michael James over at Danube picked up a discussion about whether the product owner should be considered part of the team. At first I thought he was saying no, but as I absorbed his points, I believe he was saying the PO is part of the team. Schwaber has come up with the term "scrum development team" to refer to the team without the PO. This point concerns me a bit... do we need other terms as well such as "scrum analyst team" and "scrum test team"? Why do we want to silo the team off?

The team is the team. It's everyone involved to deliver business value to the customer.

Not every member of the team is committed at the same level and the same way. How team members interact with their peers is important, and different people have different levels of authority when they speak. PO's have a stronger customer and market voice, usability and analyst roles have a stronger requirements and user voice, and developers have a stronger technical voice. But all voices impact each other so excluding any one from the group can be detrimental. Everyone on the team has to understand how to work as a team and not behave in ways that are harmful to the team. Just because a PO is a manager doesn't mean you should treat them that much differently when in the team circle.

What do you think?

Darth Vader was an agile coach too...

I swear I'll stop with the Star Wars references, but I'm not the one making these up and it is complete coincidence that they are back to back...

















Courtesy of Sebastian Bergmann on Flickr

Princess Leia was an agile coach...

Great article about managing, anxiety, stress, etc. Includes a Star Wars reference for the fanboys:

The problem is that the more we try to control, the more pressure we put on people, the less likely we are to get what we really want. Princess Leia said it best back in the 70's… "The more you tighten our grip Tarkin, the more star systems will slip through your fingers". The more we scream… the more we demand… the more we try to control… the less likely we are to get what we want.

Being anxious leads us to demand control. The more we try we try to control, the less likely we are to actually get the outcomes we desire.

It wasn't until after the fact I realized that Mike Cottmeyer wrote it. Met him at Agile 2008 and he's got some good ideas rolling around in that head of his.

It's Friday... I'm not going to add to this one, I'm just suggesting you go read it. It gave me some good food for thought, maybe it will for you also.

Don't create a terrorist...

Peter Stevens over at Scrum Breakfast had an interesting article about questions to ask your CEO about agile. The idea is in line with items I've pointed to previously around explaining agile, specifically Mike Cottmeyer's elevator speech used to grab a CEO's attention.

The item in his post that caught my attention though was around the topic of being "ambushed" which he described as:

... a peer (i.e. rival in the company) learned bad news about your project before you did and surprised you with it in meeting in front of all your peers. Very embarrassing. Operational staff often learns about an ambush through a very heated discussion with said top manager after the fact.

This reminded me greatly of something a prior (non-agile) mentor shared with me about being a good PM and dealing with a "terrorist".

A terrorist is someone who doesn't believe in the same side of a debate or cause as you. Typically it is cultural or political. They hide in the shadows. They wait to strike. (If we exclude the recent surge in suicide attacks, ) terrorism was originally an attack from someone that was in hiding to make a point (and hope to make it again and again until they win). Typically, a terrorist fought this way because they were in the minority in that situation and knew they might lose their cause if they fight out in the open.

You could easily imagine this general description of a terrorist as the group behind any number of bombs left outside any embassy... but you could also easily envision this terrorist as a co-worker that agrees with you in meetings with many peers but soon after seeks out a higher manager to undermine everything that has been said and done in that meeting.

Agile is a cultural change. On some level it requires a company to undergo political or organizational change. It's not uncommon to find people that can't fit within an agile culture. These people can quickly hide once they realize they are outnumbered by the peers around them that embrace agile with enthusiasm. You need to be aware of these people when you are driving agile coaching and transitions. One of my favorite quotes is from J.B. Rainsberger who says... "don't inflict change". Tying this to my other mentor, I believe that if you do inflict change, you are at risk for "creating a terrorist" in your organization. To Peter's point, this will lead to you being "ambushed".

My old mentor also said that once you create a terrorist, it takes a long time to overcome that problem. Sounds a lot like that Bin Laden problem, doesn't it.

Being a good diplomat and reaching out to build relationships with people that are least aligned with your intentions is a good way to create respect across areas of disagreement. I believe it is also imperative to dealing with the above issues. Whether you are driving agile changes, or any other changes... this is something I've found valuable to carry in the back of my mind.

Agile coaching help...

If you are looking for great coaching games within agile, check this wiki out.

I leveraged the balloon game and the coin game this week while running training in my company and it seemed to go well.

I saw a session with these guys at Agile 2008 and was impressed with what they are pulling together. Use and contribute!

Agile, where to start...

This is not the end-all-be-all silver bullet answer... but I answer this way because it is what others have shared, I have learned, and there is more support with these approaches.

If you are adopting Agile bottom-up from a tech team perspective... start with XP. If you are adopting agile top-down from a business perspective, start with Scrum.

And yes, at Agile 2008 in Toronto, during the keynote banquet Uncle Bob Martin basically declared that XP and Scrum need to unite and that they complement each other. I attribute this to the fact that XP focuses on engineering practices and Scrum focuses on PM approaches. Someone at ObjectMentor once told me that XP is the content and Scrum is the box it ships in.

Why is the previous in quotes? Because it was part of a discussion that I contributed to Peter Stevens description of what is agile after he attended an agile conference in London. I do agree with him that there might be too many flavors, many mis-applied labels, and that Lean is a great complement to the above.

Backlog Poker Prioritization...

Peter Stevens wrote a great post over at the Agile Software Development blog about how to tackle prioritizing your product backlog when starting a new project. He lists several approaches to this including:

Minimum Marketable Feature Set - the first pass to narrow the list of stories

Business Value First - Focus on High Value Functions

Bang For Buck - Go for easy wins

Technical Risk First - Do the hard things first

Defer Risk - Do the hard things later (or never)

Vote - Ask your users

He then provides an overview of each of these which I will let you read on your own there.

When he asked for other experiences, I mentioned the following:

We had a product where the backlog clearly could not be covered in the first release. Our customers were hospitals that didn't budge on "their needs".

We pulled our top 10 highest paying potential customers into one site and gave each one a bag of poker chips. They were asked to "pay" using their chips for certain features. They were told they could plop all their chips on one feature, or spread evenly across many.

As they saw each other "pay", they shifted their chips around. They didn't "waste" money where their peers didn't care, and they spread money to provide emphasis where peers needed help.

We walked away with a greatly pared down set of features that everyone was invested in (pun intended) and they felt like they were part of the process.

That's what we ended up building.