Exercise Introducing Story Maps

When doing Product Owner training I have introduced the concept of story maps to the attendees for the last year or more. The problem has always been the same though. You need to do an exercise before people really get it but an exercise involving even a small example or the trainees own context always ended up taking way too long or became too simple to be of any real value.

It seemed that creating a vision, Identifying the backbone, identifying personas/users and creating high level user stories from walking them through the backbone proved simply too much to do in an hour or less even for simple examples and way too much when people had to do it for their own context. I went back of forth, putting more or less weight on the individual elements but still really was not satisfied with how it went.

Therefore I started thinking “what is the most important thing I want people to learn from this”. It turned out that what I really wanted was to make people aware of was the power of the story map as a tool for discussion and communication and how when prioritizing and planning, a 2 dimensional story map will generate insights far beyond those you get when doing this using a traditional one dimensional backlog.

So the goal became to create an exercise where the groups would use most of the time exploring this. To do this I decided to create an example of a product that everyone would be able to relate to, create the vision, identify users and even write the user stories. To try to make it as realistic as possible some user stories would be interdependent, redundant, obsolete, missing etc.

The result became the exercise named “hairdresser.dk” described below. I have been running it four times now and it works really well. Teams come up with very different "walking skeletons" and the story told can be very different. What matters most though is that they get into real discussions about value and MMF's, and some tell me afterwards that Story Maps was probably the most important thing we covered in the entire course.

Here is how it works:

Purpose: Giving people an idea about what a Story map is and how it can be used to facilitate prioritization, release planning and finding MMF’s

Before the exercise I use about 10 min. to describewhat a story map is. Then I roughly do it this way (You might want to twist the “story” a bit. The one below is just the basic version)

Setup: Divide people into groups of 5-8 and hand each team these user stories and vision http://dl.dropbox.com/u/2095335/hairdresser.dk%20English%20Version.docx. Draw the following backbone on a whiteboard – one for each team.

• Log ind
• See available
  appointments
• Book appointment
• Confirm
• Change
• Remind
• Admin.

Story: Tell them they are both hairdressers trying to set up a business in a small town and will be competing for the same customers as well as against existing hairdressers. Market research shows that this particular town is filled with young people eager to have a more flexible
and easy way of booking hairdresser appointments and that given the opportunity to do this online, whenever they want, they would turn away from their prior hairdresser. It does however have to very quick and intuitive for them to make this transition.

Time to market is key and the first hairdresser on the market with an online solution that customers accept will likely survive while the other will go bankrupt within a very short while.

Timeline: Give them 10 minutes to go through the user stories and place them in the “right” column on the backbone (there is no right or wrong). Then allow 20-25 min. to find the “Walking Skeleton” and the content of the next 2-3 subsequent releases.

The winning team will be the one that can offer the most convincing story on why they chose to balance functionality and time-to-market the way they did. Having a theme/vision for each release will give them extra points but of course the most important thing is their story and the arguments they use to explain why their release plan is the best one.

What Does Agile Mean?

Lacking definition

Lately I have found myself wondering how so many people can work so intensely with a subject like Agile without a common definition. Why does it matter you might ask and haven’t we got http://www.agilemanifesto.org/?

First of all very few people are able to remember the principles behind the manifesto

http://www.agilemanifesto.org/principles.html

and though the manifest itself lays out the ground rules for Agile development they tell us very little about what Agile actually means.

The reason why is probably the very nature of a “Manifesto” which is something usually reserved for public declarations of a political nature, a statement of intentions used as a reaction to an existing situation and at least to me spells “change” and “revolution” of some kind. But what is left when the revolution has occurred?

The real issue here is that you will find people discussing Agile from very different perspectives. To some it means doing TDD and Pair Programming while others define themselves as Agile because they have frequent meetings with their customers. Others still use Agile as a term for the constant state of chaos they are in “It’s OK, it is just because we are Agile”.

The principles behind the Agile Manifesto

When reading the 12 principles behind the Agile Manifesto I find they bring me closer to a useful definition of Agile but still they have some inherent problems. There are too many of them and they are too long (182 words in total) for my brain to remember. There are redundant elements (“…early and continuous delivery…”, “Deliver working software frequently”) and some of them seem too inflexible (“Business people and developers must work together daily throughout the project”). With the arrival of continuous deployment at least one of them is outdated or at least too specific (“…from a couple of weeks to a couple of months”)

My first thought was that ten years after the Agile Manifesto was written a large amount of academic research must have dealt with the problem and produced an adequate definition. The best one I found was from the article by Kieran Conboy, 2009:

