3 Methods to increase Business Value

Yesterday I enjoyed talking to Southern Fried Agile, the local one-day agile conference.  My topic was this: Three steps toward greater business value.

I was also pleased to see that many participants said they wanted to talk about this subject. So much so that the organizers decided to run the session twice. I am happy that this is considered an important subject. Certainly I think it is.

Some things we already do in Scrum to increase Business Value (or should do):

1. Better partnership between Business and Technology
2. Improve the Product Owner (and give him or her this job)
3. Use a prioritized Product Backlog
4. Order the Product Backlog to maximize the release of Business Value (over your chosen time frame)
5. Build working product each sprint (if we get cut short, at least we can field what we have so far)
6. Demo working product and get feedback from business stakeholders each sprint. Ex: “Did we build for you the most value stuff this sprint?”
7. Release more frequently

Could we be doing each of those better?  (Ok, sorry for the rhetorical question.)

In the presentation, I suggested three “big” additional things we could do.

A. Business Value Engineering…

This is a framework for continuously getting better at delivering business value. By mapping the process, by articulating the underlying assumptions, by taking a fact-based approach to proving which improvements would be better.

B. Priority Poker

This is an easy thing to add to Release Planning or to Release Plan Refactoring. Or relatively easy. You enable the “5″ best people on business value (in your specific domain) to learn from each other more about business value. By voting “business value points” on each user story.  And the rest of the group learns too.

C. The Pareto Idea

This is classic, and in some sense, almost everyone does it already.  Except they don’t do it enough. And they don’t take it as a basic, everyday, mindset.  So, we fight every day to separate more the gold-platinum-diamonds from the silver-copper from the dirt.

This is a lot of hard work, every day, that we do while we break down the stories into small sprint-sized ones. (I like about 8 stories in a 2 week sprint.)

***

There is much more to all 3 of these ideas.  To be discussed later.  But they attendees seemed to like the ideas. But the real question is whether they got enough to start taking action (if only to learn more).  We shall see, I hope.

Agile Release Planning is not about the Plan...

The past week and a half, I have enjoyed working in France.  I have worked with 3 different companies, and a bunch of great people.

In the third class, we did a 2-day workshop.  The Workshop was mainly about agile release planning. With the real work of that company and those teams.

As with most people, some of the people were waiting. They wanted to wait to do the plan.  They wanted to wait until everything was known.  Until at least much more was known. And, as they know, the Plan would be better if they knew more.

This is a very normal human reaction. (And this group was not unusual in this way.)

But this is not the way of life.

Life changes, we learn.

We must always be changing the plan.  So, we do not do Agile Release Planning to have one Plan.  We start Agile Release Planning now, while we are relatively dumb, so that we can learn, so that we can discover what the plan will become.

And we want to discover that with the crazy human beings that we are working with (the Team) and working for (meaning: the customers).

I say 'crazy' in a most affectionate way.

Crazy in a nice way, crazy in an inexplicable way, crazy in an emotional way.  Crazy in far more ways than we have understood yet.  Because what it means to be human, to be a customer, a teammate, a friend, another stranger on the road…what it means to be this we still do not know.  The customers and the teammates are, for so many reasons, both good and bad, changing all the time.

So… we do some planning, relative quickly, and we ask our co-workers to work with us, and help us figure out what we are doing, and how we shall do it.

Lesson 1: We plan now, even with very imperfect information. And then we evaluate, and think about what we need to make a better plan.  And we do some of the work, and then we learn more, and re-plan.

Let me also add this.  Sometimes it can be true that, before taking a path, some things must be known. Or at least...if we choose one path wrongly, it may be hard to change paths later. So, we want to know more.  If you are convinced you have this type of situation, you have a much higher need for more information early.  So, use common sense.

But we caution you. At least with a software product, and with many other products, from experience we guess that you are again using one of the standard rationalizations for procrastination. "I need to know more first."  Analysis paralysis, as it is often called.  Almost surely, yes, review what you know now, but then learn from taking action.  The school of hard knocks is a wonderful teacher.

Comments?

Choosing a Scrum trainer/course

