Category: Agile and Lean

Forgotten practices: The Backlog Priority Game

Backlog prioritization is one of the most difficult parts of Agile adoption for many companies. So, what is the right way to do it? Are there any recommendations or methods, or is it just enough to let Product Owners decide? These and similar questions are often raised.

When it comes to backlog prioritization, the most common scenario is that the company starts by objecting that: “We’ve always done requirement prioritization and it has worked somehow in the past, so why should we change anything?” Once you dig in and try to understand their practices, you find out that the reality is usually not at all harmonious. The team has a very low understanding of the business value of individual functionalities and usually has freedom to choose the order, since it all has to be done anyway. All the business is interested in is whether they are delivering the release on time. So, starting Agile, the user stories usually have three types of priorities: 60% of them have priority “1”, standing for functionality that must be included; about 30% have priority “2”, standing for functionality which also has to be there; and the remaining 10% have priority “3”, standing for functionality which should most likely be included as well. Maybe ‘prioritization’ is the wrong term, and it would be better to use the word ‘order’. However, all expressions can be misunderstood, so we cannot blame the name for our troubles. Teams affected by such dysfunctional Product Owners have a few options for making it work. One of them is to create the role of Product Owner Proxy who tries to overcome the gap and grasp the missing business context as quickly as possible. Another is to push back to the Product Owner and simply tell him it is his responsibility to choose the priorities for the next Sprint and if he does not we might simply just deal with them in alphabetical order.

Having backlog ordered in this way, and presenting it back to Product Owner with thick red line at the position counted based on real team velocity to visualize which functionality is going to be delivered  with the release (above the line) and which most likely not (below the line) usually brings Product Owner back to prioritization process. Such a picture usually creates strong enough pressure to make the Product Owner take action and start to consider changing the actual priorities and functionality. That is the time to play the “Relative Weight Game”.

Let us say you are a product company

In such a case, the key to prioritization is as simple as that. Focus on business value and its cost. If the ratio is high, invest in that functionality. If not, take some actions to improve it or remove the functionality from your backlog.

The following method will support you in this approach. It is not new, but not many teams know about it. The method is based on relative weights, following the same principle as the relative point estimation often used by Agile teams to size the user stories. The idea is simple. Because most of the power of Agile methods comes from teamwork, we start by building a product team. The Product Owner can actually play this game alone, but then he is missing other people’s points of view and the lack of discussion means he might run into unexpected problems while dismissing important aspects of the business value. The team structure many differ depending on your product, company structure, and roles. In a company producing a box product with some level of customization, the Product Owner would usually involve business analysts, the user experience person, SW architect, or manager. At some point he may also involve the consultants or customer representatives in the discussion. The decision as to which priority the particular user story is given still remains with the Product Owner. However, the discussion among the parties involved is often very valuable and allows the Product Owner to make a much better quality decision than if he were to decide on the priorities by himself.

The Product Owner is still the key person in this process. He organizes the meeting; facilitates the discussion; and takes responsibility for the decision making, overall functionality, and, thus, the success of the whole product. The role of the user experience expert is often underestimated in companies. However, such experts are crucial to successful products and their point of view on business value might be the one which is missing in most of the final products. Experts like these help the Product Owner to simplify functionality while retaining business value. The next proposed role for such a team is that of Business Analyst. The role itself is quite controversial, because it is usually missing the connection to ROI, trying to make functionality as extensive as possible to satisfy all potential customer requirements. This is particularly noticeable in formal environments where everybody sticks to their own role and where the competencies are formally divided among parties. In this case, the Product Owner has the high level vision and strategy and does not care about the detailed level of the particular user stories. Conversely, business analysts lack the context of the customer relationship and environmental specifics. So, creating a single team out of them with a common goal is actually a good idea and can be quite helpful even on its own. Another suggested role could be that of Software Architect who can prevent the Product Owner from taking technical risks, e.g. if the team has no experience of using the expected technology, it might be wise to spike around the problem and build some prototypes, or deliver one user story to burn that risk. After all, it is the architect’s role to be in touch with the customer as much as possible and propose solutions that not only make sense from the technology perspective but are worth investing in for business reasons. The group is not limited to above mentioned roles, so feel free to invite anyone who might give you a valuable opinion.

Business value estimation: Relative Weight Game

