It’s all about the input

March 7, 2013 by Niels Talens

header

Garbage in, garbage out

This is a pretty basic principle. But what do you expect? What are the odds that if you give poor descriptions of your vision and needs that the results will be as expected? 50/50? Maybe less?

Within the agile community there’s a lot of information to be found on processes and the output of teams. What I’m really missing here is the discussion about the input. And bad input is very often the main cause of bad output. This input does not start with designs or architecture but starts from a business perspective. In this article I’ll focus on the flow of input from an early stage: from vision to user story.

Some causes of bad input

However in no way a complete list, some causes of bad quality of input are:

The product owner role

This role is often taken too lightly. It’s not about writing user stories and whether to attend a daily or not. It’s about product vision, entrepreneurship, stakeholder management, domain knowledge, user research, strategy, leadership, innovation and passion.

Big design up-front

In some cases there was a phase in which there has been made for instance a functional or graphical design before the development team was involved. But we want to do the project agile because we want to be able to prioritize and build the software iterative. So we split the designs up and create a backlog based on the items in the designs. How is this different than implementing a big design upfront in basis? Do we now really know that we are creating the maximum business value?

“If the big design upfront was wrong, why should the quality be better if we cut it up?”

No focus on business value aka Quantity over quality

We really want it all. So we just define as much stories as possible. We do not really have to implement them all but we still define as much as possible. The bigger the product backlog the bigger the chances are that we will get a lot of functionality.

Why, What & How

We sometimes answer these questions in the wrong sequence. Sometimes customers start with the how and we go along with that (A man went to the Doctor) and sometimes we skip the what. To really define and secure the business value we really have to follow this sequence: Why, What and only then How.

The flow of input

What to do then? After seeing a gap between business and IT over and over again I started looking for ways to help the business to get a better connection with the way we do our agile projects. To help product owners to communicate better between stakeholders and development teams. I found some really helpful ways of thinking and tools which I like to use in order to create a good quality of input. I didn’t invent these tools or methods. This is the work of people which I admire for that. I’ll only describe a small part of each subject. I provided some links to their sites so you can get in depth information written by the experts.

The agile product vision board

We need a clear and common understanding about the goal(s) of the product we are going to make. We start by defining the product vision. We specify a vision statement, the target group(s), the reason why we should make or do anything (the needs), your crucial features (those can become your epics) and what value it is going to bring the stakeholders.

We now have a common understanding about the goal on which we can verify all the choices we have to make in the future. Whether you are a developer, product owner, stakeholder, user or tester. We know the target groups on which we can define our personas, we know which problems we have to solve/which business value we have to create for these personas and we have our top features. These top features we now can easily use for the next step: the story map

The story map

The reason why I like to use story maps instead of flat backlogs is because flat backlogs are very difficult to understand. Most of the time they need explanation for the people who are not directly working on it (stakeholders for instance). It is just a flat illogical list of splitted functionality.

A story map is a two dimensional backlog which makes your backlog and release planning both much better readable, logical and understandable. Not only for the development team but for everyone who can read basically. It will show you your planned releases and what they contain in one glance.

The principal is very simple (as very common with good ideas). At the top of the map from left to right are the “big stories”. Let’s call these activities. It is something an user wants to do with the product. The order of these activities explaines the behavior of the system. Underneath these activities we put our user stories, prioritized according to their value.

As Jeff Patton puts it here: ”I simply arrange the small things under the big things in a bit of a grid form.”.

If your story map is ready just take the top row(s) of features, the most important ones, and work them out in a product canvas. This set of features can be your minimal viable product. It contains only the features which you need to have your (first) version deployed. Now you can finally get some real feedback from the users you’ve defined in the product vision. Inspect and adapt.

The product canvas

This is something that helps teams to get the stories for the next sprint ready just in time. This gives a clear and focussed view on what there needs to been done on the short term to get ready for poker instead of a big design upfront. I found out that it is also very helpful for getting (UX/graphical) designers and architects, who are used to create designs upfront, faster in a agile mindset.

We take our most important features from the story map, add the personas, describe the journeys these personas can take, describe the constraints, do some basis or overall design and combine all this data to write stories which are ready for poker. This is the input for your sprint. And after the sprint planning you start over again with the next set of features.

Finishing up

