Very Proud of Our Internal Hackathon

Last August, my colleague Don Gregori and I facilitated a division wide hackathon at the company we work for.   I've blogged about this experience elsewhere and the following video was put together:


Jenny Liang of IntraprenuerLabs wrote a flattering case-study called Sparking a Culture of Innovation within the Enterprise.

For me, helping coordinate such an event was one of my proudest professional moments, not just because innovative product ideas were generated, but 18 teams of people were truly proud of the prototypes they presented and built over an 48 hour period.  Really looking forward to the next hackathon that we're doing this year.

Facilitating Retrospectives with Remote Attendees using Google Drawing in 5 Easy Steps

When you talk about retrospectives, most people probably imagine a group of people in a room together using stickies to identify what is "working well" and "opportunities to improve."  If you have participated in a retrospective when everyone else is co-located, you may have found that experience sub-optimal.  Consider the alternative of running a retro with no one co-located, where all members participate remotely.

The following are 5 easy steps to facilitate a retrospective using a 4 square format with Google Drawing.  The example I draw from was run with fourteen remote participants--most of whom never used Google Drawing and some who never had been to a retrospective.   In general, I am tool agnostic, but I have found that Google Drawing is intuitive, provides some of the "tactical-like" feel that you get with using stickies, and it is not difficult to set up. 

Step 1: Set Up - Est. 10 Min

