statcount

Thursday, 16 July 2015

Story Map upfront planning?...It depends!

I will start with two disclaimers, just to set the stage:
Disclaimer 1: This is not a blog about "You're right, I'm wrong" or the other way around. I might refer to people I trust their agile maturity. I do not think I am a beginner myself. So we are all discussing in a decent-high maturity level.
Disclaimer 2: This blog is in the context of a large organization in love with Agile principles, where a large change is starting as a new project, team and sponsors not mature in Agile. My focus is more on the Product building point of view, not Project management.

I have been working at my client for over 2 years now, with different teams, facing different issues. I am pleased with how this organization has moved forward and improved with Agile principles. Yesterday, one of the teams that has regular get together coaching sessions, asked to discuss about Story Mapping.

Kit-Kat break:
2 years ago, when I first started in this organization, they were told "Go Agile!" with almost no hands-on experience. On top of that, the groups around the delivery team were struggling with Agile as well. The quarterly budgeting was a new concept, not proven and not exercised in quarterly fashion either. Business was put on the Product Owner chair without understanding what that meant. And yet, the team had to deliver a huge change in an Agile way!
As the coach for this team, I proposed to use Story Mapping as a tool to eliminate BRD writing-approving-updating process. I also used Story Mapping to get everyone on the same page, understanding the Why and the What of the change, bringing Business and IT on the same page and have a maturity on the decision making. The team identified to participate in Story Mapping exercise was 45 people, representing 43 systems that were being affected by this change. It took about 2 weeks to prepare the Story Map, create a strategy on MVP delivery, discuss with sponsors on the value delivered on each MVP, make any adjustments/changes, really high level sizing of the work, and get ready to start Sprint 1. If interested I can break all this down on what was done every day. But I don't think that is needed. The goal was to have a backlog that we all agreed will be updated constantly, to have a roadmap on how this product will evolve starting with the first MVP, to get the team to feel comfortable owning this work and delivering high quality.
(*Clarification added after some people read this and asked: Not all 45 people stayed for 2 weeks to work on this Story Map. 45 people worked together for first 3 days. For the rest of the time, there were mostly core people from the 3 bigger systems that were being affected. All 45 were on standby for any question that the core group might have had during that 2 week period.)

Outside of this organization, I have used Story Mapping multiple times, in workshops or with real projects being delivered over a weekend by volunteers (GiveCamp examples). On these setups, Story Mapping has been from 15 min to max 30 minutes. Teams were smaller, work had a smaller focus and Product Owners had more decision making power.

I want to continue below here with the large organization example, as per my second disclaimer.
Kit-Kat break over.

Yesterday, on the presentation I did about Story Mapping, I took them through the steps on how to create the Story Map explaining the thinking behind, explaining the goal and showing some examples on how to break a Goal to Activities and Stories and then slice them to create a small size MVP. Focused on the fact that now MVP 1 is our closest target, without losing track of the big picture with the other MVPs on the roadmap. I also used my example from 2 years ago and mentioned 2 weeks period of time used. One of the people on the call made the comment that Story Mapping seems like a big upfront planning.
On one side, I was happy to hear that! This means that there are areas in this organization that are really getting quickly through the process of creating MVPs and have created a good relationship with their sponsors and are able to pivot without push backs. That is where we want to be and I was glad to hear that.
On the other side, he also made a comment saying "Well, we all know that what we present at the beginning is going to change and we will need more money and more time down the road!".

I was not comfortable with that.
I believe in being open, transparent, working smart and hard at the same time. Over and over I hear examples where teams have gone to Sprint 1 without a clue on what they are doing. 4 Sprints down the road they use agile as an excuse when sponsors are confused and have no idea what is being demo-ed to them. Complains about sponsors not getting this Agile thing begin and sponsors start micro-managing the team because they lost trust. To sponsors, the team is a bunch of cowboys running across the town, making a big mess and fixing nothing.

As a coach, I would like to create a team that looks like Clint Eastwood when riding the horse across the town. Be confident, be sharp and quick, armed, with horses that are strong and healthy. I want my team to be a group of craftsmen in IT delivery AND in Product strategy. Craftsmanship is not done quick.


If the team doesn't take the right time to look at the work ahead, there is no point on getting them to start running fast on the wrong path. Slowing down a bit, makes you move much faster after.

Is 2 weeks a lot? I still think those 2 weeks were necessary for that team, for that project, on that context. The Story Map kept being adjusted and updated while the team was working and delivering. Just like any backlog, it was groomed and prioritized. At the end of the first MVP, I asked the Dev lead (he was really skeptical that  agile would work on that project):
Me- So what do you think about Agile now?
L- Are you kidding me? We would be still writing documentations by now. And look at us, we have first release in Production with only 2 small issues!

Is 2 weeks a lot in other environments and teams? Maybe ..Yes... especially for small changes or small companies. I am hearing 2 hours to 1 day timeboxing. If I only had the GiveCamp experience, I would say: Are you crazy? We delivered a whole website in 1 day!!

So: It depends!


At the end, the whole Twitter conversation I started, was with the Product building in mind. The timing discussions made it more like a Project management issue. I wanted to get the pulse on the Story Mapping as a tool for product roadmap, but then it started looking like analysis-paralysis.

That was not my original point of view.

If there is information that we have, let's put it on the map and VISUALIZE IT! If there is information we don't have but we need, we found an area where we need to do some discovery/spikes/POC. All and all, Story Mapping visualizes what user/sponsor says and asks for. It visualizes it in a way that you can read it from any level, and go as deep as you want to (if it helps/is necessary). It helps everyone to get on the same page quickly with user's needs, with the story this change is bringing, with the impact this change will make on every step of user's experience. Limiting how deep you go under each goal, or saying "the 1 day timebox is over so we should have enough info now" do not convince me. Why should we do that?
Creating a thin slice and getting to your first MVP is not an easy job. Sometimes that sticky at the end of the pile, can make a big difference when the team sees it there and has the option to put it on the first MVP.

And most of all, this is an exercise that creates a great relationship within the team. While everyone participates, a lot of trust and openness is created. A lot of knowledge is transferred and as a team, you end up connecting, collaborating and having fun.

The "how" part on delivering this work is where project management begins, and where I want to stop. It is a completely different conversation from what I wanted to have. But if I have to say something, I don't think the team should do *only* Story Mapping. I mentioned spikes and POCs, but on the same time you want to also have open conversations with sponsors that might not be all the time in the same room, but still want to know where their money is being invested.

I still hope Jeff Patton sends me his number and have a call with him :)
   


1 comment:

  1. User story mapping is a valuable tool for software development, once you understand why and how to use it. This insightful book examines how this often misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features. To learn more with the aid of graphical illustration and freely usable templates visit Creately.

    ReplyDelete