Once you form a product team, the game can start, with the point being to estimate business value. Because the discussion is the most significant part of the point estimation process, the same applies to the business value estimation game. You, as a team, are going to estimate two independent values for every user story in your backlog (which, by the way, directs the discussion). Because the team is formed of various kinds of people, all the different aspects are considered. The first value you are going to estimate is “Benefit” – meaning how much you weight the value of this functionality. The second value is “Penalty”, which stands for the weight of the loss if you do not implement that user story. Each estimation value is relative to each other of the same kind. Usually we estimate in a range from 0 to 100 for both of these values. For example, the user story which represents the functionality everybody else on the market has, and is therefore expected, might be given a very low Benefit value, close to 0, and a Penalty of around 100. Conversely, a user story that is a differentiator from the competitors and really makes a difference to users might get a Benefit value close to 100 and a Penalty value of 0, as no one expects anything like that anyway. The key stories might be given 100 and 100, but most of the features will be given a value in between. Do not forget that Benefit and Penalty are independent of each other. You can play Planning Poker or do Magic Estimations to get the values, but remember that, to get good estimates, the numbers are just a side effect of the discussion, so do not try to cut it down to get the results faster. You need to take a business point of view, so you should be looking at the estimations from the customer’s viewpoint. You might say that this is not very different from what you usually do, but the need for the two different perspectives of Benefit and Penalty will make sure you do not omit any important aspect. Most prioritization done by companies  only uses intuition, usually just considering the Benefit side and only reflecting on the Penalty in very significant cases, if any at all.

As soon as you have those values, you can add up the estimates and the result stands for Business Value (BV):

Benefit + Penalty = BV

The numbers will be somewhere between 0 and 200. You could simply mark it done and just prioritize your backlog according to the business value, and it might seem to be right. However, in many cases, you need to play a bit longer and let the team estimate Complexity so you can compare the ratio of the cost of business value for each user story. The result of the calculation is the priority of the backlog item:

Priority = BV / Complexity

You will see that the “quick wins”, where the cost of business value is cheap, are escalated to the top of the backlog, while the extensive and difficult features with limited value are moved to the very end. Note that these are just numbers, so if you do not like the result, feel free to change it. However, you might consider having a closer look at it and recalling the discussion once more. Usually you will find that the Benefit and Penalty were not estimated correctly as independent values or, even more likely, that the user story must be split into smaller stories to improve the ratio, as Business Value and Complexity are never distributed equally over the functionality. You will find out that there are some elements which are delivering value and might not be so difficult to implement; while there are other elements which have only a limited business value and these might be the ones that are pulling the feature down. For example, drawing some data in a chart with a few pre-defined filters might be enough to satisfy the user requirement, but enabling customers to create the filters might be the difficult part. Do not forget that, according to several studies, about 60% of successful projects are never or hardly ever used. It is hard to cut the functionality, but if you involve customers in the prioritization process and explain to them the cost of the feature they might quickly come on side.

The Relative Weight Game is not very well known by the Agile community, but it delivers very good results in any product-oriented development. More than that, it is easy to implement and fun to play as well.

The article was published in Agile Records No14, May, 2013

Agile Adoption Story – Common Mistakes (part 6)

And finally, to finish the agile adoption story, even though the team is after all able to find their way to communicate, share knowhow, learn from each other, and cooperate, there is another obstacle. Surprisingly it’s not outside the company but in the business unit internally.

Company doesn’t need to change

The company doesn’t need any change. It used to be working good for many years, and if we had observed any problems, they were indeed located in the ICT, so why should we change the business unit? Isn’t Scrum called software development methodology?

Oh, yes, Scrum is business driven, but here are the requirements, so take them as they are and if you need to make any User Stories out of them, sure, feel free to do it. But we are not really interested in your internal processes so don’t bother us. However, we expect you to finish all this work on time.

So the teams are desperate again. Unless they got Product Owner, who is willing to become part of their team, and share the risk and success with them, they can’t proceed with real Scrum. They can’t take all responsibility and gain success in return.

Unfortunately, some get frustrated from the lack of business support and still complaining “Agile is not for us”. We are different, we have too complex product, we are too big/small to implement agile. Our customers are like this and that, and you know, agile is great, just for a different company.

Agile Adoption Story – Common Mistakes (part 5)

So what happened next in the agile adoption story? John starts to be really frustrated. Is all agile just a rumor? Or did we make any fundamental mistake?

