Product Owners can Prioritize their Stakeholders

The product owner role is a critical to the success of an agile team.  Scott Ambler describes the product owner role as a Stakeholder Proxy for Agile Teams. "The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team." Scott Ambler further illustrates this with the following image:

Scott Ambler's Role of Product Owner

If you are a Product Owner and you struggle to partner effectively with the various stakeholders in your company or organization, rest assured that you are NOT alone. Depending on the product you responsible for and size of your organization you may have numerous stakeholders and need to develop ways to coordinate among so many people. We all have limited time, so we need to determine how to invest your it most effectively to deliver value. In traditional project management, a suggested technique is to prioritize stakeholders based on their influence and interest so you can identify who you want to manage closely, keep satisfied, keep informed, and monitor with minimum effort.

The problem with this approach is that it is a power grid and emphasizes a stakeholder's influence, instead of knowledge or value, that a stakeholder can provide to a product owner and agile team.   It positions the stakeholder as a power broker that the team serves, rather than a partner who works with it the team.  


I like the concept of a simple matrix for prioritizing stakeholders, however, I choose not to use the power or influence of the stakeholder as an axis.  Instead, I modify the grid to focus on the value the stakeholders can provide the team.  I define value as knowledge that can take many forms.  It could be domain expertise, understanding of customer needs, business acumen, technical know-how, and the list goes on.   
  
My form of the stakeholder prioritization matrix looks like this:

• High Knowledge / High Interest = Stakeholders that you partner closely with
  These are the stakeholders require little effort to involve and willingly work with the team.  As a product owner, I identify touch points (development / updates to product roadmap, prior / following release planning, during backlog grooming sessions) to keep these stakeholders in the loop and often seek their counsel.  
• High Knowledge / Low Interest =  Stakeholders that you consult with (and try to move to high interest category)
  These are stakeholders that you want to involve but they are either too busy, or may not (yet) see the value to them helping the team.  I seek to convert these stakeholders to willing partners (i.e., high interest) by .   I seek  
• Low Knowledge / High Interest = Stakeholders who you keep informed
  Agile teams believe in transparency.  I believe demos should and any communication of team progress should be made available to anyone who is interested.  You may discover that one of these stakeholders deep knowledge in an area that you were unaware of.
• Low Knowledge / Low Interest = Stakeholders who have an open door in get more involvedThese stakeholders are welcome to attend demos or express interest in becoming more informed, but I don't go out of my way to involve them.

If you have a number of stakeholders and find it difficult to keep up, this technique might help you prioritize your efforts accordingly.  While this post is geard at Agile product Owners, it is useful to others who work with Stakeholders on a diaily basis.  

Example Working Agreement

When a new team forms, it is important from them to consider how they want to work together.  A technique for developing a shared understanding is to have the team co-create a working agreement.  There are many ways to approach this exercise, but it is important that each member have an opportunity to share what they feel will enable the team to be effective and happy working together.  Esther Derby  describes working agreements as "focused on amplifying desired patterns of behavior" and "aimed at helping the team achieve their task and team-work goals." in her post: Norms, Values, Working Agreements, Simple Rules.   Working agreements help teams surface shared values and address what could be issues before they happen.   


A working agreement is an artifact that should be shared publicly and referred to by the team.  It is not a static document.  It should be updated periodically, perhaps during retrospectives. The following is an example working agreement that evolved with a team that I am working with.  I share the following as an  example of what one team came up with.  It is not a template.  I believe working agreements need to be developed together as a team, as they should be tailored to the specific dynamics and needs of a team, and are likely influenced by the culture of the company..   

Sample Working Agreement

Always

• Product Owner is responsive to team requests for information
• Team will close higher priority stories first.  To do so, we limit the number of stories in progress at any one time.  NOTE: Rule of thumb is to put as many people on the highest priority story that is still efficient.
• Team members use information radiators (sprint burndown) to help determine whether we're on track with commitment.
• All agile ceremonies are time boxed. This means that they start on time and end on time. To maximize the effectiveness of these ceremonies team members show up on time and are committed to being completely focused and dedicated to the task at hand.
• We use the retrospective to continually inspect, adapt, and therefore improve our work together.
• Core hours are established between 11:00am and 4:00pm where no non-agile meetings with Team members maybe set up. Informal conversations between team members are ALWAYS fine. 

Planning

• We believe in in the value of planning collectively as a team 
• Product Owner respects teams estimates coming out of release planning / sprint planning
• Product Owner keeps the backlog up to date. 
• Team contributes to product backlog in advance of planning sessions.

