Agile Coach Journal

A Simple Tool for Prioritizing Features

Roger — Fri, 14 Oct 2011 13:22:14 +0000

Prioritization of desired product functionality is often ad-hoc. Balancing the needs of all stakeholders is a challenge. A client recently shared a technique for gaining consensus on priorities and gave me permission to share it.

Context

I was invited to facilitate a Road Mapping exercise for an internal IT product that supports a global sales staff. Sales are for equipment and supplies manufactured by the company. We had representatives from several locales and business units. The challenge was to reach a consensus on product enhancement and improvement priorities.

Identifying Features

We spent the first half of the workshop developing a backlog of new features plus known defects. Features were identified by each stakeholder group independently. Some were epic-sized, some story-sized. The IT Department was a first class stakeholder, representing payback of technical debt and infrastructure needs. Defects and technical debt items were collected into functional areas.

When each group had their features up on the wall they were shared using two methods.

First, each group was invited to look at the stories from the other groups. I call this a “Science Fair”. It is a useful technique when facilitating multiple groups at once. It gives diverse groups a chance to cross-pollinate; ideas from one group can trigger similar or different ideas for other groups.
Second, each group presented their features in general terms to the rest of the group. This started us toward convergence and consensus by showing what sorts of things were valued by each group.

Convergence

We then did a Product Box exercise (see Innovation Games) to draw out similarities and differences across the stakeholder groups. We did this in mixed teams to start breaking down the differences in stakeholder expectations.

Next the features were clustered by “likeness”, meaning “things that are similar”. This is different from categorization and the difference is important. Premature categorization can lead to a different set of groupings. Instead, we just looked for similarities in terms of who benefits and what kinds of user activities are enabled. This gave us a better balance across stakeholder concerns because every cluster had requests from more than one stakeholder. In contrast, pre-categorization could have led to more stakeholder-specific groupings and, in turn, more difficulty in achieving consensus.

Once we had the groupings, we put names on the clusters. Those names then represented the feature areas to be prioritized.

For this exercise, we drew on the methods described in “The Workshop Book”. It is a powerful book for facilitators. Three things from the book were particular helpful:

“Consensus” does not mean agreement by everyone. It means “a common understanding that allows the group to move forward together.” This definition saves a lot of anguish and time.
The divergent- convergent activity framework that we use often in the Agile world helped put a structure on the workshop. It is similar to the Data-Insight-Action structure many of us use for retrospectives and identical to the ORID framework (see The Art of Focused Conversation).
Clustering of ideas followed by Naming of the clusters is a liberating way to aggregate information from diverse sources.

Prioritizing Features

Once we had a common vision and the features identified, the next step was to decide what development order made the best sense. The goal was a Road Map level development strategy rather than a detailed release plan. At this point we were not sure of how many teams would be needed or how much each feature would cost.

We discussed some methods of consensus prioritization including dot voting and a variation on Planning Poker. The wrinkle was that we did not have equal representation from all stakeholder groups. So we decided to do it verbally, en mass, with all 15 people present. Knowing the challenges of reaching consensus with that many people, I approached this cautiously. One participant pre-empted my facilitation with a proposal and, recognizing this as a good opportunity to increase client ownership, I stepped to the back of the room while he presented his technique. What resulted was the gift I want to share.

The first step was to identify useful criteria for determining priorities. We got this set:

The participant who gave us the method advised that more than 4 criteria would be problematic, so we then distilled the list to the 4 most important. In the process, one split into two and a new one appeared, a nice evolution in thought by the group.

We then created a matrix with the criteria as rows and a simple scale of Low, Medium, High as columns. We next assigned a priority number to each cell in the matrix as show here. We started by asking which cell was the absolute highest priority and assigned it the 0. You can see that features with important compliance requirements trump everything else. The company sells products in a highly regulated domain, so this was not such a big surprise.

The group agreed that a high likelihood of increased sales was the next highest priority. We then worked down in priority (up in number). You can see that a high likelihood of decreased cost ranked second. Next was medium likelihood of increased sales. Priorities 1-3 align with our traditional Agile principle of seeking maximum business value.

From there, the picture got more interesting. Ease of implementation ranked high. Minimal compliance impact ranked lowest. Low increased sales is still medium important. Medium compliance impact is rated low.

At one point around 6 the group got stuck, having trouble assigning numbers in the middle range. So I used a facilitators’ trick and drew them to the other end of the spectrum. I invited them to place 11, 10, 9, etc. With both ends filled in, the middle ground became easier to see and the remaining matrix filled in quickly.

Applying the Matrix

Finally we collectively processed the features identified earlier and assigned a number from the matrix to each one. If a feature would help the sales people sell a lot more product, it got a value of 1. If a feature was absolutely required to meet regulatory standards, it was a 0. If it was super easy to implement, it got a 4. And so forth. This was a ranking, not an exclusive assignment. We had more than 12 features to prioritize. Features with the same priorities will be dealt with later when we have more information about teams, team capacity, budget, etc. Their general position in line was established.

