The Problem
The biggest problem with this is that one of the most important jobs of a Product Owner is to prioritize, so to have a Product Owner who doesn’t understand the importance of prioritization is a problem that must be handled immediately.

Why is prioritization so important to an Agile project?

Agile makes it clear that change is an inescapable fact of life, but how do we deliver a successful project in this reality? The only way to do this is to ensure that:

1. We maintain a high level of quality throughout the length of the project.
2. We tackle risk and integration early and often.
3. We make sure we do the most important things first so that we reach our Minimal Viable Product or the minimal product we can release as early as possible.

The Problem

Product Owners, regardless of previous background, find it hard to understand why we need small stories in Agile. In the Kanban-Scrum war, I think this is one of the only always agreed on topics. If you’re working Scrum you need stories that are small enough to finish in a Sprint, and if you’re doing kanban then you want stories that will flow quickly from end to end.

This boils down to feedback loops. In Agile, one of the biggest benefits we get as short feedback loops. These loops can be between R&D and QA, between R&D and the PO or even to the end customer. This is why we want working software, so that we may demo it, get feedback and respond to change if needed.

Even if they understand the need, new POs find it hard to break stories into very small chunks which have business value. The reason for that, is simply that it is really a had thing to do. This is a new technique and mind set that one needs to learn as an Agile PO.

How do we solve this

There is no easy solution here. It takes time and experience to learn how to break stories correctly. Time can be saved by mentoring, either internal or external, and by reading books on the subject, but even than it takes time.

The team needs some patience for the not perfect stories at the beginning. If the PO is serious about trying to write this stories he will succeed, it just takes time.

Are there stories which cannot be broken and retain business value? Yes! But from personal experience I can tell you that they are few of them. So if you think you found one, good for you, think again, talk to someone else to get another perspective, because just saying that it can’t be broken is the easy way out. Try not to take it unless you are sure this is one of those rare cases.

The Problem

So this is usually the first problem we encounter when teams shift to Agile. The developers move to Scrum, Kanban or any other system, but Product Managers, or Business Analyst view this as an internal R&D mumbo jumbo, which should not affect us.

When they are asked to change their behavior (writing stories, creating requirements on the go, etc.), they resist.
Now, doing Agile without customer involvement, while still valuable loses a lot of its effect.
For me this is a funny problem, but it happens a lot. Agile benefits, mainly, the business and I would love to see more companies move to Agile do to the pressure of the business and not because R&D wants this.
How do we solve this

1. Education – The best way is to educate the potential POs, and work with their managers to explain why Agile is for their benefit and how they can improve the products and the bottom line with Agile practices.
2. Honey trap – Another way is to build confidence in them by writing stories with business value in R&D and invite the business to the demos just to see the progress and asking for their comments. Share the goals and show that you meet them.  This gradual involvement shows them the benefits, builds trust and draws them in.

It was very hard for me to squeeze my talk to 12 minutes but I hope it made people want to see more and I want to thank all those who attended for the great feedback.

Thanks to Cesario and Pascal you can now see all talks online at http://www.bathtubconferences.org/bathtub/, I have also put mine here in this post for convenience.

Come to the next online confereance, as I’m sure it will be fun.

I have to say that I agree. It’s funny to see, though, that Agile is usually perceived in exactly the opposite way, as a soft skill concept with no real project management skills.

Maybe this is the beginning of a new trend in the understanding and maturity of Agile.

Here are the slides from my talk, I will post later answers to some of the questions I received.

In my opinion, the reason to have different personas is in order to understand better customers to whom we have different value proposition.
This means that if there are different users in the product for whom the value proposition is either the same or very similar I would group them into one persona.

Now let’s discuss the difficulty of handeling so many personas and discuss several options of reducing that number.

Let’s say, that each of the personas you describe does represent a value proposition from your products, that is inherently different that those of the other personas.

First, let’s remember that they will still be split among the three product we have, X, Y and Z, so each product will have less personas to handle.

Second in a persona we want to capture a real (although an amalgam) user, if we have a someone who’s sole job is to do a specific type of work that’s one thing, if he does,several types of work, as far as the persona is concerned this is just one persona with many needs, just like the real life situation. We want personas to mimic life not to be one dimensional characters that represent an aspect of the business or of real people, this can even hinder us in understanding requirements, such as understanding that this might point to the fact that one persona needs to use three product which could be a problem.

If even after all that we still feel that we have many different personas, I would urge you to create, manage and keep all of them. This will help you focus on which personas are served in each release, and which have been starved for several releases. Personas we keep starving, might be off our radar at the moment, and in this case I would stop managing them since, we are not offering them any value propositions, right now.
For each release have a grid, mapping requirements to personas to help manage the starvation issues.
Another thing this matrix could help you see, is that if some requirements are always serving several specific personas and those personas are always served by the same requirements then this means we don’t have a clear and different value proposition for each one, either combine them into one persona and one value proposition or create a value proposition and requirements that would separate them and set them apart.

I see value in having a physical project board even if the company is using an electronic tool. While most of the information can come by printing reports from tools, one cannot get the full picture in one view on any decent type screen. I also see value in the fact that this board is constantly open and available to the manager, the teams and other managers.

If the company has an amazing dashboarding tool which can present the status of the project or value stream on a single big screen, and such a screen is available and always turned to this dashboard, that is equally good. However, trusting people to login to tools run reports and get a composite view of a project detracts from the clear visibility needed in an Agile environment.

Regarding team boards, I think, that having a physical always-on board of every team is critical; this can be a truly physical board or the electronic representation of one using any tool. I think that even if an electronic version is used several physical artifacts will be needed to complement it.

Since the board’s point is too allow the team and any other interested party to view the status of the team, having it hidden inside a tool is not true visibility. It also takes away responsibility from the team as there is often one person updating the tool, and the rest never look at it. A lot of the time, if you ask them about the status of the team they would refer you to the tool and have little or no direct knowledge of the answer. The investment in a large screen for the team board is in my opinion, necessary.

This echoes Pascal Dennis’s thoughts from ‘The remedy’: “My questions elicit either blank stares or assurances that, ‘It’s in the computer.’ That’s what we used to say at NJMM. We’ve learned that the ‘what’s in the computer’ is usually wrong…It was a recurrent theme with business processes. Information was always in a box called the computer…Take information out of the box known as the computer and make it visible and understandable to users…Don’t trust the computer screen, report, or phone message. Genchi genbutsu – Go see for yourself!”

We also want the place we visit to be physical place to avoid the temptation to do it in a room with a projector instead of actually walking the Gemba. Part of the benefit of doing a Gemba walk is to actually wander around the people; you will be surprised how much enthusiasm seeing management touring the board would instill in a team. You would likewise be surprised to see that as time progresses more team members come to their board to listen and answer questions. All these benefits would be lost if we stayed in a room and used a projector.