During Sprint

• Team members attend daily scrum at 9:30am
• Should a team member have a conflict, s/he updates the board in advance of the meeting and sends an email with updates for the team. 
• Task board is updated during daily stand up meeting so team members can refer to the specific tasks they are working on or completed.
• Team members may add new tasks any time.
• Communicate impediments to Scrum Master such as dependencies, issues, waiting, and so on
• Stories completed to Definition of Done and Product Owner agrees acceptance criteria of story is met.

 NOTE: The above is printed on 11x17 paper, posted in the team room, and signed by all team members.

Sitting the Teams Together: Value of Co-location

If you are rolling out Agile to an organization, I recommend you consider sitting the team members together.  If you have multiple teams, I  recommend that you have these teams sit together until the achieve a base level of agile maturity that is self-sustaining.  Agile principles emphasize face-to-face communication wherever possible. The benefits of this are demonstrated best at the team level. When teams sit apart from one another, the overhead of communication and the problems that arise from a lack of easy communication are seen daily.  


My objectives in having the team members sit together in one area are to:

• Improve Efficiency - Reduces coordination, speeds up communication
• Create the opportunity for continuous collaboration - Provide central location for task board, information radiators and white boards
• Foster closer working relationships – Encourages face-to-face communication, strengthens team spirit
• Allow teams to learn from other team’s practices

If at all possible, have the product owners sit with the team.  Depending on the level of support you are getting with your agile transformation, this could be easy or tough.  In order of preference, here are the arrangements I try to make:

1. Have Product Owner sit with the team full time
2. If giving up an office is a blocker to having  the product owner sit with the team, reserve a seat for the product owner with the team. Product Owner should set up a schedule where they sit with the team (and the team knows when to expect him or her to be there)
3. Move the product owner closer to the team   
4. Move the team closer to the product owner  NOTE: For 3 and 4 above,  establish office hours with product owner so there is a set time when the team knows the product owner is available

By members of the team sitting together with access to their product owner, we hope to achieve what Alistair Cockburn describes as "Osmotic Communication" where  "questions and answers flow naturally and with surprisingly little disturbance among the team."  Sitting together as a cross-functional team, rather than being surrounded by those in the same role, will be an adjustment for some.  


A balance needs to be achieved in co-location, where team members can informally and quickly resolve questions and get into sync with each other, but also where team members have concentrated focus time to execute their work effectively.  If possible, providing a private team room, in addition to co-located team space. This team room is often used to hold the daily stand up, display information that is valuable to team members to do their job well (also know as Information Radiators), be a place to do more focused activities, and a space for private conversations.

In the spirit of self-governing teams, I look for each team to design the collaborative space and team room to maximize productivity.  There are lots of ideas and examples on how to do this, so I encourage teams to be creative.  I encourage teams to do a bit of research on visual management and team rooms to determine what will work best for them.

To maximize benefits of co-location and reduce any drawbacks, teams should consider updating their working agreement with good habits for sitting together.  The goal setting up setting up a working agreement is to be: "focused on amplifying desired patterns of behavior" and "aimed at helping the team achieve their task and team-work goals."   Perhaps, some teams will implement core hours to protect the team from distractions, desk flags to indicate when someone shouldn't be disturbed, or find ways to increase knowlege creation, collaboration, and shared understanding through the concept of "Ba".  



If you work in a distributed team, there are other ways to keep the team connected and minimize lags in communication and collaboration, but that is a topic for a future post.

Presentation to Agile NJ - Rolling Out Agile to the Enterprise

I've always gotten so much from participating in Agile community events, it was a pleasure giving a presentation today at Agile NJ.   Good questions from the participants.

Thanks to Jardena DiGiorgio and Bob Small for coordinating the event and to Medco for hosting.

Download the slides now.

Feb 6th - Agile NJ Speaking Engagement

I am giving a talk, with another speaker, at Agile NJ on Monday, February 6, 2012.   

I will discuss a framework for approaching mid-to-large transformations based on recent experience standing up 15 Agile teams in 6 months.  I will share techniques to run your transformation like an agile project and ways achieve executive buy-in, alignment of product roadmaps, as well as support mechanisms like Scrum of Scrums, Impediment Removal Team.

The event is being held at:

Medco – 100 Parsons Pond Rd, Visitor Lot #5, Franklin Lakes NJ  (see Google Map)

The schedule is as follows: 

