Keep it simple

"Keep it simple stupid" has been a known term since the sixties and has been adopted to software development some decades later. Although KISS has been adopted for many years, it is still not understood by many. For starters there's the sentence alone that has been misinterpreted. There shouldn't be a comma after simple. The addition of the comma implies that the one who is is making it simple is stupid, without the comma it implies that there shouldn't be sophisticated tools needed to solve a simple problem.

So KISS' meaning is that the solution to a problem should be simple and that the expertise and tools needed to solve the problem should be simple as well. Simplification makes the world easier to understand. A problem needs to be broken down in simple parts that everybody can understand, then a solution must be made to fix the problem as simple as possible. When tools are needed in the solution, those need to be simple as well. Of course simple means within your area of expertise, you ought to be knowing what you do.
Overly complex solutions indicate that the problem was not thoroughly investigated or not completely understood.

Within software development I have seen a lot of non-KISS-compliant problems and solutions. Too many classes depending on each other, versioning of API's gone wrong, overly complex build pipelines and very interesting workflows to say the least.

We humans have a knack to make things overly complicated. Because some things can be done complicated, it is not a must to make them complicated. Only use what is needed and keep it as simple and clean as possible. If you don't do it for the ones after you, just do it so it makes sense if you look into your solution a year from now.

There can be only one

The Product Owner (PO) is the sole owner of a product. The PO is responsible for maintaining and developing the product and do this the best way possible. The whole team helps the product owner in the hard day to day decision making, because the whole team cares about the product and its customers. The PO can be seen as the face of the product in an organisation.

Many companies implement the role of PO in a very different manner. Let's have a look at a few:

1. The senior product owner: A senior product owner could be someone with a lot of experience and is therefore a senior. But in this implementation that is not the case. The role of SPO is a hierarchical position above the PO, which means the PO is not solely responsible for the product anymore. As an effect, the PO will not feel responsible and will loose focus, decreasing team performance.
2. The product owner team: make multiple people PO and thus responsible for prioritisation of the backlog. There will never be consensus and the POs will be played against each other. This leads to reducing focus and therefore low performance.
3. The product owner support team: Take one PO, and put people with the PO in a separate team to do the refinement, estimation, slicing and prioritisation. The PO is suddenly in two teams and the team gathering information about the stories is not the team implementing the change, which will reduce effectiveness.
4. The product owner by proxy: in this scenario a PO is not dedicated to the team thus appointing someone else as a replacement. The latter will never have the responsibility of a real PO and can never make hard decisions. In this case the PO by proxy sometimes just doesn't know what to do and will therefor delay development and speed.

In my opinion these are all constructs to redirect ownership and avoid responsibility for the true role of the Product Owner and will always result in a lower performance. The PO is the funnel with the business. Everyone demanding something from a PO is called a stakeholder. Even in a hierarchical organisation where a PO has a manager, the manager is a stakeholder to the PO when it comes to requests for the product. See here a potential conflict. 

So when a PO is the absolute ruler of the product, how can we make sure the PO doesn't do anything stupid? Well, we trust in our PO. As mentioned the PO is backed by the team, the PO is interested in the wishes, demands and quirks of the stakeholders and needs to make tough decisions sometimes in prioritising. And the PO, just like anyone else, makes mistakes. But mistakes cannot be prevented, just like a taxi driver will have a dent so now and then. We cannot prevent mistakes, but we can help the PO in making the damage as small as possible by creating a save environment where the PO has trust from everyone, autonomy to make the right decisions and authority on the product developed.

The power of Scrum is in it's simplicity. Make everything small and simple. The responsibility of the PO is also small and simple; there can be only one. 

If you have any PO constructs, please share in the comments.

Learn to say "No" and become predictable

People in general don't like surprises. When they are being surprised there is a very basic human emotion: "fight or flight" and a shot of adrenaline. When it turns out the surprise is for the better we can enjoy the adrenaline. But when it is a bad surprise we get angry or sad. So if you want to surprise somebody, make sure it's a good surprise.  