Using the resulting priorities we were able to lay out a Road Map for the next 12 months. This was our primary goal. We also achieved many secondary goals including consensus building, learning the value of removing duplication in user functionality across geographies, appreciation for the role of IT in supporting the business and general networking for a globally distributed population having common needs.

Conclusion

Simple, lightweight tools can be very helpful in reaching consensus and collective ownership. Simplicity can help a diverse group stay focused on the work to be accomplished and avoid getting lost in the details. This matrix prioritization technique is simple to use and promotes confidence in the outcome.

How to Make a Training Poster

Roger — Thu, 08 Sep 2011 22:24:46 +0000

I like to brighten up my training classes with wall posters. They typically reproduce slides in my presentation materials. In one class we had some audio-visual challenges and I actually used the posters as my slides . They serve as reminders of important concepts throughout the class and a focal point for specific exercises.

At first, I struggled with various technologies for making posters but finally found the magic formula. Here it is for anyone who would like to try it.

Sample Poster

Create a new presentation in Power Point.
Go to Design – Page Setup, choose “Custom” for slide size and set the print size you want. I use 24×36 inches because that is a standard choice at Staples where I do my printing.
Have just one slide in the deck and make your poster on it. Font sizes will be larger than you normally use. All shapes scale easily and print cleanly.
Any photo images should be high-res to print well (300 dpi minimum).
Save as pdf for printing.
You can test-print on 8.5×11 from a pdf reader. It is a good idea to do that for a final layout check.

You can get the pdfs printed at your local print shop. Black and white posters are inexpensive. Color versions are quite expensive. I usually print a new one in black and white and use it a few times to be sure it does what I want, then print it in color and have it laminated to protect the investment. Laminated posters can be used many times, rolled up and put in a tube for transport.

Posters in Use

Personal Report from Agile2011

Roger — Sun, 14 Aug 2011 23:26:34 +0000

I spent much of this week in Salt Lake City at Agile2011. This year’s theme was 10 Years since the signing of the Agile Manifesto. It was very cool to have many of the original signatories present. I have had a chance to meet some in the past and met more this time. I was impressed by the humility expressed by many of them given what has emerged in those 10 years. I got a chance to personally thank one for making my current career possible.

I was honored to repeat last year’s collaborative work “Creativity for Teams” with Mark Levison. We had about 80 people attend, nearly twice the crowd as last year. The session was recorded and I will post a link when the video is available. We will post our slides asap. We have some other neuroagile (Mark’s term) offerings in the pipeline.

Highlights of the conference for me were:

Barbara Fredrickson’s wonderful opening keynote about Positivity. It is so perfectly aligned with the Agile collaborative, value-driven mindset that we strive for as coaches and practitioners. The neuroscience evidence for her theories was an extra bonus for me. My main takeaways were that it takes at least 3 positives to nullify a negative and other people matter Plus the cool concept of “biobehavioral synchrony”.
Elizabeth Hendrickson‘s session on exploratory testing in an Agile context. I knew within 5 minutes that it was a valuable choice. Not only was it fun to play with Scrabble Flash toys (doing exploratory testing), I got a chance to fill in a knowledge gap that I usually cover with clients by waving my hands and saying something like “And all this automated testing gives us time to do more exploratory testing, an art that I know nothing about.” And some reinforcement for using the word “check” instead of “test” for automation.
Jez Humble‘s session on “Lean Startup Practices in the Enterprise”. He described the same sort of value stream consolidation I have been helping a client with – getting to where business-dev-ops are all on the same team. My client includes support as well. The idea is that we can reconfigure our functional departments into self-organizing teams so that each one owns a product all the way from concept to customer.
Michael Sahota’s facilitation of a Thought Leadership Workshop for
a serendipitous group of Scrum Alliance members using StrategicPlay® with Lego® .
We are posting the details here as time allows.
And, of course, great discussions with many friends in this very friendly community.

Pics and videos to come…

What are the Best Practices for Agile?

Roger — Tue, 24 May 2011 10:58:40 +0000

“What are the Best Practices for Agile?” If I had a dollar for every time I have been asked this question, I could buy a weekend on Maui. This industry term has taken on a “silver bullet” quality. In our endless search for perfection, we lazily think that going through the motions of the best practitioners will get us the best results for ourselves.That is why successful Agile coaches teach the principles along with the practices – so people will understand why Agile works, not just how to do it. As Bob Hartman likes to say, there is a difference being doing Agile and being agile.

Knowing the principles helps us to choose or even invent what is “best” for ourselves in the next cycle. What is best for a web project may not be best for a backend project. What is best for a software project may not be best for a hardware project. The best for the team today may not be the best tomorrow. In the spirit of Lean and its core principle of continuous improvement, a Best Practice is the one we have not found yet – so keep looking. The best for you is not necessarily the best for someone else. And it is only Best for a while.

