Today’s topic peaked my interest as my company is currently hiring for Product Owners and Scrum Masters. Recent candidates have asked: “What’s the difference?” Also interesting, is the fact that the top 3 all time search engine term for this blog is: “Product Owner Job Description.” Today in particular, it happens to be #1.

There are many discussions on how the Scrum Master and Product Owner split their roles and responsibilities, and I’ve even read those who think they are the same person! (oh my!) Even more dynamic than the Product Manager and Product Owner roles, the relationship between the Scrum Master and Product Owner has it’s own set of professional responsibilities that contribute to team(s) success.  I’ve collaborated with Scrumbelina to come up with the below matrix that defines some of the differences and skill sets required to enable high-performance scrum teams.

Would love to hear your experiences as well!

Cheers,

–Jennifer

Are you an experienced Product Owner with cloud and platform service experience? Tendril wants to hear from you.

Tendril Product Owner Job listings

Check out all the openings, including Scrum Master positions.

Cheers!

In the beginning of the 2011, my organization had just one official Product Owner (PO). Now, kicking off 2012, we are 6 Product Owners strong, with 8+ scrum teams and advancing. That’s monumental growth.

As the PO team grows, it begs the question: “Should there be an official PO organization within the overall Product group?”

I don’t have an official response, as the real answer probably lies within the realm of your enterprise organizational infrastructure. But regardless of the managerial reporting structure, what I do know is that there needs to be a mechanism for POs to collaborate, learn, share, and grow their best practices.

With those specific goals in mind, we kicked off our own “Product Owner Club.” One of the ideas our first collaboration meeting resulted in was to test the inclusion of a new PO “communication trigger” to our overall scrum cadence.

Here’s the trigger: Meet once per sprint, just a few days prior to the end of the sprint boundary. This meeting’s goal is to succinctly identify and communicate cross team dependencies for a release, and specifically, the following sprint or one shortly thereafter. This is not the scrum of scrums, rather, this the mechanism that fosters healthy communication between POs regarding their detailed technical implementations and dependencies. Examples include: “We’ve identified that eventually, we will need a new API that allows for X, please bubble that up to your PM“, or “My team is now planning to deliver X in the next sprint, and is expecting your team to implement X in the UI in the following sprint, so we can ultimately deliver Y in time.”

Our first meeting alone identified many issues that we could address in the following sprint planning. While we expect to catch the majority of dependencies at release planning, inevitably things change, and this quick trigger helps catch that change along the way.

The PO Club also agreed to meet twice per month to collaborate, learn, share and grow our Product Owner best practices. At first, I wasn’t sure how the team would respond to “yet another meeting”, but in short, the idea was unanimously embraced. It blew me away how other POs are completely passionate about the role and it’s inherent responsibilities, and are willing to meet over lunch or dinner to grow the practice. It was also apparent that POs absolutely need to make the time to collaborate, as it’s too easy to get drawn into their own scrum team, without raising their head and talking and learning from other POs.

In that initial meeting, the makings of a Product Owner Manifesto was also brought forth. Below are the words from D. Lim, a fellow PO. I wanted to share, as if you are a Product Owner, you know exactly where he is coming from.

Product Owner Manifesto

• We know what the product needs to be
• We synthesize that into the stuff the scrum team must do and when
• We help drive the scrum team to do it
• We’re willing to wear the “target”
• We enable other POs to do the same

Please feel free to comment so we can grow and share our PO Club learnings with others!

Cheers!

It’s been a slow demise, but I definitely feel that email in the agile workplace is becoming more and more a followup tool than the pervasive corporate killer app it once was. Let me explain.

Our sprint kicks off in the typical manner, planning. This takes place in a room, with a web conferencing tool and face to face communications. No email.

Once we agree on the work, and work commences, communications still happen real-time, either in a chat room, or in person. No email.

If someone is blocked, I am informed they are blocked in either the standup, in person, or in the chat room. Email comes into play here as a followup, and only if I rely on a project management tool that has email notifications. But even that is after the fact, and hopefully the issue has been resolved before I even get to the email notification.

We do design reviews, architecture reviews, acceptance test reviews in person, or through our web conferencing tools. Email is only used here for notification of artifact locations or change.

Story acceptance happens in person, or through our web conferencing tool, and is celebrated in the same way. Usually high fives or explosive fist bumps are required.

All these scenarios assume your product owner is available to the team, which in my mind is one of the strongest attributes POs bring to the team; the availability to answer the 100′s of questions, issues, and clarifications that get raised on a day to day basis in an effort to keep product development flow moving.

So what has my use of email morphed into? For me, my email has become my own personal backlog of calendar notifications, random attachments, competitive information, event notifications and invitations, and personal notes. Typically, I read it early in the morning, and after the day has ended. I no longer rely on it for real-time management and support of my agile team(s). If my sprint needs attention, real time tools are best. My computer has become an orchestra of beeps, bings, chimes, and rings all notifying me real time that the sprint needs help.

There is one final essential use of email in agile. Remote teams on opposite timezones still relying on it for communication. Until we can magically fix the human sleep requirement, the real time tools just don’t cut it. I’ll work on that solution during my next sleepless night.

Cheers

