From the Agile Transformation Trenches

What is a Product Owner in Scrum

Scrum defines only three roles for particpants on a Scrum team; Product Owner, Team Member and Scrum Master.  In my experience, the Product Owner role is the least well-understood.  Some even call into question the need for this role at all on some projects.  I believe that "Product Owner" is a label for a cluster of responsibilities that may resident in individuals with such wide-ranging titles as "Procurement Manager", "Program Manager", "Product Manager", "Business Analyst" or "Chief Architect".  This role represents what a fast-moving development team needs to maintain maximum velocity while delivering maximum business value.  When I was asked to identify the key success factors for a Product Owner on a Scrum team.  This was my answer:

 

The core responsibilities of the product owner are:

• Be available (especially to the team) to clearly explain the product requirements and communicate exactly what will be acceptable to the stakeholders. 
• Have the authority and responsibility for consolidating all stakeholder needs into a coherent prioritized (and constantly re-prioritized) requirements backlog.

There are many supporting responsibilities that ideally are handled by the product owner, but may be handled by other supporting members of the organization as long the final decision, and responsibility for the results of that decision, rest with the product owner directly.  These include:

• Developing relationships with key customers and representatives of important market segments 
• Understanding the details of the problem domain that the product addresses 
• Understanding the technical trade-offs of various potential solutions and strategies 
• Balancing the timing of feature delivery to maximize cost/benefit over time 
• Coordinating the product strategy with collaborating products and teams 
• Coordinating dependencies and contributions between products for collective benefit

This requires strong leadership and negotiating skills.  Close trust-based working relationships with the team members is greatly beneficial.  Management and incentive structures must be in place to balance the desire for functionality with the realistic constraints on the resources required (especially time) to deliver that functionality.  This is most often seen in the form of "pressure" to deliver more in less time, with the implicit reduction of quality that leads to non-sustainable development practices and higher costs over the life of the product.

 

Here are links to a few online articles that add important details to this description.

• www.scrumforteamsystem.com/ProcessGuidance/Roles/ProductOwner.html
• www.scrumalliance.org/articles/44-being-an-effective-product-owner
• blog.lundak.org/2006/12/15/the-under-rated-product-owner-role/
• www.agilejournal.com/articles/articles/the-product-owner:-choosing-the-right-person-for-the-job.html

He's got a roadmap of Jupiter, a radar fix on the stars

One of my teams recently went through a session to develop a product roadmap, using a technique based on the teachings of Luke Hohmann in his book Beyond Software Architecture. A roadmap is the oft-forgotten second level of agile planning—vision being the first, and release planning, iteration planning, and the daily plan being the other three (and comprising the bulk of agile texts). The roadmapping process got high marks from everyone involved, and at many times it was great fun!

We’d allocated two days for the exercise and invited an even wider group of aspects than usually participate in our scrums: development, QA, documentation, product management, sales, usability, marketing... you get the idea. Numbering almost half the crowd, the engineers were by far the largest contingent. Most of the broader dev team is new to agile and had never experienced a roadmap session, and frankly were rather skeptical. They saw this activity as largely a Product Management (PM) function and were expecting to be bored at best, with two days wasted at worse. Instead, they found themselves engaged and active participants, helping to plan not only the individual features but the aggregate product itself.

Like many agile practices, the benefits of roadmapping were not predictably obvious. What looked to dev like a gathering where they were going to sit at the back of the room and text their friends while the PMs and marketing folks argued turned out to be quite interactive; even those folks that didn't speak up during the two days commented afterward how illuminating it was to "see how the sausage was made". Before the session, the engineers were not looking forward to the meetings; afterward, they are asking when the next one will be!

Post title is a lyric from Dreamline by Rush.

Please allow me to introduce myself; I’m a man of wealth and taste

I hate introductory posts like this. You either spout off a bunch of highfalutin precepts on what insights you intend to bring to topic at hand, or you create a long-winded self-congratulating biography. Neither are my style, but you gotta do something if you're the newest person to join a group blog, right? Maybe I'll do a Twitter-ish bio and hope that dropping the name of a trendy social network makes me sound cooler than I really am? Yeah, I think I’ll go with that.

My name is Michael Klobe and I am one of the growing number of contributors to Borland's Agile Transformation blog. I am a Longhorn football devotee, an avid reader, a family man, and of course, an agile development enthusiast. Here at Borland, I am the Director of Development responsible for the RDDM (Requirement Definition, Demand, and Management) products, such as CaliberRM and DefineIT. I’ve spent the last fifteen or so years working in agile or iterative development shops, and firmly believe that incremental progress in short sprints is a superior way to create software. A growing number of companies are seeing this as well and actually changing how they do business. Borland is in the midst of one of these agile transformations and I thoroughly enjoy being a part of it.

Whew—I’m glad that is over! Now we can get down to the interesting parts of discussing how agile really affects the software development process. Stay tuned!

Post title is a lyric from Sympathy for the Devil by the Rolling Stones.

Staffing Agile Teams - What to Look for in a Team Member

I read an interesting post about Scrum related job opportunities increasing and the author (Robin Pillay) posed three good questions to his readers:

1) Where do you see Scrum in 5 years time in organisations?

2) Every day I come across many candidates with no Scrum background that very keen to work for organisations that use scrum. The issues that I’m facing is many organisations always seem to want candidates from a Scrum background what would you recommend to candidates with no previous Scrum experience?

3) What changes have you seen working in organisations that use Scrum compared to organizations that don’t ?"

I want to look at question #2, since I think there is a parallel question: If I'm staffing a Scrum (or Agile) team, what do I look for in candidates who don't necessarily have Scrum experience? 

In my role as a ScrumMaster I've been involved in the interviewing process for many Scrum team members.  Often these folks don't have prior history with Scrum, so I first give them a quick overview (this picture is really useful).  A candidate without experience in Scrum should at least know how it works.  Mountain Goat and others have lots of good (and free!) introductory material.  For me, it's important to see that they've done that homework. Having some questions for the Scrum team on how well different Scrum practices work would be a plus for a candidate. 

After the overview, I like to see is how the candidate contrasts this description of Scrum with the way they currently work.  Do they seem leery of the change?  Are they reluctant to work in such a highly visible and accountable way?  Do they see benefits to Scrum from their current job?  Are they eager for the high amount of interaction with their team?  Will they pitch in to accomplish the goal or want to stay in a specialty?

It is also important to have lots of time in sessions with other team members.  Not only are the other members in the best position to assess if the candidate is technically excellent, but they also have a great read on how the person will fit in with the team.  Good teams are very vested in the hiring process since they know they'll be relying on this person to help them achieve the team goals.  The best advice I can give to the candidate going through this process is the tried and true "honesty is the best policy".  Don't try to bluff your way through since you'll be working really closely with these folks if you are brought onto the team.  Sometimes flexibility and eagerness are more important anyway.

Finally, some thoughts for those candidates who do have Scrum experience.  I'd expect to hear questions from them about adaptations the team has made to "by the book" Scrum, and for the candidate to be able to describe modifications their current team made over time.  This shows the interest in learning from retrospectives and a dedication to continuous improvement.

I'd be interested in hearing from others.  How do you assess candidates that aren't experienced with your methods?