The dirtiest pig in Scrum – The Product Owner

Your Scrum Product Owner

Scrum often makes reference to a classic joke regarding a pig and a chicken. The chicken wants to partner with the pig to start a restaurant. The pig says, “No thanks” to the chicken because the pig would be committed while the chicken would only be involved. The Scrum world typically defines a Scrum team as a team of pigs.  The chickens are all the other “stakeholders” that don’t have their own skin in the game, and are not members of the Scrum team.

I recently participated in an ongoing debate by several members of the Scrum Practitioners group on whether the Scrum Product Owner should be an active member of the team. For those of you that are not as familiar with the title, the Product Owner is usually one person who is accountable for the product. This role usually is, but not limited to, a product director, product manager, or business development resource. Where does your Product Owner fit? Are they a chicken or pig?

A Team of Pigs

Scrum typically defines the product team as:

ScrumMaster – This person facilitates the objectives of the team and remove obstacles.
“Product Development” Team – The software developers, designers, testers, etc. who build the product
Product Owner – The person who define user stories, set priorities for the team, and clarifies questions from the rest of the team.

The UI/UX designers and technical architects are sometimes included and sometimes not (a topic for another day).

The Scrum Product Owner is the dirtiest of the pigs.

The Product Owner is the single “wring-able neck” for the product. They typically are responsible for the return on investment (ROI) and will be answering to the executives and business partners if something goes wrong. So it benefits everyone to have an active product owner in the process.  I would recommend that your Product Owner attend the daily stand-ups. He or she should keep quiet unless someone has a question or someone is not following the plan (even then, bring it up with the ScrumMaster). The P.O.’s goal at that daily stand-up should be to find out when/if something is off target as soon as it happens and to answer any scope questions that come up from the team.

Other than that, I would imagine most Product Owners will be too busy to engage in other activites during a sprint. They should be too busy with their other responsibilities. The Product Owner most likely will be busy coordinating with the chickens, preparing the next sprint, helping define test cases, and ideally working with the business to get feedback from the product user base/market.

Shouldn’t the ScrumMaster protect the team from the “business?”

Some of the issues raised during the debate centered around the notion that the team should be left alone to work. Disruptions and unnecessary change are things to be avoided, the argument goes. Questions arise like:

• Why should the Product Owner have any involvement with the team?
• Shouldn’t the P.O. just write the user stories and go back to their “business work?”
• Isn’t the point of Scrum to isolate the team and “put them in a bubble?

The goals are admirable, but I caution against those attempting to place their development team in a protective bubble. I counter those questions by asking:

• Why are you doing Scrum instead of Waterfall?
• How can you be agile and adapt if a core member of the team disengages?

You need to be able to adapt to change. You need to know when you are off course. You should want to have a development team that understands what they are building and why they are building it. The goal of Scrum is to achieve business value by repeatedly inspecting and adapting as you learn. You should isolate the team from changing requirements and interruptions, but not from outbound requests for clarity.

In an ideal world, user stories would be written perfectly, sprint planning meetings would deliver a nirvana of understanding, and there would be no need for questions or change. But that premise of “perfect enlightenment” is the same weakness of the Waterfall model.  Learning happens after sprints and releases, but it certainly happens during the sprint. If you want to maximize the team’s potential, you need to course correct at the first sign of trouble (This is more a Lean principle than a Scrum one).

There’s a class for Product Owners??

Most people that are familiar with Scrum know about the ScrumMaster role. The Scrum Alliance does have a Certified Scrum Product Owner (CSPO) class) as well. Some organizations, out of necessity or ignorance, will combine the two roles. I have seen it done, I have done it, and while it can work, it’s not ideal. The ScrumMaster is there to protect the team. The Product Owner is there to protect the product. When the two come into conflict, will one person be able to balance both of those responsibilities?

