Product Owner and the Scrum Team

On March 11, 2014, I presented a talk to IIBA Baltimore on the topic of the Product Owner and the Scrum Team.  I have to say, this was an awesome bunch of people to talk with.  You know you're at the right place when they offer beer and crab cakes with dinner.  Gotta love Charm City! The last 10 years of Agile have focused on the team. I believe the next 10 years of Agile will focus on the enterprise. That said, should the Product Owner continue to be a single person or does it need to evolve as well? Let's cover the basics and then see how LeadingAgile has been successful at leveraging the Product Owner role at scale.

The product owner and the scrum team. Can one person do this at scale?

As a thank you to IIBA, I was able to get a promo code for 50% off an upcoming Agile Requirements Workshop. The code "IIBA" is limited to only 5 seats.  Are you a business analyst in the Atlanta area or want to go visit some friends in Atlanta?  Take advantage of this limited offer.

Cheat Sheet for Backlog Refinement

Backlog Refinement Meeting

What is it?

The purpose of backlog refinement (grooming) is to make improvements to the product backlog.  Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.

Who does it?

Backlog Refinement is a collaborative effort involving:

• (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal

• (Optional) representative(s) from the Management Team – clarify the high level priorities

• (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items

• (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items. It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

When is it?

Before development of a user story in the current sprint (iteration), generally sometime during the previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale. Depending on the delivery rate of your teams, you should be meeting once or twice a week to review the backlog.

Before You Begin

We need to ensure:

• The product backlog is top-ordered to reflect the greatest needs of Management Team and the Product Owner Team

• Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research

• Epics, features or other items on the Management Team roadmap are reviewed periodically

The Backlog

The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when using Scrum as the delivery framework, product backlog items must be small enough to be completed and accepted during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner team.

Estimate

Backlog items must be completed in a single sprint or split into multiple user stories. While refining, give stories an initial estimate to see if they are small enough. If not, split them. The best way to split product backlog items is by value and not by process.

Acceptance Criteria

All stories require acceptance criteria. Without it, you can not define the boundaries of a user story and confirm when a story is done and working as intended. Ensure acceptance criteria is testable.   This is what your testers should be writing tests against.

Rewrite Written Stories

Ensure the user story format is consistent, INVEST criteria is being met, and is written from a business not technical perspective.  Know who the customer is. It may not be an end user. Rather, the story may be for something like a service, to be consumed by another team.

Image Credit: Pictofigo

Originally Posted at LeadingAgile

How to be Successful with Agile at Scale

Ever asked yourself how you could be successful with Agile at scale? Let me show you how we've done it at LeadingAgile. In this one hour session that I presented to the PM Symposium in Washington DC, I explained how we've been successful by focusing on culture last and predictability first.

What is Fist of Five?

Why

It doesn't matter if I'm teaching a class or coaching a team.  When the moment comes, I need a quick way for a team to come to a decision.  Why should the team decide and not me?  From the seven standard leadership styles, I see consensus as the most appropriate for an empowered team.  If the team is not empowered, they are not an Agile team.

How

When a decision has to be made, ask the team to do a fist of five. All the team members raise one hand to vote with their five fingers (unless they've suffered an accident in shop class).  I depicted in the Fist of Five Pictofigo drawing, member votes range from a fist to five fingers.  The term fist to five and fist of five are interchangeable.

Explaining the Details

• I see a fist as a blocker. This individual is in complete disagreement and further discussion is required.

• One finger (preferably not the middle one) has minimal support to the request at hand. Again, discussion is required.

• Two fingers. Not happy with the current proposal. Should discuss as a group to try and resolve disagreements.

• Three fingers. Luke warm response. May go along if the rest of the group is voting three, four, or five.

• Four fingers. Pretty much agree with the request. There is some apprehension but you can't expect everyone to be all in all the time.

• Five fingers. Full support. They drank the Kool-Aid

Certainly, the success of this strategy is going to depend on the team employing it.  There will be some who just like to hear themselves talk and will throw up a fist, one, or two every time.  Hear them out!  You'll also have those who don't like to commit to anything.  They will generally put up three fingers.  Whatever the outcomes, try to keep a strict timebox for discussions.  Remember, this was to be a quick way for a team to come to a decision.

I would be curious to hear when you use fist of five, your successes, and your failures.

Image Source: Pictofigo

Retrospective Shades of Gray

The Retrospective

I love retrospectives.  It doesn't matter if it's an informal process that occurs naturally as team members interact or it is a formal process that occurs at the end of a meeting, an iteration, or a release.  It's an opportunity for the team and organization to make things better.  It most certainly is on the minds of others today.  I've read about the goals of a retrospective on George Dinwiddie's blog and also retrospectives - wronger and righter on Bob Marshall's blog.

I honestly believe we should be constantly looking for things to start doing, stop doing, do less of, do more of, or keep doing to improve the things we do.  I have been a part of projects where a Lessons Learned meeting was part of the Project Closeout activities.  What good is it then!?  We should constantly be learning and constantly trying to make things better.

Shades of Gray

Depending on the team, I may use the four-quadrant grid, starfish retrospective diagram (or both) to capture ideas. I love the format of the four-quadrant grid, in that the team can communicate what is working, what isn't going so well, any ah-ha moments they've recently had, or appreciations they would like to note for their teammates. Unfortunately, just as some organizations or teams think of writing documentation as an afterthought, I see them doing the same with retrospectives.  Retrospectives are a critical component of any process.  Without them taking place, you are pretty much guaranteed to make the same mistakes twice, a third time, ad nauseam.

retrospective starfish

When to do it

Don't wait until the end of your current iteration, release, or project to document and improve.  On a team board or flip chart, draw a circle.  Segment the circle into five quadrants: Stop Doing, Do Less, Keep Doing, Do More, Start Doing.  Please note that these are merely recommendations.  The content and order are not retrospective commandments.  Have a stack of Post-It notes and a Sharpie nearby. Encourage the team to add notes to the board when the mood or event strikes them.  Don't wait!

If you struggle to get cards on a regular basis, perhaps a facilitated retrospective is in order.  The act of collecting ideas is not just to make people feel better.  Notes captured on this board are all candidates for conversion to action items.  If you have the fortunate problem of having too many ideas on the board, use a consensus strategy like fist of five or dot voting to identify the most valuable action items.

Keep Doing (=): Capture good things that are happening. As a facilitator, ask the team what they would miss if something was taken away from them.

Do Less (<): Anything that might need a bit more refining or that is simply waste.  Is there something that adds value but not as much as something else could?

Do More (>): Are there value-add activities the team may want to try more of but are not necessarily taking full advantage of?

Stop Doing (-): What are some things that are not very helpful or not adding much value?  My prime target is long formal meetings.

Start Doing (+): Suggest new things!  You read or heard about something that helped others like you.  What do you have to lose?

Hawthorne Effect Coaching Dilemma

The Hawthorne Effect is something I wrote about over a year ago.  Previously as a Project Management Adviser and now as an Enterprise Agile Coach, I've seen it numerous times.  To all those currently advising or coaching, do you tend to see clients trying to impress you? The Hawthorne Effect refers to the tendency of some people to modify their behavior, when they know they are being watched, due to the attention they are receiving from researchers, auditors, or coaches.

This effect was first discovered and named by researchers at Harvard University who were studying the relationship between productivity and work environment. Researchers conducted these experiments at the Hawthorne Works plant of Western Electric. The study was originally commissioned to determine if increasing or decreasing the amount of light workers received increased or decreased worker productivity. The researchers found that productivity temporarily increased, regardless if the light was increased or decreases. They then realized the increase in productivity was due to the attention given the workers by the research team and not because of changes to the experimental variable.  (Thanks Wikipedia)

This is one reason short term engagements can be challenging.  People are on their best behavior, until they get used to you being there.  This is also why I don't believe in annual reviews.  How do you, as managers, leaders, coaches, or auditors get past the effect?  How do you ensure you get a true representation of individual and team behavior and not suffer from the Hawthorne Effect?

Image Source: Pictofigo

PMI Eating its Own Dogfood

I am happy to report that the PMI-ACP Community Guide project is off and running.  Each day, I see new content being added.  I wonder if this is how Jimmy Wales felt in the early days of  Wikipedia.  Our first measure of success is to get the content of each page of The Guide as close to the vision of the ACP Steering Committee as quickly as possible.  Our second measure of success is to reach a tipping point, whereby the community (not the support team) is maintaining the guide.  Remember, future versions of the ACP exam will be based on this Guide.

Community Guide

To reaffirm, there will not be an AgileBOK.  The Community Guide of the PMI-ACP (login required) is an initiative of the PMI Agile Community of Practice to provide ongoing support for the PMI-ACP agile certification.

ACP Support Team

Lead by Joseph Flahiff of Whitewater Projects and myself, the ACP Support Team has kickstarted the Community Guide content creation process.  We are empowered and 100% self-organized.

The Backlog

In order to deliver something of value to the community, Joseph and I leveraged the wiki within PMI's website to create a Product Backlog.  We wanted transparency and for everyone to know what we are focused on.  Every major area of the ACP exam has a page waiting to be edited. If you had a traditional product backlog, the 10 major areas that comprise the Tools & Techniques of the exam could easily be considered Epics.  Each page of our wiki could be compared to a User Story.  We're not estimating our work.  We're just doing it.

Iteration 1

We are currently in Iteration 1, which ends on May 10, 2012.  Of our 15 member team, we asked volunteers to commit to work on the first 7 pages of the first content area.  At the end of each iteration, we can ask members of the ACP steering committee to review what we have done.  It's important that we stay focused, have short feedback loops, and deliver something of value on a regular basis.

Eating the Dogfood

When you think of PMI, you probably think of project plans, schedules, and stuff like that.  As a self-organized and empowered team, we decided what is important, to increase the chances of our success.  Though there should be a predictable date of completion, based on the currently defined deliverables and length of the iterations, we're prepared for things to change.  We may have to rework some of the pages.  We may have some team turnover.  Regardless, we can guarantee we will deliver value on a regular basis.  We can guarantee there is collaboration with the community.

Joining the Team

If you are interested in creating or maintaining articles for the Community Guide, join our team!  If you want to work independently, we welcome your valuable contributions.

Measuring Team Emotion

Too many times, companies focus too much attention on metrics like Team Performance and Team Efficiency, while ignoring metrics like Team Emotion or Happiness.  This last week,  I worked with a company and team which did not make this mistake. At the  conclusion of the iteration, they held a retrospective. As noted on a previous blog post,

a retrospective meeting is held at the end of a scheduled event or time interval. With the aid of a facilitator, a team discusses what went well and what could be improved during the next interval or prior to the next scheduled event.  The meeting is time-boxed to help ensure it doesn’t just turn into an out-of-control complaining session.  When properly facilitated, you come out of the meeting with an actionable list for improvement candidates.

At the conclusion of the team retrospective, it was time for the final task of the (2-week) iteration.  It was time to know how the team felt.

As you can see from this Cacoo drawing, the team was happy during iteration planning and the first week of the two-week iteration.  Things didn't go so well during the  second week or the Iteration Review. I was there during that meeting and not surprised they voted as they did.  What is telling from this diagram was their feelings of the actual Retrospective meeting.  They were very happy.

During the Retrospective,  the team discussed how they could make the next iteration (and Review) better.  It was a really healthy and productive conversation.  There was no blaming.  It was all about "how can we as a team do better?"

In closing, find out how your team feels.  You may be surprised how team performance and efficiency improve when the team is happier.  If you want true process or team improvement (Kaizen), track your feelings as well.