As stated above, I like to use these tools to bridge some of the gap between business and development teams. To create a common understanding about what we do and why we do it. To do really successful (agile) projects we need everyone who is in any way involved to have that understanding. To maintain this we need to have this visible, understandable and accessible for everyone. I found that the examples I described above are great for that.

By taking flow of input serious, like we should take the PO role much and much more serious, we can create qualitative input. The odds that the output will be qualitative will then be also much higher.

For me there is one downside. I consider this a luxury problem: you really need a lot of room on the walls.

In-depth explanations:

The product vision & the product canvas (also the business model canvas) as explained by Roman Pinchler
Story mapping explained by Jeff Patton.
The business canvas generator by Alexander Osterwalder and Yves Pigneur

category: Agile, IT-Governance, Scrum | no comment
This post is written on March 7, 2013 by Niels Talens

A man went to the doctor…

November 9, 2012 by Niels Talens

“Hello Doctor, I have epicondylitis lateralis and I think we can fix that with Shockwave. Shockwave is a brand new treatment that is faster, cheaper and better than all the other methods. Everyone I know does it. Don’t bother looking that up for I’ve done some research on the internet. It’s the best there is. I really think that Shockwave is the solution.”

Where the doctor says: “Well alright then. It’s very nice that you have done some research but while you come to me with a problem I will, being the professional I am, first try to find the cause of your problem before we’ll find a treatment. First things first. I’ve studied for this you know.”

A man went to the ICT supplier:

“Hello sir. All our projects are late and over budget and I think we can fix that with Scrum. Scrum is a brand new method for developing software which is faster, cheaper and better than all the other methods. Everyone I know uses it. Don’t bother looking that up for I’ve done some research on the internet. It’s the best there is. I really think that Scrum is the solution.”

Where the supplier says: “No problem sir. Scrum is the best there is. I even use it at home! We Scrum all the time. We will start right away if you want.”

Not the goal

I know that a customer asking for Scrum must sound like heaven for some. We are so passionate about our agile ways of working and thinking that we want others to experience and gain from this too. But working agile is not the goal. It can be a way to achieve goals but is not the goal itself. The Doctor has a point: without searching for the cause of the pain, any solution is a lucky shot.

It might scratch. It might scratch really really good. But if it’s scratching where it doesn’t itch, it makes no sense.

To really help a customer we need to take responsibility and say: “It’s very nice that you have done some research but while you come to us with a problem we will, being the professionals that we are, first try to find the cause of your problem before we’ll find a treatment. First things first. We’ve studied for this you know.”

category: Agile, Scrum | no comment
This post is written on November 9, 2012 by Niels Talens

Velocity is not for you

October 8, 2012 by Niels Talens

A while ago someone told me they let their product owners participate in estimations. And I don’t mean watch how the team estimates but really estimating stories. I’ve heard about non-programming scrum master, projectmanagers, salespeople and architects who decided their input is fundamental for getting estimations correct, but product owners were new to me. And I personally think that neither of them should ever estimate anything.

I am not so much about strictly following what is written or how people say things should be done. Insights change, the world changes and people change. If stuff works for you I rather want to learn from that instead of telling you that some guide says that it should be done different. This is not about rules. The problem I have with this is the greedy mechanisms behind this.

Would you tell a carpenter that his or her estimation for creating a table should be divided by two? Or tell the physiotherapist that your pain could be relieved in a third of the time he or she thinks? Or ask one of them to take the the average of both your estimations?

Would you really be surprised they tell you to do the work yourself if you think you can do it so fast? (And that would be the most polite response you’ll get I guess.)

One reason why people outside the team want to influence estimations is because they think they will gain from this. They feel that if they fill up a sprint with twice the realistic amount of work it will result in more profit. I personally think that it will result in more but crappy software and unhappy people.

Another reason is that some people must feel that they are in control. They are our leaders. Without them controlling every single thing only failure is certain. Trusting people to do their best is a nice thing to do when they have some free time. They are the kind of person who would tell the carpenter they could do it much faster. That is if they knew how to hold a hammer.

In the end it is very simple. It fits on a sticky if you want:

category: Agile, eXtreme Programming, IT-Governance, Scrum | 5 Comments so far
This post is written on October 8, 2012 by Niels Talens