• 6:00-6:30 - Networking and refreshments
• 6:30-6:45 - Introductions and updates
• 6:45-7:15 - Growing Hyper-Performing Teams - Brian Haughton 
• 7:15-8:00 - Rolling out Agile to the Enterprise - Ilio Krumins-Beens

There is no cost to attend, but guests must be pre-registered in advance. 

Considerations For Running Your Transformation Like an Agile Project

In my earlier post, Eat Your Own Dog Food, I suggest to run any mid-to-large transformation like an agile project.  Several people have asked me to explain the differences between an agile software project and facilitating a transformation like an agile project.  I believe there is more value in focusing on similarities when working with teams, but the following will be helpful to those who are interested in managing a transformation effort like an agile project.

It maybe obvious, but the output of a software team and transformation team is quite different.  Software teams deliver working (“potentially ship-able”) code every sprint. A transformation team may deliver training sessions, provide coaching support, write best practices documentation, define and collect metrics, work to improve alignment between agile teams and the rest of the organization, or a multitude of other activities during a sprint.  What may not be as obvious is how these differences play out.

Fractional Resources
I often have fractional resources (someone who is on more than one team) as part of a transformation team, where as I am against it on a agile software team.  It is not because, most organizations under invest in the resources required to initiate and sustain a large transformation.  A successful transformation requires many different skills beyond those proficient in coaching agile practices.  

If possible, I like to get representation from Project Management Office (PMO), Human Resources (HR),  Communications, and Finance on the transformation team.  This is for several reasons:

• being part of the transformation team allows these people to learn about agile practices first hand (because you are running the project like an agile project).  These people will act as force magnifiers for the agile transition with their colleagues
• if you are on a team (and feel part of that team) you will be much more invested as compared with spending X% of time supporting another person’s initiative it allows me to leverage the specialized skill set and experience the person brings with them 

People from shared services Finance and HR often have unique and valuable perspectives on the organizations culture.  They can provide a helpful perspective in considering how to approach your transformation.  

Sprint Planning and During the Iteration
On software teams, I advise product owners to present a sprint goal so the team can rally around building a set of related features.  On a transformation, the team is often working on many different efforts, so having a singular sprint goal is less valuable.  It is a MUST however to have goals for release planning and clearly defined objectives when creating your transformation road map.

In sprint planning, I also have found it helpful when members of the team select which stories they want to work on during sprint planning.  Having a point person see a story through maintains continuity and helps manage external dependencies. Sometimes transformation team members select stories in-line with the expertise that that person has, but frequently another person will ask to work on it, so they can get experience in that area or to balance out the distribution of work.  Every sprint, however, we find that multiple people collaborate on tasks within that story.  This is due either to one person having extra capacity, or someone having too much on their plate.  This happens informally, but also during our daily scrum if we're trending behind based on our sprint burn down chart.  

When working with a software team, I tell them to limit the Work in Progress (WIP) and focus on completing the highest priority stories in the sprint backlog first.  The stories in a transformation backlog often have dependencies outside the team, so I find the my transformation teams will have more a higher percentage of open stories a few days into a Sprint than a typical software team.  

Preparing for the Sprint Review
Transformation teams may need choose what they present at the sprint review and spend more time preparing the presentation than a software team.  I advise software teams to show all the features they completed in a sprint and spend as little time as possible in preparing fancy power points for the demo, because the working software they build should be the focus of the Sprint Review.  The general rule of thumb I give to software teams is NOT to spend more than 2 hours collectively preparing for the demo.  It is important to make sure participants attend a well run demo, but completing the features prioritized by the product owner according to the team’s definition of done is the team’s top priority.

I have found that transformation teams cannot present everything they work on in a sprint at the demo.  Transformation teams work on meta-stories that require being creative about the best way to show them at the demo.  On average, the transformation team that I am working with completes between 20 and 25 stories a sprint.  If we were to try and demo each of these, the sprint reviews would be 4 hours long and my team would have to spend an inordinate amount of time preparing for the demo.  Instead, we select a few stories that we want to highlight at the sprint review and tend to spend slightly a bit more time preparing for our demos than the typical software development team.  

A few days before the end of the sprint, my transformation team will take 5 minutes after a daily scrum to indicate which stories be believe should be shown in the sprint review.   We do a silent vote, where each member gets three votes and they can apply 1 - 3 votes to any story.  The stories with the highest votes are usually are the ones we demo.  As product owner, I reserve the right to select other stories to demo, but most often the team selects the stories that I think are important to show.  Furthermore, hearing why team members believe a specific story is valuable to highlight often convinces me.