It’s just a process, follow it!

So he went to the team, be really strong and say “It’s just a process so follow it”. They were weak in following the practices; they abandon most of the particular practices. So somewhere there must have been the problem. If most of the companies reporting agile works great, why agile shouldn’t work for us.  That’s because they are still complaining, asking for some change… They have a team fully allocated team now as they requested, so what would they need next? Let’s make a brainstorming in our management group and find out how the individual practices are supposed to be implemented. Then use them and make sure they are not adopting them according to their preferences. Let’s make sure Scrum Master controls all the activities, is strong enough and able to decide instead of the weak team. Let’s make him personally responsible for the team ability to deliver, quality and overall team health. We can put it into his KPIs.

However, the given process, regardless how good it was invented, could not ever bring any commitment, understanding and responsibility. The people just pretending they are following it and keep finding some sideways and complains. Finally, when you asked them, they keep saying “Agile is not for us”. We are different, we have too complex product, we are too big/small to implement agile. Our customers are like this and that, and you know, agile is great, just for a different company.

 

 

Agile Adoption Story – Common Mistakes (part 4)

But John still feels we should continue with agile adoption process started in previews articles of agile adoption story. It’s not going well so far, however, we just spent some money on training so we should give it a try. The project manager even if he is now called Scrum Master is keeping the common practices; we had still the same allocation system and organization structure. So when the Scrum Master got one-one meeting with John, he must admit Scrum process adoption has some issues ant it’s not really successful so far. But as John needs any improvement, he finally asked: “ok, so what needs to be changed in order to make Scrum working in our environment?”  And the Scrum Master selects the most crucial thing which bothered him – the allocation of the people.

Group of people makes team

Scrum is based on team cooperation and collaboration, so how should we use Scrum in the current conditions where we never know in front what time we got resources, people are allocated in front and took out of the project without any in front notice. They are sitting somewhere in the office matrix without any direct connection to the project. So let’s imagine they are just because of Scrum process moved to one shared place and from that time they are called “team”.

How this could work? Starting from the university, those highly specialized engineers were learned they are good enough to work individually on their tasks; any help offered there was called cheating. And now, they should work together? Even more in the company where were built strong silos called development department, testing department, and so on. And those silos have different managers with different goals. Those managers usually don’t like Scrum at all, as they had to delegate their responsibility and got less direct influence on the individuals.

However, the particular engineers happen to be sitting together in one room, having a Scrum Master, who is trying to sell agile to them. In a reply, he is often hearing questions like why do we have to talk so much, why should we select what are we going to finish? Just tell us what to do and keep us working. We are specialists and so we can’t lose our expertise in sharing knowhow.

So finally after some time, the Scrum Master is in John’s office saying “Agile is not for us”. We are different, we have too complex product, we are too big/small to implement agile. Our customers are like this and that, and you know, agile is great, just for a different company.

 

Agile Adoption Story – Common Mistakes (part 3)

To continue with my agile adoption story… The company started to realize that Scrum is not any silver bullet. It’s much more complex than that. But John is really upset. He did all what he could to make it better. But maybe the people inside his company are not good enough to make it. And it’s so simple, just follow the process and keep the practices. What’s the point? But even John must admit he doesn’t know answers to all the problems his Scrum Master is putting on the table, so he finally agreed to give it a next try – let the Scrum Master to get a certification.

Let’s make a certification

So next week the Scrum Master is sent to the Certified Scrum Master Course, CSM, to become an expert. With high expectation from the training he supposed to understand all the difficulties of Scrum from that time and he should be able to adopt the Scrum methods in a way the company needs. Nonetheless in nine out of ten cases the Scrum Master understand the theoretical ideal case of Scrum implementation, get some idea of how is should be, however, when he try to apply it in the company or even change outside company environment he must admit that “Agile is not for us”. We are different, we have too complex product, we are too big/small to implement agile. Our customers are like this and that, and you know, agile is great, just for a different company.

Agile Adoption Story – Common Mistakes (part 2)

To continue with the agile adoption story…  John is sitting in his office, waiting for the measurements and results and looking forward to the great results of the new process called Scrum.

We can use just a few practices