• The continual readiness of an ISD method to rapidly or inherently create change, proactively or reactively embrace change, and learn from change while contributing to perceived customer value (economy, quality, and simplicity), through its collective components and relationships with its environment.

While serving as a good academic definition and probably something I would have found very useful back at university it doesn’t quite help me in the pursuit of a short clear definition I can use as a daily reminder to keep me on the right track, as well as a base when discussing Agile Software development with others.

My own definition of Agile in 9 bullets

Puzzling with the problem for some month and changing the exact wording a number of times I have arrived at the following 9 bullets which currently serves as my own definition of Agile and the one I use when discussing the Agile framework with teams and business partners I am involved with:

1. Satisfy the Customer through Working Software
2. Deliver Early and Often
3. Create and Embrace Change
4. Focus on Quality
5. Create Transparency through Visualization
6. Endorse Sustainable Pace
7. Bring People Closer Together
8. Trust in People and Decentralize Authority
9. Improve Continuously focusing on Simplicity

While most of them are easy to map to elements in the existing principles from the Agile Manifesto a few deserves a comment to get the meaning right (probably a sign that they could be better formulated):.

4. Focus on Quality

Quality is a key enabler of early and often delivery as well as sustainable pace. Quality problems create distrust and slows down the development speed over time, when it becomes too hard to maintain the system and integrate new features. TDD, code review, refactoring, continuous integration, pair programming, accept criteria and early feedback have all proven to be excellent tools to achieve high quality releases.

5. Create Transparency through Visualization

Though visualization of work is not part of the principles behind the Agile Manifesto or the Manifesto itself it has proven to be a core value of Agile Development and a key enabler of transparency. By visualizing the workflow everybody involved in the project knows exactly what is going on and nothing is hidden. This gives everybody a clear picture of the project’s current status. Whiteboards for collocated teams and online tools for distributed projects have proven to be a key enabler for visualization of work and thereby transparency and trust in the organization. A real problem however is that many Agile projects only use visualization for internal transparency and consciously or unconsciously keep this information from the rest of the organization and the customer. In many cases it is simply a matter of sticking to old ways and the game of “Project Poker” while others simply have not recognized the benefit of openness and total transparency.

7. Bring People Closer Together

Agile is all about collaboration, inside the development team, between the development team and the business, end users etc. Bringing people as close together as possible is the most effective way of sharing information which is what software development is all about. In some cases this might be using the best online tools available to facilitate communication in a distributed environment while other projects are fortunate enough to have the business as well as the development team in the same building. The key principle is to bring people as close together as possible to avoid unnecessary management overhead and handovers.

9. Improve Continuously Focusing on Simplicity

Reflecting on our current situation to do things a little better than we did yesterday/last deploy/last iteration/last release is a core principle in Agile. Before the Agile Manifesto was written in 2001 Agile methods were referred to as “Lightweight methods”. One of the key elements was keeping management, process and technical overhead low to ensure that as much time as possible was used for value creation. When continuously improving our system and process we should always do it with this in mind since keeping things simple allow us to avoid a complexity few of us are able to handle anyway. Complexity, both technical and process, seems to creep in under the radar whenever we are not paying attention and therefore we need to let our continuous improvement initiatives be guided by the will to constantly reduce it to a level where we are keeping our heads above the water.

Using the 9 bullets

I try to make these 9 bullets as visual as I can in my workspace, posting it on whiteboards, walls and doors… to make it serve as a constant reminder to myself and my colleagues in our daily work. As you will probably have notice the 9 bullets are almost practice free which is on purpose. To me Agile is more of a general set of principles I try to follow to enable better ROI (Return On Investment) for my customers, than a set of specific practices I need to follow. Pair Programming and TDD are very useful tools to enable high quality software which again is necessary to deliver often, but while the need for this might be more apparent in Agile projects I think they are as useful with a waterfall approach. User Stories are a fantastic way of bringing the development team and business side “closer together” and making them focus on customer value, but I will never consider it Agile in itself.

Stating that there really are no “Agile practices” have gotten me into some heated discussions from time to time, and though I do understand where the arguments are coming from (after all many of these practices have evolved in the Agile community) I am still not convinced that they are not just tools that should be used according to the specific context. But feel free to prove me wrong.

Explaining why

The next natural step becomes gaining a more in-depth understanding of why Agile principles help us deliver better ROI for our customers. My experience is that many companies follow Agile principles like a checklist without really understanding why they work and are simply trying to copy other people’s successes. While doing ok for a while they often end up making the wrong decisions at critical moments when they are faced with difficulty and consequently revert to former practices.

Understanding “why” might therefore be even more important than the definition itself. In this pursuit I have found the principles of Lean Product Development to be extraordinary helpful but that is a subject for another blogpost and another day.