We rotate demo deck duty, and the primary person who worked on the story prepares how to demo the story at the sprint review.  S/he will create the materials for the sprint review and send to the person on demo deck duty who compiles everything in one presentation.  We do a run through the day before the sprint review and each person who is presenting explains what they want the audience to take away from their presentation.  The team gives each other feedback and we fine tune the presentation prior to the sprint review.  

Our sprint reviews are scheduled for an hour and often run that long.  I email  a brief description of what is going to be covered the day of the demo to key stakeholders and typically 10 - 25 stakeholders show up.  At the start of the demo, we display a list of all the stories we worked on in the sprint and with a different color font indicate which ones we plan to present.  Anyone in the audience can request that we speak to a story that is NOT selected for the demo.  After that, the team takes turns demoing what was selected to highlight.  Often we get feedback during the demo or suggestions on things that we can work on in future sprints.  We always speak to the progress we are making in the transformation and cover how we are doing against the transformation roadmap and release goals.  The Sprint Review follows the same agenda that our software teams follow.

Summary
Overall, I try to run an transformation as similar as I can to an agile software project.  Sure, the output of a software team and transformation team are different, but the basic principles behind why agile works applies to both.  If you try to run a mid-to-large transformation like a waterfall project your chance of success is much less.  You need to have a motivated team that is focused on delivering highest value, able to respond to the changing needs of the organization, focused on quality, and that is continually reflecting on how it can get better.

Although fractional resources are part of the transformation team, asking them to present their work often makes them an extremely invested members of the team.  All the members of my transformation team take our sprint commitments very seriously.  We are ruthlessly transparent when we don’t complete stories.  There is a temptation to alter the acceptance criteria to count stories as being complete before the review because transformation stories often have external dependencies.  I advise that you stick to the initial acceptance criteria discussed in sprint planning and use the sprint review to surface the blockers that prevented the transformation team from completing the story.  By showing your incremental progress against  the transformation roadmap and release goals, the team proves that it is delivering value.  Holding a consistent sprint review creates a feedback loop with your stakeholders.  By working in iterations or sprints, you can adjust the stories planned for the next sprint to address issues surfaced in the demo or to address the highest priority issues.

There are a few differences when you closely examine how an agile software team and a transformation team running their initiative like an agile project.  The important thing is that stakeholders seeing that you follow the same guidelines that you prescribe to your software teams.  Besides, when done right Eating Your Own Dog Food is extremely satisfying.

Eat your Own Dog Food - Critical to Successful Agile Transition

I really like “eating my own dog food.”   Before you gross out, I am referring to the expression  the suggests a company should use the product it makes.  There are many benefits, including becoming better attuned to what customers are experiencing and creating tacit knowledge throughout the organization about the product.  I also believe it encourages innovation, increases quality, and builds pride within a company.  

When rolling out agile practices, the equivalent of “eating our own dog food,” is running your transformation effort like an agile project.  Doing so allows you to:

• demonstrate the practices you are asking teams to follow
• inspect and adapt to the specific needs of your organization
• gain support of executives and stakeholders with transparency and demonstration of incremental progress

To exemplify how you can run a transformation effort like an agile project, I share recent experiences in rolling out the Scrum framework to 15 teams within a waterfall organization.  For clarity, I take some editorial liberties in simplifying the sequence of events at this company.  Transformations are often complex and messy, but I do not want to confuse the reader with superfluous details. 

Identifying Key Stakeholders and Defining Success

Before I assemble a team or create a backlog, I approach an agile transformation in a similar way to how I would start any project--trying to understand what the objectives are and what success will look like.  I meet with key stakeholders to understand problems we need to address and/or the opportunities we want to exploit by going through the agile transition.  I seek out multiple stakeholders at different levels within the company (and customers if possible) with different perspectives, as this provides me with a better understanding of the organization, it is culture, and the various players involved.  While some patterns of an agile transformation maybe similar, dynamics in one organization will be very different from another organization, which is why an adaptive approach to any transformation works best.  

