In Scrum one of the named roles is that of Product Owner.  Some people have taken to referring to this position as the “single wringable neck” on a Scrum team.  This is because the Product Owner is ultimately responsible for the prioritized product backlog which the team uses as their to-do list to build the product.  If the Product Owner does a poor job then the resulting product will not meet customer needs.  That scenario leads people to believe the Product Owner should be held accoutable for the failure.

To me this is very short-sighted.  The Product Owner has a LOT to do without having this additional burden placed upon them.  Because I want to keep this blog entry short I will give 5 reasons why the “single wringable neck” concept has to be left behind:

1. Product Owner’s normally do not have sufficient training to do the job well.  We often here of Certified Scrum Masters (CSM), but we don’t hear about Certified Scrum Product Owners (CSPO) nearly as much.  This is a shame.  If they are the single wringable neck, why not give them a fighting chance by giving them some training specific to their position.  I don’t care if the training is a certified training or not, so long as it is good, solid training.  A few months ago we had our Agile Product Management Boot Camp which is a great way to get this training.
2. Some organizations isolate Product Owners in a way which does not allow them to interact with customers properly.  I’ve actually heard sales people say “We can’t have the product person talking to our customers – it would just confuse the customer.”  When I heard this I think my reply was “In other words they might tell the customer the hard truths?”  You can guess how the conversation went from there.
3. Many organizations expect too much from their Product Owners.  Product Owners need to interact with the team and customers on a regular basis.  They also need to be doing other forms of market research.  They may need to attend trade shows.  They may be involved in Change Control Board meetings.  They may prioritize defect lists.  They may be helping the marketing department develop materials.  They may be creating nice charts and fancy reports for executives about how products are expected to perform.  They may…   The list can go on forever.  Please make sure your Product Owners have time for what is truly important.  Find other ways to accomplish the tangential items.
4. Product Owners don’t get to understand lost sales.  If you are trying to create a product to grow your market share then finding out why you lose sales is CRUCIAL!  Lost sales is a huge potential source of product ideas.  Talking to current customers may help you maintain your market share, but it isn’t guaranteed to grow it.
5. Product Owners ultimately report to someone else and that someone else sometimes makes inappropriate decisions.  Sorry to be so blunt, but this occurs more often than anyone wants to admit.  How can a Product Owner be held accountable if someone else ultimately pulls the strings?  Worse yet, the person in charge often doesn’t admit the errors were their fault.  This all falls in the category of sad but true.

As you can see, I don’t agree with the single wringable neck concept.  I believe a team creates products and all members of the team contribute.  A Product Owner may ultimately be one of the major contributing factors to failure, but it is rarely the only one.

Until next time I’m going to be Making Agile a Reality^® by helping teams get effective training and coaching for all team members including Product Owners rather than concentrating on just one or two team members bringing information back to the team.

Related posts:

1. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
2. New to agile? Give thanks! Here in the United States we will be celebrating the Thanksgiving holiday...
3. Agile pondering: How does agile work with a team of 1? See that picture off to the left?  That is me and my...

Time for a short blog entry (I tend to be way too verbose!). I often see teams trying to make sure they have all of the requirements for their projects before they start doing any substantive work on the project. Unfortunately, this often leads to long delays at the front of the process which in turn causes the rest of the process to be squeezed. The Nokia Test for Agility underscores this point by having one of the questions be about specification. See this blog entry to learn more about the Nokia test and look particularly at bullet #3.

Remember a few things when you are tempted to get all of the requirements up front:

1. Requirements WILL change.  In courses I teach the average percentage of requirements which change is 50%.
2. Requirements WILL be dropped.  We almost always think we can get more done than is possible (or even desirable in many cases).  It seems the average percentage of dropped requirements is 25%.
3. New requirements WILL come up during development.  This too seems to average about 25%.