I was informed this weekend of a tragic loss to our Agile community. Mauricio Zamora passed on Thanksgiving day. He was a founder at Scaled Agile Partners, a dedicated team of Agilists committed to sharing and scaling the benefits of Agile through the Scaled Agile Framework. I only just met him weeks ago, but was truly drawn to his passion, knowledge, and love for life and his family.
More here.
Life is too short. Share, mentor, continuously learn, and be kind to others. We are all connected in this small world.

Much love goes out to his family, friends and partners.

The importance of delivering high assurance software becomes more critical as your software products and applications become pervasive and ubiquitous, and human beings, communities, as well as the corporate infrastructures that deliver these products rely on their performance and quality to make critical budgetary, corporate, personal, or life decisions. Thus, the more users you have, the pressure to build software with proven development processes that enable the highest assurance for your users surmounts.

That’s a mouthful to digest, but the point is, when we endeavour on our career journeys to deliver great product via software, “high assurance software” is really the end-game, isn’t it? In the end, we want our customers to rely on our products to make decisions that better their lives, so that we can continue to innovate, and deliver product in which humans will trust, invest in, and use on a daily basis.

I wanted to point out perhaps the obvious, as Agile development practices that I enjoy blogging about are no longer viewed as “loosely structured” or “lightweight methods” that make developers jobs more enjoyable. Agile has become the most effective and disciplined way to build software to date.

To validate my rantings, I invite you to download and read Dean Leffingwell’s latest white paper: Agile Software Development with Verification and Validation in High Assurance and Regulated Environments.

Not to ruin the ending, but here’s a quote from the conclusion of the article, which perhaps will entice you to read the white paper from the beginning:

“Driven by quantified improvements in productivity, quality and employee morale, Agile software development methods are making their way into one of the last bastions of waterfall development: those industries developing high assurance software where the cost of defects and solution failures is insurmountable.

I just wanted to followup with a quick retrospect on our Flash Mob release from this year’s sprint:

• We reduced the scrum to 8 members, better communication
• Initial release planning went extremely well, and we were coding (dancing) in the 1st sprint
• The sprints only took 15 minutes to complete, with a total of 4 plus one hardening sprint
• Release velocity improved by 100% by reducing the size of the scrum and having a better understanding of the requirements
• The release had far less bugs! Take a look for yourself

PS: If you can’t identify me, I’m the ass!

Many thanks to all the dedicated product folks who demonstrated their commitment to finding better ways to deliver great product today by spending their Saturday at Rocky Mountain Product Camp.

Jennifer Fawcett introducing the talk

Catherine Connor and I presented two back-to-back sessions, the first being a Panel where we shared “Product Manager/Product Owner: Scars from the Horses Mouth.” Fortunately, we don’t have any photos or videos (ie: you had to be there) but we did foster engaging and honest discussions with the audience. I was honored to have my Product Manager and peer, Jennifer Jaffe join us for that session, and she added her great and heartfelt perspective as well.

Our second session was an “Ask the Expert” session where we introduced the audience the proven division of Product Management/Product Owner responsibilities that needs to happen to support the business when your development teams go agile.  The presentation was titled: “Product Managers and Product Owners: Cutting their Teeth,”  and attached for download here.

Catherine and Jennifer Presenting the Shared Responsibilities

Looking forward to continuously improving these presentations and sharing at future conferences! Let me know what you think.

Cheers,

–Jennifer

Last year, we took a chance on releasing a Thriller Flash Mob, just in time for our Halloween party. Being the Agile organization that we are, we pulled development and business stakeholders together, did release planning, themed our sprints, and released on time! Our customers were delighted!

Here’s a visual look into our plan:

Release Planning: Breaking down the stories. As you can see, there’s quite a bit of uncertainty about the knowledge of the stories at this time. We estimated the stories pretty high.

Sprint #1 - Laying Down Code. Now that we have a full understanding, we’re well into our development phase. Our burndown is looking good.

Sprint #2 – Integration. Feature level coding is complete, so we decided it was time to integrate into our backend (music). This was a high risk at first as our code wasn’t fine tuned in Sprint #1. But it’s going smoothly, and our velocity increased.

Sprint #3 - Final Bug Burndown. Our rehearsal helped flush out any final high-priority bugs.

Sprint #4 – Beta Testing. Final Beta, with real customers and costumes!

RELEASE! – Our customers were thrilled!

I hope you enjoyed this view of our release. We start planning for this year’s Flash Mob release on Monday.

Cheers

PS: Drew, this one is for you!

Be sure to vote for your favorite product topics at Rocky Mountain Product Camp next Saturday 10/29/11.

This particular topic seems to be a current favorite. Cast your vote for a lively and somewhat therapeutic panel targeted specifically for questions of Product Manager and Product Owners:

Product Owner and Product Manager Scars Directly from the Horses’ Mouth

Ask your questions to a seasoned team of product professionals who will offer their honest and sometimes different perspectives of both roles. A panel of product managers and product owners who have lived the struggle of effectively performing all the necessary product management functions when development goes Agile. Bring your hard questions about the product owner role, the product manager role, and product marketing roles, accountability for each, challenges, egos, and how they deal with them. Panelists will share tips to avoid the pitfalls agile brings to product management, and their experience overcoming the challenges.

Hope to see you there!