As a Scrum team we have the ability to surprise once in a while at the Sprint Review. But stakeholders don't like surprises anymore then anyone else. So we should try to be predictable as a team and minimize surprise.

A Scrum team typically calculates the amount of work they can do in a Sprint. They use Story Points, T-shirt sizes or even apples to make predictions and to achieve the Sprint Goal. At the Sprint Review all the work that has been done is officially revealed. And if the team did well they deliver what was predicted. A lot of times teams are measured by the work they have done in an absolute measurement, like counting total amount of Story Points delivered.

And as Peter Drucker stated, when we measure something we improve on it. So if we measure Story Point, they will increase. This makes me wonder: "Does the amount of work done increases as well?"

The answer is most probably: "perhaps". So how can we improve this measurement? Well it seems that our stakeholders are interested in the work done and they don't like surprises. So let's improve on the measurement, let's measure predictability. When we have calculated the total amount of Story Points done we should divide the predicted amount of Story Points by it and multiply with 100. This number tells us if we surprised our stakeholders and is a measurement about how good we are able to plan in percentages.

Predictability = Estimated SP / Delivered SP * 100

When we now how predictable we are we can try to improve. Improvement on predictability can be done in a couple of ways and we will focus on one for now.

You can improve on predictability by making better promises. Better promises are made by getting more focus. Focus is gained by saying "No" to everything that is not part of the current focus. A ballpark estimate is that a good Product Owner will say no to up to 80% of the change requests. The PO always has two options when a new request is made: yes (20%) or no (80%). Of the 80% no's at least half will not even show up on the backlog and end in the bin.

We need to make choices to increase our performance. This means that we need to have the courage to say "No" in order to be able to focus, perform and deliver on the things we say "Yes" to. In Scrum there is only one person responsible for changes that are made to the product and that is the Product Owner and the Product Owner alone. There is no committee overseeing PO's, there can be no manager pushing changes to the Product Owner (he can make request of course just as any other stakeholder). A Product Owner is solely responsible for the product. As a team we should help the Product Owner in making these hard decisions and stand the Product Owner.

In summary we need to say "No" more often to increase focus on the goals we want to achieve. Resulting in more predictability and happier stakeholders.

Planning in Scrum: story points and planning poker (2/2)

This is the second article about Planning in Scrum

Scrum

What does Scrum teaches us about planning? To be precise, nothing. The only thing Scrum demands is that you plan. There is a timebox in Scrum that dictates that you plan, the timebox is about 5% of the sprints hours. So for a sprint of a month, you should take a day to plan, for a sprint of a week you should take two hours. 

In this timebox, there are three activities. At first the value of the sprint is determined. What value will be added this sprint, what will be our sprint goal? Then the work that needs to be done to achieve that  goal is gathered. The last activity is to determine how the work is done. 

To be honest, I rarely experience teams that do all three. But one of the most important things here is that in Scrum it is mandatory that you plan.

Story Points

So what about those Story Points (SP) then? Hate to tell you, Story Points are not a part of the Scrum framework. But, what are they? Story Points are numbers we give to work items to indicate complexity. Complexity is more then just time, it is also about how difficult it is to achieve the outcome. A small simple task may be one SP and a large complex one 100 SP. What about a small complex one? And a large simple one? Those are somewhere in between.

Story Points can be compared to travel distance. If you travel from Paris to Berlin by car you need to drive about 1058 km. This distance won't change, it will always be around 1000 km. We can say the distance between Paris and Berlin is 1000 SP. And how long will we need to drive by car to get from Paris to Berlin? It depends. If we don't take a break and drive a steady 100 kph we will reach our destination in about 10 hours. We will not account for traffics jams, fog, detours etc. In this case 1000 SP will take us 10 hours to complete. But if we put in the variance of the troubles on route it is safe to say that we will reach our destination in 11 hours plus or minus an hour. In this case 1000 SP is comparable to 10-12 hours. 

Therefor we can use SP in planning to talk about effort of work, but we won't be sure when the work completes.

Empirical