If your organization is implementing Scrum, I highly recommend that your product owner be CSPO trained. Your product owner is accountable to your development team, and vice-versa. It is essential to have a Product Owner that understands their responsibilities in building software.

Finally getting Twitter…It’s about “community” stupid.

This is not, I repeat, not another long diatribe on what Twitter is or how it’s better than Facebook (it’s not, it’s just different). Though I may attempt to cover those topics in a succinct manner at some point, it won’t be today. There are so many blog posts on the topic, and most of what they have to say becomes self-evident when you start to use those services on a regular basis.

Many of my real-world friends have asked me what Twitter is. And while saying “It’s Facebook status without the rest of Facebook, is true from a technical standpoint”, I can see how inept that description is, and how it’s the wrong question to be asking. The right questions to ask are “How can I use Twitter?” and “Why should I care?“

What “it is” will be determined by time. But I think I am getting what it should and should not be.

• It should not be about endlessly spamming people with your bitly tinyurl blog link to build RT’s and page rank.
• It should not be about getting a 20-to-1 follower:following ratio.
• It should not be about a one-way dump of information
• It should be about posting interesting (and hopefully original) content
• It should be about fostering a dialogue (even in 140 characters)
• It should definitely be about building some semblance of relationships with the people in your network so that they stay engaged and so that they return the favor by keeping you engaged

Ultimately, my hope is that a system will emerge (much like Google search) that promotes the good twitters with compelling content.

Thanks to @MarketingJobsDC and Maddie Grant for helping me see the light.

Change you can adapt to…

Kaypro II - old school

First!!!

Oh, wait. It’s my blog. I should have remembered that. I came here to write about technology. How it gets built, when it turns into something great, when it sucks, and how to make it useful.

I think I’ve been a technology freak since I came out of the womb. When I was 7, my dad had this Kaypro II (left) that he used for work. When he took breaks, I would load up the 5 1/4 disk and play Ladder (text Donkey Kong). I also wrote a small program in BASIC.  It was nothing fancy…just some print statements, and an if/then loop I think. I was trying to simulate space invaders (<<**-O-**>> was the ship), but you couldn’t actually do anything except watch the loop. Anyway, that’s how I became hooked. There were Ataris, Logo, Commodores with tape drives, and somethings I can’t remember, but it all started with the Kaypro II.

I’m sure by 1982, I had played video games in other places, but the Kaypro was different. For the first time, I could see how the game was made. The cconnection between inputting some code and getting meaningful results was amazing to me. I think it ignited a creative spark that made me want to understand the technology. That lead to some pretty elaborate Logo programs in 5th grade (a ship that disappeared in the fog), modifying Microsoft’s DOS operating system with a HEX editor with friends in junior high school, and so on. I’m not sure how, but I did manage to get outdoors with friends from time to time.

Fast-forward to 1997. Four years prior, I had all but given up on Computer Science in college. I could code pretty well, but I found the long hours in the computer lab on the opposite end of campus and Friday morning quizzes incompatible with the lifestyle I wanted to lead. I was more interested in business and politics at the time, but I needed to work. I found myself at IBM working as a remote system administrator. Despite my reluctance to get back into computers at the time, it was a great opportunity to learn both business and technology and paid pretty well. Plus it was in West Palm Beach, FL. From there, I formed a solid basis on the technologies of the day during the first Internet boom.

Today, I am preparing to leave a Software-as-a-Service (SaaS) software company that I joined as it was just starting out, and the upcoming departure is probably the reason I am writing this blog. It has all come full circle for me from the Kaypro II to creating web applications. When it is done well, the process may be hell. but the finished the output can be art.

This will probably be the last “Wonder Year” post of mine for a while. The main focus of the blog is to write about software (and occasionally hardware) that I find compelling, the adoption of that software, and processes that I have been involved with to make software. I am a big practitioner of Agile Software Development and Lean Software Development, not just as a practice, but as a philosophy, so expect to find the occasional post on that as well.

Thanks for reading!