Create virtual retro board and pre-create blank stickies and voting chips for each participant in advance of meeting.  Alternatively, you can open the Remote Retrospective Template* in Google (you'll need to 'Make a Copy' to be able to edit it).  Note: Please abide by the Creative Commons license referenced at end of this post.

I suggest grouping of "stickies" and "voting chips" to a named individual so there is no confusion on where people should start.  

You'll need to give participants edit rights to the document.   

First time doing this I add people in advance of meeting without email notification.  This enables me to explain how to use the board to everyone at once.    Everyone can benefit from questions raised.

Step 2: Explain How to Use The Board - Est. 5 Min

If this is the first time your participants are using Google Drawing, take a few minutes to show them the basics.  Although the tool is very intuitive, you will lower anxiety by showing how easy it is to: drag a shape >  double-click to edit > enter text.  I also showed various ways to create additional stickies. 

In my example, many participants were not familiar with retrospectives, so I explained the values behind why we do retrospectives and the guidelines I wanted people to follow prior to showing how to use the Google Drawing..  

Step 3: Create and Add Stickies - Est. 10 Min

I time-box this part of the retrospective to 10 minutes.  Each person adds their thoughts (1 per stickie) to the corresponding quadrant: (Working Well, Opportunity to Improve, Questions, Suggestions)

Here's a 10 second time elapsed view of 14 people simultaneously adding items over the time box.

Step 4: Group like items and use voting chips to prioritize items for discussion - Est. 10 Min

Once everyone has independently added their items to the 4 different areas, group similar stickies together.  I like to employ silent grouping to items.  I have found this minimizes the amount of time spent discussing what the team agrees to. 

Ask for volunteers to read the groupings.  Anyone participating can ask for clarification to what is meant by a stickie, but no one should make challenge or comment on the validity of what someone else shared at this point of the meeting.

After all items have been read, each person can assign 3 "voting chips" to the groupings that they think are more important.  A person can choose to allocate their chips to separate items or put more then one on a specific item.  Voting chips can be applied to a grouping in any of the 4 quadrants.  This voting can be done silently and independently.  In a matter of minutes, you will have identified themes and prioritized them as a group.

Step 5: Identify Action Items - Est. 10 Min - 30 Min

As a group, discuss the groupings of items starting with the items that received the most votes. Suggest which activities the team wants to continue and what the team wants to do differently.  Identify a few action items that the team can commit to in the upcoming iteration. 

-----

Additional Tips and Tricks

• Suggest participants use Chrome when opening your Google Drawing virtual board
• The first time you try this you might miss the ability to read visual queues from other people participating in the retro.  Encourage folks to speak up about how their feeling.  
• Enable video when discussing the items as a group.  Google Hangout is great, but there are a bunch of other tools that work well too.
•  I like to differentiate the color of the action items that the team comes up with collectively, from the items that are suggested independently.
• There are many excellent ways to facilitate a retrospective, depending on maturity, team dynamics, organizational context and a set of other factors, so I encourage you to experiment with that will work best with your team(s).

-----

* Note: Use of Remote Retrospective template is under:

Remote Retrospective Board by Ilio Krumins-Beens & Terrence McGovern is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Based on a work at https://docs.google.com/drawings/d/17cyx7QZJLpMIoVHsdlAldXfgU-cPdIg9v_XlVhhtkZU/edit?usp=sharing.

Techniques for Getting Aligned with Stakeholders

From my experience, a key challenges is in getting everyone on the same page about how to approach the problem or opportunity you are trying to address. If you are not aligned on the vision, it is nearly impossible to gather requirements from multiple stakeholders when each person brings a different perspective based on their own experiences and context with in which they work. 

Many agile teams employ techniques to help alignment with stakeholders. These techniques are lightweight, but require key stakeholders to be involved in the envisioning exercise. Techniques that I've enjoyed include:

• Creating a Vision Board or Product Canvas. For more on this, you can see read some other posts about why product visioning is important: 
• http://agile.conscires.com/2012/06/28/why-is-product-visioning-important/
• http://mhjongerius.tumblr.com/post/9539129138/using-the-product-vision-board

• Use "Provisional" / "Assumptive" Personas to create shared understanding about who your target customers are 
• http://www.agile-ux.com/tag/personas/
• http://www.romanpichler.com/blog/agile-product-innovation/persona-template-for-agile-product-management/
• Ideate with Stakeholders using Design Studio Technique 
• Story Mapping to visualize the user flow and prioritize the work 
• Use games to partner with your stakeholders and become aligned 

Stakeholders have differing levels of interest in your project, but if they aren't accountable to the outcome they may not share the same sense of urgency that you do.  Those with "skin in the game"  should have decision making authority. This is illustrated through the Classic Story of the Pig and Chicken illustrated by Michael Vizdos / Tony Clark.  Although, Scrum has moved away from using classic story, I believe it helps to illustrate that those who are committed and accountable (pigs) should be separated from those only involved (chickens), and only those committed and accountable should get decision making authority.  NOTE: In high-trust environments all stakeholders are committed and accountable.  

Product Ownership is Challenging and Rewarding

The Product Owner role is essential but can be extremely challenging to fill.   Most organizations struggle to find someone with the right blend of skill and experience to fulfill this role perfectly.  Before we explore why that is, let us define what the role entails.  


Roman Pinchler, author of Agile Product Management with Scrum, describes the role as "the individual who champions the product, who facilitates the product decisions, and who has the final say about the product."1   The ideal product owner has to have:

• Vision for the product(s) they own
• Strong understanding of their customer(s)
• Deep domain expertise
• Ability to collaborate with multiple stakeholders
• Authority and respect throughout the organization
• Time and willingness to work with team to describe his / her vision 
• Leadership style to motivate others to see that vision and work with the team to achieve it 

Having been a product owner for several years, I know the pitfall and rewards of this role.  In his article, The Product Owner and the Product-Shaped Hole, Jeff Patton jokingly suggests product owners should wear "spandex and a cape” given the super-hero-like demands placed on them.4  

Organizational context and product maturity greatly influence the expectations on a product owner.  For example, if you’re responsible for delivering a new product that will change how we sell products to our customers that is a very different challenge than inheriting an internal business system that has been in production for 10+ years.  If you are responsible for delivering a new product, you are likely to be judged as an "entrepreneur" or “intrapreneurs,” while an owner of a mature product might be judged on how well they maximize the return on investment on a series of enhancements.1 This is does NOT imply that product owners of mature products are less inventive than those building new products, or that one is easier or more valuable than the other.  Understanding how your product fits into the larger ecosystem of the organization you are working in is critical to the choices you make as a product owner.  

Most agile literature on product ownership takes it as a given constraint that there is ONE product owner per product.  This is certainly a best practice, but in many resource-constrained organizations that I’ve worked, teams often support more than one product, and sometimes product owners support more than one team.  If you find yourself supporting multiple products or multiple teams, do the best you can to protect the team from context switching and churn by helping to focus the team’s effort and coming to planning sessions fully prepared.  Furthermore, leverage the talent on your team to see how you can involve them more and take some of the load off your shoulders.   

Here are some suggestions that I offer to product owners, regardless of the organizational context, product maturity, or number of products you support:

• Focus on outcome, not output  – Outcome is what we expect to happen after the software ships. We can only improve if we assess whether what we deliver is meeting its intended purpose. Furthermore, teams are motivated by knowing that what they build is expected to move the needle. 
• Involve the Team - Resist the feeling that you need to figure it out on your own. Present the team with the opportunity or problem you’re looking address, and they’ll find a solution that works and likely be more engaged as part of being involved in product envisioning. 
• Talk and test with actual customers – Why not learn from the people you are looking to serve. Validating your assumptions or being able to course correct will greatly improve your product offering.
• Communicate with Your Stakeholders – As a product owner, it’s your responsibility to make sure that you’re effectively prioritizing and sharing feedback from stakeholders and representing your team well back out to stakeholders.

While challenging at times, I have found product ownership to be one of the most rewarding jobs because you have an opportunity to work with motivated team members and deliver true value to an organization.  


Sources:

1. The Product Owner on One Page by Roman Pichler
2. Top 10 Product Owner Qualities and Characteristics by Peter Saddington
3. The Product Owner Role: A Stakeholder Proxy for Agile Teams by Scott Ambler
4. The product owner and the product-shaped hole by Jeff Patton

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.