Planning in Scrum with Story Points is an empirical process. We need to learn that we, as a team, understand the size of SPs. Before we start planning we can build a reference board with work items we consider one SP and work items that are of another order. We can use this board for all future planning. The more we plan, the better we get at planning, the better we will understand what it means to have a work item of one SP and a work item of 30 SP. 

The better we get in planning, the better we get in becoming predictable. Stakeholders love it when we are predictable and they hate it to be surprised (but when you surprise them, better make sure it's a good surprise). Predictability can be measured in estimated SP / achieved SP * 100%. The closer to the 100% the more predictable a team is, the better they understand the work that needs to be done, and the better their performance.

Planning Poker

We can also use the reference board to derive a game of: Planning Poker. With Planning Poker we keep the reference stories in our head (or we take a glimpse on the board) and we guestimate how many SP a story is. Planning Poker is not a part of the Scrum framework, it is just used a lot to facilitate planning. The cards are most of the time based on a numbered sequence based on the Fibonacci sequence. This sequence starts with a zero and a one and the next number is the sum of the last two: 0 1 1 2 3 5 8 etc. Some card sets use the exact numbers, some a simplified set.

In most Planning Poker sets there is a 0, a coffee and a question mark. Get rid of those. There is no work that is worth 0 SP; it would mean the work is already done and shouldn't even be considered to be taken up in a Sprint. The coffee is for indication of a break; still communication in a group can be done with our mouths and it works much better. The same goes for the questions mark; if you have a question, just ask.

With Planning Poker cards are played in two rounds and team members guess how many SP a work item is. Science has proven that the bigger the group, the better the estimate. Therefor everybody needs to estimate, even if they think they don't know how to solve the story. Anyone who abstains won't learn to improve in planning or ask the right questions.

Planning Poker is not about poker, it is about planning and understanding what needs to be done to achieve the Sprint goal. It cannot be played wrong, as long as there is feedback making sure we can learn from each other.

Conclusion

Planning is an empirical process and hard to master. Planning is easier with references. Planning in Scrum is mandatory, figure out the best way how to do it with your team. And if you decide to work with Story Points and planning poker, take the time to understand what you are doing.

Planning in Scrum: planning and variance (1/2)

This article is one of two about Planning in Scrum

We humans really suck at planning. We can plan simple things pretty accurate: cleaning the house, food preparation, repetitive labor. Planning improves if we do the same or similar tasks often. We learn it by doing. But for the rest? Planning of anything that isn't simple is hard.

One of the things that surprises me is that we don't get taught planning in school. In high school teachers assume the students can plan, but it has never been taught in primary school. And it doesn't improve after high school either. There is a general assumption that everybody can plan, although we all know we can't.

Planning

Planning is about three things, the first one is time, the second one is breakdown and the third one is order. When we talk about time we want to know how much time we need to complete the work. We can guestimate that vacuuming the living room will take approximately half an hour. But we also know that there can be a slight variance in time. Which means that all time estimations should carry a variance with them. We should say: "vacuuming the living room will take me half an hour plus or minus five minutes or between 25 and 35 minutes". 

For bigger tasks we need to break them down in smaller task we can comprehend and plan. So if there is the task of vacuuming the entire house, we should break it up in vacuuming per room. Smaller tasks are easier to understand and guestimate. 

Last but not least we need to take into account that there is an order in doing things. Vacuuming the attic, then the basement and then the living room doesn't sounds like a practical order. We must reorder to optimize our work plan. All in all planning is more then just a time estimate and even that is worthless without knowing the variance.

Variance

Variance is the deviation from the norm. So if we plan an hour and it can be either five minutes shorter or longer, the variance is five minutes. All estimation should have a variance to predict minimum and maximum time needed. The time we need is only known in hindsight, but should be somewhere between min and max. The larger the estimation, the larger the variance. The ratio between estimation and variance is not linear. It is more exponential. This means that the bigger the job, the bigger the variance can be. And the variance will grow more compared to the increase in time. Which enforces the need to breakdown work.

Conclusion

Planning is hard to master, it takes three ingredients: time, breakdown and order. And when talking about time, always mention the variance.

Next week we talk about story points and planning poker