When you take all 3 of these things together you quickly realize you are fighting a losing battle by trying to “get the requirements right” up front.  Get the requirements good enough to start moving forward.  Once work starts requirements can change, be dropped or new ones can come up easily if you truly embrace the agile principle to inspect and adapt.  Keep looking for what will make the product better, not necessarily what a requirements list says from a few months ago.  This isn’t up to the developers themselves, but the product owners and others who maintain the backlog.  Build GREAT products by adapting to changing conditions.  EMBRACE change as a good thing, not as an impediment.

Until next time I’m Making Agile A Reality^® by focusing on emerging requirements over time, not trying (in vain) to get them perfect up front.

Related posts:

1. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
2. Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...
3. Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently.  This...

The primary way I see teams release products faster is by reducing the scope of each product.  However, this can’t be done in an arbitrary fashion.  There are real business reasons for each feature request (hopefully anyway!).  Having seen teams reduce scope successfully I’ve seen three primary ways it can be done.  In order to deliver 50% faster teams can:

1. Deliver 50% fewer features
2. Deliver all features but with 50% fewer bells and whistles per feature
3. Deliver all features with a sliding scale of bells and whistles per feature

Let’s look at each of these separately to see how they work.

Deliver 50% fewer features – This one is obvious and the easiest to make work.  Because agile uses a prioritized backlog of work, a product owner can simply have the team work in priority order until enough value is delivered to make a reasonable release.  A danger here is not being aggressive enough on how much is enough.  Most product owners still go overboard and allow features to be added until the product is well past the point of being releasable.  I believe this is due to product owners being conservative by nature.  Again, this method is simple and effective, except when the sales and marketing teams have “promised” features which are further down the priority list.  If a team delivers 25 of 26 promised features the customer can be upset.  If they deliver the same 25 features when only 20 were promised they are instead praised as heros.  Be very careful with the external commitments so they can be met!

Deliver all features but with 50% fewer bells and whistles per feature – This is a bit different.  It avoids the problems of the method above because all features are being delivered.  This method is relying on studies which show 64% of features are rarely or never used (Standish Group).  In order to deliver 50% faster, 50% of each feature could be eliminated and statistically still not hit the “core” of the software which will be used most of the time.  The drawback here is each feature is treated equally and there is a likelihood too much will actually be cut from some features and not enough from other features.  Which leads to the final method…

Deliver all features with a sliding scale of bells and whistles – In this method the highest priority features are fully developed while the least important features are developed only enough to say they work properly.  The features in between the extremes have a decreasing amount of robustness for each drop in priority.  This allows for the most important features to be the most useful and the least important features to be the least useful.  This overcomes the objections of the first method because all of the features are delivered, while also overcoming the objections of the second method by delivering maximum value for the highest priority items.

I think of the three methods as slicing scope horizontally (a horizontal line through the backlog showing our last feature to be developed), vertically (a vertical line to the right of each backlog item showing how much of it will be developed compared to the maximum) or diagonally (a slanted line to the right of each backlog item showing how much will be developed compared to the maximum).  The first method is clearly the most common, but the problem of leaving off externally promised deliverables is very real.  The last method is much harder to accomplish, but it can be done.

In the last method one way to accomplish it is to create a thin slice of each feature during early iterations.  In this way the product owner knows all the features could be delivered at any point in the future if robustness didn’t count.  From that point forward the product owner can prioritize how much time and effort should be applied to each feature and create the appropriate sliding scale – even properly accounting for changing priorities if necessary.

Too often we fall into the trap of believing every part of every feature needs to be delivered.  When expectations are properly set this is rarely the case.

Until next time I’ll be Making Agile a Reality™ for my clients by helping them cut scope using the method which allows for maximum value to be delivered in the minimum amount of time.

Related posts:

1. What do you want next? The software industry today is plagued by long release cycles for important...
2. Ten Ways to Improve Your Planning Poker Results People who promote the use of Planning Poker understand some of the main...
3. Agile antipattern: Using manual tests In an agile environment manual testing is fine – except for when it...