I was fortunate to have executive level support in the example organization.  I met with the CEO, CTO, Chief Administrative Officer (CAO), Division Presidents, VP of Development, Project Sponsors, Tech Leads, Developers, Project Managers, Business Analysts, QA Leads, Customer Service reps (as a proxy for external customers), and internal users that the technology group served.  I asked open ended questions to understand what the interviewee wanted from the transformation and to identify what was and was NOT working in the current process.  I learned that there was very little trust between the technology teams and business partners.  On the business partner side, there was very little faith that technology would deliver.  On the technology side, there was a feeling that business partners provided inconsistent direction and had unreal expectations about what could be accomplished with the resources and timeframe provided.  Despite everyone caring about the company and wanting to do a good job, there was a real “us vs. them” mentality.

Building a Roadmap

I became the “product owner” of the agile transformation because I was accountable to the success of the effort.  I drafted a vision statement and success criteria of the agile transition based on what I learned from various stakeholders and got feedback from the sponsor of the transformation.  The vision statement, success criteria, and knowledge I had gained by talking to through the organization provided me with enough information to create a “roadmap” for the transformation. 

In this particular organization, I decided that the “Agile Transformation” would be broken up into 4 “releases”: 

1. ‘Pilot Agile Practices’ with three distinctly different types of projects for two quarters.  The goal of this “release” was to prove the viability of agile practices within this organization.  
2. ‘Stand up Dedicated Teams’ assembled teams of cross-disciplinary people dedicated to a specific business unit.  This was its own release because the developers, project managers, and quality assurance team members had been operating as a central pool of resources, often assigned to multiple and disparate projects at the same time.  I thought it was important to get people working together as teams.  Furthermore, the desire was to stand up all 15 teams at one time, as opposed to my initial recommendation of transforming a few teams at a time.
3. ‘Implement Agile Management’ was next the next release.  The goal was to establish a baseline of the scrum framework across the 15 teams.
4. ‘Introduce Agile Development, Build, and Quality Practices’ was separated from the introduction of Scrum because I did not have the bandwidth or resources available to implement these concurrently with the scrum framework.  

Having a high level roadmap, as simple as the one above, set targets and direction for those involved with the transition.

Creating a Backlog 

Now with a “roadmap” that suited the needs of this organization established, I was ready to create a backlog.  I decided to capture the requirements of this transformation in user story format.  Some examples of early stories include:

• “As a trainer, I deliver an executive briefing so that senior leaders understand fundamental agile concepts and how this transformation will impact their org.”  
• “As a recruiter, I have an updated Agile coach job description, so that I can find candidates that match the desired criteria.”
• “As a team member transitioning to agile practices, I have participated in a kick-off meeting, so that I have an opportunity to raise questions about these changes.”

Each user story included acceptance criteria that detailed the conditions required to complete of this story.  This backlog was a living document.  I continuously added, updated, re-prioritized based on feedback from stakeholders and my own tacit knowledge about what would work within this organization. 

Establishing a Team

The transformation team, at the example company, consisted of me as product owner, two dedicated team members (one of whom had no prior agile experience), an external agile coach (who was consulting for a limited engagement), and part-time of several others. I am usually against fractional assignments for Agile Teams, but in the case of the agile transition I found the participation of these additional people to be extremely beneficial given their differing expertise and roles within the organization.

The dedicated team member, who had no prior agile experience, agreed to be the scrum master.  This was a great way to test training we has planned for future scrum masters and forced him up-to-speed quickly.  Partway through the transition, he was ready to coach and help teams that had never done Scrum before.

Sprinting the Transformation

Although this transformation team was not building software, we ran all the scrum ceremonies and baseline practices that the agile teams would do.  We did release planning, worked in two week sprints, estimated stories in points, held sprint reviews (aka sprint demos), and retrospectives.  The furniture was removed from an office in the technology area, so that we could post our task board,  tracked progress with a burndown chart, and hold our daily check-in.  We tried to live by the motto, that we were not going to ask teams to do something that we had not tried ourselves. It was visible to everyone that “we were eating our own dog food.”  I believe this not only helped us get buy into trying the practices we were prescribing,  but is the most effective way to run a transition.  

The transformation team was more in-sync about the baseline practices we wanted teams to follow, because we lived them.  The Sprint Reviews provided an opportunity for any stakeholder within the organization to see how the transformation was going and provide feedback.  Working iteratively and delivering value incrementally allowed us better respond to the needs of the organization.  By becoming self-governing, the transformation team was able to come up with better and more efficient solutions than if I was dictating how ever task should be done.  My transformation teammates were a source of many of the stories that we implemented (some of which I would not have thought to try without their suggestion).   

It is a pleasure running an large transformation effort like an agile project.  Did I mention, I like “eating my own dog food”?