We do know that there are Agile practices that work really well. Extreme Programming enumerated several long ago and they are still really good. That is what the “extreme” part means – always do the things that work extremely well. In a recent class, after failing to disabuse some participants from asking for the “Agile Best Practices”, I challenged the class to tell me. But I insisted in reducing them to a lesser superlative (is that an oxymoron?) of “Really Good” Practices. For flexibility, I offered two levels of “Good” and “Gooder”. Here is a digitized version of what they originally produced in less legible sticky notes.

Fun at the Seattle Scrum Gathering 2011

Roger — Sat, 21 May 2011 00:04:40 +0000

I spent the week at the Seattle Scrum Gathering, starting with a day-long retreat for Certified Scrum Coaches and Trainers. I learned a lot this week and made a lot of notes about things to check out, new ideas, new tools, new people, etc. Then I left the gathering in a hurry to catch my plane and accidently left my notebook behind. I am pretty sure it got gathered up with the trash. So I had a great time but was bummed to lose my external memory. Yeah, I know, a modern person would take notes with an iPad and never let go of it. Oh well. If I promised you something, please send me a reminder.

I got to see a lot of old friends. I made some new friends. And I think I mended one fence. And it was great to run into some of my CSM students who are doing really well. I also missed seeing a few friends who were not present.

I was asked to organize a coaching clinic. In keeping with the “foodie” theme of the conference, we called it “Scrum to Go”. A number of experienced coaches, many Certified Scrum Coaches, volunteered to talk with people in 15 and 30 minute time slots. We had a lot of walk-in business, too. We coaches got a great chance to co-coach with others as well. It was a big success.

Here are some things from the gathering:

My presentation: “Lean Strategies for IT Support Organizations” http://twurl.nl/a4ox7n

A few grainy pictures from the Scrum To Go coaching clinic: https://picasaweb.google.com/rwbrown900/ScrumToGo#

A few notes from my open space session “How to Launch a Team: ” at http://sgsea2011.posterous.com/how-to-launch-a-team

Where Does a Project Manager Fit in Scrum? part 2

Roger — Mon, 07 Feb 2011 05:08:22 +0000

In our last post, we described an exercise for discovering how traditional Project Management duties are shared by the 3 Scrum roles. We raised the question: Is there still enough left to justify a Project Manager? If not, what is the PM to do?

I can identify 5 scenarios. You may have others to contribute.

The PM has other things to do that we did not identify. This could be the case if the PM has many projects or plays some other role in the organization. Or they may have other things to do that are not getting done during daylight hours. This idea comes from a similar exercise from Pete Deemer that I patterned this one after. It is used to answer the same question about functional managers. See this article for an eye-opening revelation about the great opportunities for managers when development teams are self-organized.
The second scenario is that the PM assumes the role of ScrumMaster. A recent parade of job requisitions marching past my desk suggest that many companies are conflating PM and SM. This sounds like a risky proposition to me but it is understandable that people with limited understanding of Scrum might make this mapping from SM to what appears to be the closest position in a traditional software development organization.
Can the Project Manager become the ScrumMaster? I think the answer is “yes”, provided some shifts in perspective and expectations are made. Some PMs have an easier time of it than others. At the APLN/PMI event we had more time for this exercise than I have in the CSM class so we took it a bit farther. We explored the differences between a PM and a SM by collecting answers to two questions. Note that the answers came from PMPs, not from me. I do not have training as a Project Manager.
- What do we expect from a ScrumMaster that is different from what we expect from a traditional Project Manager?
  - Coaching
  - Bring out the best in the Team
  - Don’t try to control the Team
  - Spark new thinking, facilitate creativity
  - Actively building trust
  - More learning from others
- What are some new opportunities available to existing Project Managers?
  - Professional development for self and others
  - Help people be more self sufficient
  - Become an Agile coach
  - Align self with strategic goals of the organization
  - Have higher expectations of the people doing the work
In a contracting situation, the Project Manager is in charge of the business relationship with the customer. This one shows up in the table as a line item but there is a lot to it. We are not talking about the Product Owner role here, that of defining the functionality desired by the client. We are talking about the day to day communication that a PM does to keep the client in the loop and up to date on contractual matters. There is not really a Scrum role for this – it is outside of the basic Scrum framework. Or is it?
I have encountered another scenario in a company that builds musical electronics. They have a PM on the Team who has the job of handling the deliverables between the software Team and the hardware team.
Agile multi-team product development groups sometime have a Project Manager to coordinate the flow of information across teams and from teams to other stakeholders. While a Scrum of Scrums does some of this, a PM role has emerged in some cases.

So there you have it – some ideas of what the Project Manager might do when Scrum comes to town. Try this exercise on your own when the question comes up. See what your people learn for themselves when they do it.