I was just working on some Powerpoint slides for our Agile Product Management Boot Camp coming up on March 9 and 10 and I realized I should post a blog entry about the point the slides are making.  Actually, I’m trying to make two points with the slides.  The first point is we tend to work in organizations where the phrase “everything is priority 1″ is common.  The second point is my personal distaste for using the phrase “prioritized product backlog.”  I’ll cover each of these points separately.I’ll start with the “everything is priority #1″ problem, since that is the title of this blog entry.  Let’s be very clear THIS CANNOT BE ALLOWED!!!  There are many blog posts on the web such as the ones here and here.  I like what the first of those links says about how to explain why everything can’t be priority 1 – we can’t build it all at once!  I usually approach this with product managers/product owners/stakeholders by asking them what they want if they can only get one thing.  They quickly say one thing is useless they need it all.  To which I reply, I know, but I want to make sure we have the most important item built first so we can learn from it and make changes to other items based on what we learn.  I’d like to rank all of the items 1 to whatever, with no ties, so we can always be working on the next most important item and be able to learn from it as well as all the other items which were more important.  This way we will make sure the most important items are in the release and meet expectations.

Which leads into my second point about the phrase “prioritized product backlog.”  If you simply say the words, nearly everyone in the software industry will say  they already do that.  Why are they saying this when a casual observer can tell it isn’t true?  It is because we have overloaded the word prioritization.  Most software people think having a list of 100 items which has the top 97 as priority 1, the next 3 as priority 2 and no priority 3 items is a prioritized backlog.  Sorry folks, but that is a useless list.  We really need a RANKED backlog, where the rankings go from 1-N and there are no ties.  Then we use the list by making sure we work on the next item in the ranking, not just work on some random thing which seems interesting.

We simply have to keep these two issues in mind when we are dealing with the product backlog or we will not be successful.

So, what do the two slides look like?  Here they are:

This is the first post in the “Agile Antipattern” category.  I anticipate having a few more over time.

Until next time, let me know what you think so together we can be working toward Making Agile a Reality™.

Related posts:

1. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
2. Agile antipattern: Sizing or estimating bug fixes Is the bug to the left a large bug or a small...
3. What do you want next? The software industry today is plagued by long release cycles for important...

Tired of not knowing exactly what to create or test? Get in the habit of asking the magic question “How will I know I’ve done that?” In other words, ask the Product Owner (or whatever person you have filling that role on your team) to express some acceptance criteria!  Asking this question will make miserable days seem bright and sunny!  Well, ok, maybe not that, but asking this question will brighten your mood.  There are at least three good reasons why asking this question is important.

First, the answer clears up uncertainty.  As I mentioned in my blog post Bob-ism #1 – the good developer it is very easy for developers to build the wrong product if they aren’t careful.  Being careful means uncertainty on the desired functionality needs to be cleared up as early as possible.  There is no such thing as the perfect Product Owner who creates 100% unambiguous stories that never generate questions.  This is impossible because it absolutely should not happen.  The concept behind stories is they are an invitation to a conversation. The conversation should start with “How will I know I’ve done that?”  Members of agile teams need to recognize the necessity of clearing up uncertainty, and Product Owner’s need to understand the necessity of making time available to help.

Second, the answer gives acceptance criteria. Acceptance criteria are useful to every person who deals with a user story.  Developers know how the code will be tested. Testers have a basis for knowing what tests to create.  Wouldn’t it be nice if acceptance criteria could directly be translated into automated acceptance tests?  Well, we have a class on Real World Agile Testing with Fit and FitNesse coming up.  The class is basically to teach how to do that!  Even if you don’t take the class, look at Fit or FitNesse as potential ways to translate between spoken language and automated tests.  But all of this is based on knowing what the acceptance criteria should be, and the answer to the question “How will I know I’ve done that?” gives the criteria.

Finally, asking the question fosters collaboration.  Remember, a user story is an invitation to a conversation.  By asking “How will I know I’ve done that?” you have accepted the invitation.  Imagine if all teams had developers, testers and Product Owners collaborating up front on stories and all being in agreement on what “done” would look like - all before a line of code was written.  For those of us who have seen this in action it is truly amazing.  Teams become hyper-productive.  Features match customer wants and needs much more accurately.  Quality improves dramatically.  Morale on the team improves.  All of these are downstream effects of effective and meaningful collaboration.