This is a question I get from time to time: How should I choose between one course/trainer and another?

This is an important question and deserves some thought.  It does not deserve, in my opinion, a simple answer, as one might get from Zagat's about a restaurant. The choice is very much different than choosing yet another restaurant.  For most, this is a once-in-a-lifetime choice.

The good news: Most people (I'll say 95%ish) are happy with their choice. Or so I hear. But did they make the best choice for them?  Very very hard to know.

Here are some criteria for you to consider. I believe you can think for yourself once you have some context or framework (a key Scrum theme).

1. Date, location, price. Yes, of course. You may think I am biased, but of those, by far the least important should be price.  Because in relation to the benefit, it is trivial.  OK, these three were obvious.

2. Course/workshop goal.  Yes!  What is the real goal of the course and the goal or goals of the instructor.  Even though they all say "CSM course", they do not have the same goal(s).

My goal is this: I want results for the attendee, for the team, for the customers.  To me, those results are the only things that count.  But I am sure many other CSTs (trainers) would say something different. Or would not agree.  Or would at least word that challenge differently.

3. Instructor personality: Yes.  Trainers have different personalities. And this affects how you learn.  How would you learn about this?  Well, one way is to read the trainer's blog. You might want someone who is the opposite personality to you.  Interesting ideas.

4. Instructor background: Not simple.  But if you are in finance in NYC, you might want a trainer who knows finance in NYC.  And a zillion other examples.  It can also be argued that, other things equal, the buyer should get it from someone who is from a different background. Maybe.

5. Instructor teaching approach: Each trainer has a somewhat different teaching style. To give an overly simple example: some use mainly a slide deck, some have no slide deck at all.  One related idea (theory): the training style should match your learning style.

6. Experience with Scrum. Some instructors have more experience with Scrum than others.  Jeff Sutherland and Mike Cohn would be good examples of that.  They have been doing Scrum for many many years.  (Oh, you thought I would only recommend myself?  Wrong.)

7. Accuracy of describing Scrum.  Umm. Some trainers understand Scrum better.  I do not know how wide the divergence is amongst the Scrum trainers.  I do know you will not hear the same thing from each one. Even about what I call 'the bare bones of Scrum'.  And certainly not about what things to add to 'the bare bones' to make it work better, but maybe that is different than 'accuracy of describing Scrum'.

8. Ability to explain the 'abstraction' of Scrum in a way that seems (is) do-able and practical in your specific situation.  Umm. Seems pretty important, right?  And yes, it is related to some of the other things already said.  But it is different.  One suggestion: read the trainer's blog.

9. Workshop or not. My colleague Catherine Louis got me, against my better judgment to try doing a third day Workshop. So, now I do that all the time. Most Scrum trainers do not. Or they do a different kind of thing.  In any case, that is an important part of the choice, in my opinion. Suffice to say that I think the Workshop is very valuable, based on feedback from the attendees.

I am sure there are more criteria. But that is a good start.

One thing I suggest you not pay attention to....

First, there is a thing called NPS (Net Promoter Score).  It is used a lot on normal products, and many smart people (not all), think it is very good. I usually mention it when talking about the Business Value of products.
First, I think the course/experience/situation in a CSM course is very different from a normal product.

OK. Some trainers gather an NPS score. From attendees who have just completed the course.  I do this also. (For me, I find the information somewhat useful.)  Each trainer attracts, for many reasons, different kinds of attendees.

If you get a chance to compare NPS scores across trainers, don't.  You do not yet have enough information to compare those numbers.  After you have taken the course from both trainers (of course, the first trainer will bias your observation of the second), you will almost have enough information to compare the NPS scores between both those classes.  If you could see only the NPS for each course (and both trainers would likely show those numbers to you, if you asked).  But NPS numbers averaged over a year's worth of courses will not be meaningful.  To you (although perhaps a trend line might be meaningful to each trainer).

In general, for all the trainers I know, the NPS will be high, and the differences between the NPS scores will not be meaningful. Certainly compared to other factors.  IMO.

Hope that helps. Interested in your comments.

***