But what happen in the team meanwhile. They started to read all the books and blogs, get known some theory. And get a few practices to follow: Standup meeting, Product Backlog, Sprint Backlog, Customer Demo, Retrospective, User Stories,… but what actually happen. The retrospective didn’t seem useful enough to be made part of their process as they know each other well and even if they have some problem they feel they are solving it right away. And, more than that, they have the lessons learnt. No one is learning from those, but they still believe they are useful. So why should they do any retrospective, right?

Making a Product Backlog is a strange thing as well, as the business people don’t have any time they can ever spent on such activity, their only concern is to get all they want to as fast as possible without the necessity to described it well in front. They are quite happy to hear the team is making a commitment and deliver all they promised on time. As a result of that, team is not willing to take any responsibility and prefer the technical tasks instead of user stories.

So finally Standup is the only one practice which preserved in the team. They meet every day, talking about what they had been doing, who they had been talking, but usually missing any day commitment and description of any finished work.  As they don’t understand the reason of the followed Scrum practices, they don’t like them and felt the time is spent completely pointless. “The Scrum is just about meetings, we should better work than follow those useless practices“.

As the time goes, they abandoned most of the practices, but still they have those huge expectations of high efficiency, flexibility, improved customer satisfaction and team health. But apparently, no one of those can be seen within a team.

Finally, when John asked how the Scrum goes, he is surprised to hear that “Agile is not for us”. We are different, we have too complex product, we are too big/small to implement agile. Our customers are like this and that, and you know, agile is great, just for a different company.

Agile Adoption Story – Common Mistakes (part 1)

Companies have different reasons to move to agile, some are good enough, and some will never work. Some believe that agile is a silver bullet so they start without understanding; with high expectation all their problems will be solved by using for example Scrum. It’s not always any idealistic dreamers, they are well educated managers, with many years of ICT experience. But they are very upset hearing they must put some effort into the system in order to get exceptional output. They have to change and change is difficult, exhausting, long-term work.

I’m not saying you saw just the following mistakes around you, but those are the most common, and to some point of view the most critical from all I’m seeing in the companies around me.

Agile is new and cool, let’s start!

First type of the problem I’m facing in the companies is someone who is very enthusiastic about agile. The person, John for instance, is not any expert on agile, has no personal experiences, no close friends or colleagues using it, but he heard somewhere that agile is more efficient and flexible. And he saw those problems on the projects. The company is struggling from poor efficiency and inflexibility already for couple years. They already tried pretty much everything. They changed the project managers, make their processes strict and well described, implemented ISO, sent some project people to do PMI certification, and still got no real improvement. And yes, last year, they changed the bonus structure and made the fix salary low and high bonuses. Still no improvement; surprisingly it’s even worth it used to be few years ago.

And then, John discovered there is agile, which is supposed solve all problems they are facing. Isn’t that great? So what shall we do? Let’s read about it and start. Agile means Scrum. And Scrum, that’s just a few practices. So let’s start using them. And make sure you don’t bother me with any real change inside our company. Keep the organization structure as it is, keep all our processes, and keep the roles. Just give the business opportunity to say what they want to and then make sure you deliver it on time. And take care you are more efficient as you were, as I’m going to compare the mandays spent.

How it usually ends? John, and everybody else, is frustrated and saying “Agile is not for us”. We are different, we have too complex product, we are too big/small to implement agile. Our customers are like this and that, and you know, agile is great, just for a different company.

Being Agile

For already some time I’m struggling about the definition of agile. What is it really about? What are the key parameters and how do you recognize you are agile? I spent in agile environment more than 7 years, and had met hundreds of team. But surprisingly, that doesn’t make it any easy. Every team was different. Every team had adopted different practices, implemented different processes. Can all of them be called agile? After all, I would say yes. There are many agile ‘fanatics’ who would be saying you are not agile because for example you don’t release every sprint, have fixed price and time model or just don’t follow enough practices.

For me, agile is a culture thing, it’s about the way you are addressing things, how do you approach problems. It’s a philosophy, rather than fixed process you can just follow without understanding. You must appreciate it, and live it. Otherwise you end up blind – following some practices you’d never really understood. Agile is about team cooperation, about sharing experiences and helping each other. It’s about transparent and open communication.  Identifying problems and risks fast enough. Agile is about fast feedback loops, where you see what went well and what you can change or improve. It’s about the ability to accept change in your daily life. Don’t be complaining the world around you is changing, be a change yourself. It you succeed, you are agile, despite of what everyone else is saying.