Let me close this post with a couple of very important caveats:

• Don’t collaborate in a vaccuum.  If one person needs to ask this question, there are likely others also needing to know the answer.  Make sure you have the proper people as part of the conversation.  This usually means developer, tester and Product Owner are all involved.
• Capture the answer!  This seems so silly to have to say, but it is quite common for people to have a conversation and not record the results anywhere.  This conversation affects the user story, so capture the answer in a place people will know to look.  The answer is acceptance criteria.  It may even clarify some wording in the story itself.  Whatever it is affects the story, so save it appropriately.  Remember, knowledge in your head is lost to the rest of the team – so what happens when you aren’t available???

My user story today was “My readers want a new blog entry so that they can be more agile.”  I asked myself the question “How will I know I’ve done that?”  The answer was “I’ll know I’ve done that when I have a published blog entry my users can access which gives them a useful agile tip.”  So the acceptance criteria are:

• blog entry published
• users can access
• contains a useful tip

I tested the first two and they work.  Did I accomplish the mission for the 3rd bullet point?  I certainly hope so.  If not, let me know!

Related posts:

1. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...
2. Agile Architecture and Agile Testing – New Courses on the horizon Exciting news!  Some associates of mine are currently completing work on some...
3. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...

The software industry today is plagued by long release cycles for important products. That is one of the many reasons why companies are going to agile methodologies. In doing so companies hope to deliver software on a more regular basis. They feel this will make for happier customers. Of course I’m not going to say they are wrong, but it goes far beyond the fact that they get more frequent deliveries of software.

I believe one of the biggest differences comes from how the “feature bus” is different in an agile environment. When using non-agile methods we still try to ask the customer a question like “What would you like to see in our product?” Our problem is that our customers recognize how software development occurs and what they hear is something like “The feature bus is here, so I better pile in as many things as I can think of because this is the only stop it makes this year!” The worst part about this is the recognition that what they hear is probably true. It leads to conversations like this:

Us: What would you like to see in our product?
Customer: (lists 100 items including things they only peripherally think they may need some day)
Us: Wow, that’s a big list! Let’s be real here. What do you really need?
Customer: OK, you’re right, those last 3 items out of the 100 I don’t need.
Us: I don’t think you understood. What do you REALLY need?
Customer: Ok, throw out #96 as well.
Us: Let’s try a different approach. Which items are most important to you?
Customer: Oh, in that case, only the first 90 are really priority 1, the others are priority 2.

As you can see, the conversation is rather fruitless. With good reason. After all, we don’t usually deliver products frequently enough for our customers so we have trained them to behave this way.

Agile changes the model dramatically. With frequent software deliveries and potentially even more frequent iteration demos (you do invite customers to iteration demos don’t you???) the customer gets used to seeing things in a much shorter timeframe. They understand that they don’t have to pile on the useless items where they don’t have much clarity yet. If they concentrate on important things they will get those quickly. The world changes when we can ask the initial question as “What do you want next?” Instead of an open-ended question asking the customer to dump everything on us, we are asking a slightly closed question where the answer may be only a few items. Plus we get a bonus out of this – how hard is it to prioritize a few items vs. prioritizing 100 items?

When we change the frequency of the feature bus we will change the behavior of our customers. Most surveys say the #1 or #2 most critical project success factor is having early and frequent interaction with the customer. This is a great agile practice that often isn’t used to full effectiveness. Start inviting customers to demos and asking them what they would like to see next. You will be astounded at how quickly their trust builds and how quickly you start making better products because of it!

So, what would you like to see next in this blog?

Related posts:

1. Agile pondering: Is it agile to have a “single wringable neck?” In Scrum one of the named roles is that of Product Owner. ...
2. Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...
3. New to agile? Remember to respect people One of the Lean Principles is “Respect People.”  I think it may...