Identify and involve your stakeholders

Posted May 29, 2020

Some product owners, managers and organizations have a believe that for it to be okay to show someone the product being developed it has to be polished, shiny and with all the expected features in place. Every occasion where the product is presented is a risk of being criticized, and if the product is in an early stage of development, they are not yet ready for critique.

“The product needs to be impressive! The company’s reputation is at stake!”

This thinking often causes the first feedback from actual stakeholders to be received way too many sprints into the development process. In worst case at the first product release. That’s when reality hits us! Hard.

As a Scrum Master you need to challenge this limiting belief and coach the organization to think about this differently. Everyone in the organization need to understand the importance of continuous feedback and transparency, and the consequences of not having it. You need to coach the product owner to actively seek stakeholder feedback, at all times, and to work closely with them to understand their needs.

Getting feedback from stakeholders early and often is crucial for the success of a product. How else can we know that we are on the right track?

Question is; Who should we seek feedback from? Who is a stakeholder, really?

Typically, a stakeholder is anyone affected by the outcome of the product. Generally, the most important stakeholders can be categorized in three different categories.

• Users - The people that will use the product hands-on. These are the people whose behavior, life or day-to-day work will change because of the products entrance to the market.
• Customers - The people who will pay for the product. This may be the same people as the users, but not necessarily. If you for example will sell your product to businesses the users may be employees in one department, but the customer may be someone at finance or a manager with a budget responsibility.
• Funders - The people responsible for funding the development effort.

All these types of stakeholders will bring different and important perspectives of the product to attention. They often have quite different needs that are all important for the success and existence of the product.

It’s the responsibility of the product owner to try to balance the different needs, and to effectively do so the stakeholders need to be correctly identified and extensively involved in the development as needed. The stakeholders and their needed involvement may change over time, and the product owner need to understand this as well. As the product evolve new stakeholders may appear.

If you are working in a complex setup or a big organization where the stakeholders are not that obvious to identify, start by asking yourself these three questions.

• Where does the money come from?
• Whose life will change with this product?
• Is there anyone who would be upset if he or she did not know what was going on with this product?

The answers to these questions might give you a clue on where to start looking.

Keep the stakeholders involved. Make sure they attend your sprint reviews. Listen closely to their feedback. Collaborate on your next step forward towards a better product!

Please reach out to me if you have any feedback or comments!

Is the team productive?

Posted May 11, 2020

“The team should be able to deliver more than this by now… Why aren’t they more productive? Let’s add more backlog items to the sprint backlog to make sure everyone is working with something and is kept busy!”

Do you recognize this reasoning? Maybe you have said something similar yourself? Maybe you have been working as a developer in a team where the product owner, or even the Scrum Master, had a similar approach? How did that make you feel?

In this post I will share some thoughts about how this, surprisingly common, approach to improve team productivity may result in the exact opposite.

Great products are built with an outcome-oriented mindset

There are different reasons to develop a product to begin with. E.g. to make a business more efficient, to enable new ways of socializing, to entertain. The list goes on… What’s common for all reasons is this: To solve a defined need for the users of the product.

For a product to be successful in a competitive market it has to solve the problem(s) that the users are facing - And it has to do it the best way possible! The problem has to be solved in a way that meets, or exceeds, all expectations.

Consider if you were a producer of vacuum cleaners. Is it a success if you sell 100 000 vacuum cleaners? That data alone can’t really tell you that. But if you got the information that most customers complain about the vacuum cleaner being so inefficient that it takes them twice the time to clean their floors compared with their old one; Which producer do you think will remain attractive and get a good reputation? Which producer do you think can charge the most for their vacuum cleaner while still keeping the sales figures up? Is this a success? 100 000 or 1000 vacuum cleaners sold doesn’t make a difference if you can’t effectively solve the customer needs and stay competitive over time. This highlights the difference between an output- and an outcome-oriented mindset!

Output is about what is produced and the organizational tasks around it. Outcomes describes the effects and behavioral changes that the product brings to its users and the world around them. Meaning - The incentive to buy and use the product to begin with. What is most important; To produce a vacuum cleaner, or to produce a vacuum cleaner that people want to buy and use?

To repeatedly force more items into the sprint backlog to keep everyone busy is a possible sign of an output-oriented mindset that is centered around completing as many backlog items in the shortest time possible. It has become more important to deliver a lot of things fast, rather than the right things. This will be reflected in the results of the product, how your users perceive it, and finally the profitability.

When working in an agile way the goal is not to deliver more stuff. It’s about delivering the right stuff! And only the stuff that is valuable to the stakeholders. Delivery of things that doesn’t meet the stakeholder’s needs is commonly referred to as waste, because it’s wasted time, wasted energy and wasted money.

Defining a good goal for the sprint will help you stay in an outcome-oriented mindset centered around what the sprint aims to achieve for the stakeholders of the product. Meeting those needs as efficient and early as possible is a sign of a productive team. Completing many backlog items are not.

How does this affect the team?

When the team work to solve a user need the team gets engaged in how the product will be used. They do everything they can to understand how the product will fit in the life of the users. The team will feel ownership and responsibility to maximize the value of what they deliver and to delight the product’s users. This will be the main goal and focus, sprint after sprint! This will be very rewarding for everyone involved!

If the product development is driven with an output-oriented mindset the focus of the development team changes drastically. If more backlog items than what the team forecasts is manageable are forced into the sprint, while at the same time questioning the team’s productivity, the new goal for the team will be to finish everything in sprint. That is an output-oriented goal.

This will cause the team to feel stressed, sprint after sprint, to make sure everything gets done. The work they perform will be seen more as a pile of items that needs to be moved from one column to the next on the sprint board. They will not have the time to get engaged in the product and how well it meets the user’s needs, only in what is produced and how fast they can do it.

After a while the team will start to take shortcuts to meet the goal of being perceived as more efficient by the organization. It may look like it works for a while, but eventually the quality will start to drop, and technical debt starts building up, step by step.

If the pressure keeps increasing the team will eventually not be able to meet their only defined goal (to finish everything in sprint). When the team has “failed” for a couple of sprints will the team start to ignore goals. Achieving goals are no longer seen as realistic or important. The team will no longer feel ownership of goals since they are not created in collaboration. This is a state of true productivity loss and disengagement!

Forcing more backlog items than the team feel they can manage in a sprint is a vicious spiral. For great products to be developed we need an engaged, outcome-oriented, team! When backlog items are forced into sprint and / or the team’s productivity is questioned - Consider this:

• What is worrying the person that is questioning the team’s productivity? Has something been noticed that has caused this worry that needs to be addressed?
• What are the incentives of the person that is questioning? Is the person under pressure by stakeholders or the organization? What help do they need?
• Is there a lack of collaboration that causes a gap between the imagined effort and the actual effort required to do the work properly? Is there a way to better the collaboration for an increased understanding?
• Does everyone understand empiricism and how to apply it?

But how to know if the team is productive?

A productive team does what it takes to successfully solve the defined need for the users of the product. The value the team produces each sprint is therefore the right indicator of a productive team.

Velocity may be interesting to look at from a planning perspective, but it doesn’t say anything about how productive a team is. Neither does team utilization and sprint completion (ratio of sprints where all items where completed and not). These metrics are all output-oriented.

Outcome is typically harder to measure than output and therefore many organizations are not doing it as often as they should to really benefit from it. The trends in these metrics in combination can be interesting to take a closer look at to find out if the team is productive:

• Thumbs up from stakeholders - The identified stakeholders are pleased with what the team delivers at the end of the sprint.
• Customer / User satisfaction ratings - User satisfaction is increasing or remaining high.
• Feature usage index - The new features that the team is producing gets a high usage rate. The features do meet a real user need.
• User reported defects - There is a decrease in user reported defects. This is a sign of increasing product quality and good test practices.
• Employee satisfaction - The employees that are part of the product development are happy. A happy employee is often an engaged employee!
• Lead time and release cycle - The time it takes from idea until a user can start benefit from a feature. If this time is decreasing or remains short that is a sign of a mature development- and release process and a low level of technical debt.

Hope you enjoyed this post on team productivity! Please reach out to me if you have any feedback or comments!

Do we need estimates?

Posted Apr 17, 2020

If planning won’t bring predictability, or an accurate answer to the question “When will it be Done?” in a software project… I guess there’s no need to create estimates either, right?

Well, not quite. Estimates can be useful for other things than predicting when a set of work will be done. Here are two good reasons why you should consider creating estimates in a software project!

Enable delivery of business value early

With an agile, incremental, delivery model the goal is to realize as much value as early as possible. This can be compared to a traditional project where all business value is realized by the end of the project when the product is finally delivered. Instead we want something similar to the chart below.

Maximizing the value of the product is one of the core responsibilities of the product owner. For each and every sprint the team delivers a new product increment, the product owner needs to make sure that the new increment returns as much value as possible to the users, the business and other stakeholders.

A product backlog often contains a lot of ideas of what needs to be done and what could be done for a product. All of these items will differ in their complexity and effort of development. Complexity is impossible to estimate perfectly, but by adding estimates to the different backlog items the product owner can get a hint of the effort of the work required compared to other items in the product backlog.

With estimates added to the items in the backlog the product owner can work on creating a clear relationship between the expected business value a feature could bring and the effort it would require developing it. That information could help the product owner to resonate about priorities and to make better choices for the product. It’s also possible to uncover if high business value can be delivered with a small effort, and that would probably be a very interesting thing to prioritize!

Spawn important discussions about work complexity

One of the goals of the sprint planning event is to answer the question “What can be delivered in the Increment resulting from the upcoming Sprint?”. Before this can be determined it’s important that all team members have the same understanding of the work required to consider a backlog item as Done. To help the development team get to a shared understanding it’s important that the team has enough details about the Why and the What to achieve. They also need to keep the Definition of Done top-of-mind to consider all aspects of the work required to finally be able to deliver a potentially releasable product by the end of the sprint.

If I ask you to predict how long it would take to travel between Göteborg and Stockholm using a bicycle - What would you do? You would probably start to break down the challenge into smaller pieces using your imagination. Maybe you start asking yourself questions like:

• It’s almost 50 miles between Göteborg and Stockholm. How long does it take me to ride one mile in a pace I can manage for 50 miles?
• What kind of bike can I use? Is it in good shape? What happens if my bike breaks down or I get a flat tire?
• Are the roads for bicycles good enough all the way to Stockholm? I remember it was quite bumpy and hard getting through Mariestad by bicycle last time I was there…
• Do I need to travel over steep hills?
• How much rest do I need? Do I need two, three or four nights of sleep before I’m finally there?

The act of creating estimates tends to spawn insightful discussions both about what it would take, but also about what “getting there” means. When asking the team to estimate items in the backlog differences in understandings of the work often becomes more apparent. Past experiences often get shared in a way that is very productive for the team’s understanding of the work.

Different techniques can be used for estimating, but often the discussions are often more important than the estimate itself. After these discussions the development team often have gut-feeling about what can be delivered in the upcoming sprint. If the team finds it valuable the estimates can of course be used to support the team in deciding this as well.

Conclusion

If you have a good process around inspection, adaption and transparency you know that planning won’t bring predictability to your product development. You understand that the plans need to be changed based on new insights and customer needs.

I hope that after reading this post you can still see the value of estimates, and the act of creating them as a part of your planning. Use estimates as a tool for the product owner to make better priorities and for the development team to get a better understanding of the work ahead.

Please reach out to me if you have any feedback or comments!

Good luck!

Predictability is comforting but not a reality

Posted Mar 17, 2020

Back in the days when everyone was doing big waterfall projects, both in software and other fields, we used to have an “Analyze”-phase. Today we do barley dare to call a project waterfall (because no one want to be associated with something so out-of-fashion as waterfall-projects).

Still we see the same behavior as we saw when doing the waterfall-analyze-phase. Today it sometimes gets covered as “pre study” or “breaking down the entire scope in great detail into the backlog so that we uncover all risks, can accurately estimate, set a release date and calculate the cost”. Sounds easy but in reality, many traditional project plans failed because of the believe that this could be done with accuracy if you just did it well enough.

It’s easy to understand why we continue to drive development like this in our businesses. As humans we do not like uncertainty. Certainty and predictability are much more comfortable. It doesn’t matter if the plan we create is made up of guesses and unreliable assumptions - As long as we feel that we are in control.

When software is built, we are always solving new problems. The domain is new, and the requirements differ. Ways of solving technical problems evolves with new frameworks, languages and other techniques to increase efficiency and enabling new more powerful features to be developed. That, in its nature, is making software development hard to predict to the detail required to create a predictable plan.

So, if planning can’t give us predictability; Why should we bother? Planning is crucial - But plans are not! The fact is that if your plan is not changing, you are probably not getting enough important feedback. A plan serves the purpose of giving alignment and understanding of the goals based on what is known today. A plan could include a forecast of what to release and when. But following the plan is not a goal or a measure of success. The measure of success is delivering value and meeting the users and stakeholders needs as well and soon as possible!

If we try to control uncertainties, we are not open-minded and welcoming of the changing needs of our users and stakeholders. We do not focus on what brings value to our users now. We do not focus on validating our assumptions. Instead we focus on deliver the things that we agreed on based on the knowledge we had then (which may be completely different from the need today. Or even worse; made up by false assumptions about the user needs). That will make us spend time and money on features that will never be used (aka. Waste). That will also make us miss new market opportunities! Market needs are changing quickly and frequently, and it is not predictable. If our world is changing quickly, why shouldn’t our plans?

If you have made the decision to leave waterfall behind and go with an agile approach - Dare to skip your analyze-phase! It wasn’t a good idea then, and it’s not a good idea now. Put your focus on validating your hypotheses as quickly and reliable as possible. Release frequently! Act on the insight that it brings! Don’t spend valuable time and money on something no one asks for. Done correctly that will be the best approach for both your business, customers and users.

Do you try to control and avoid uncertainty instead of embracing the discoveries and adapting to new possibilities? Do you focus on scope and feature delivery instead of learning about what brings most value for you users and other stakeholders? Hope you found this post interesting (and not too provocative).

Why the feedback-loop is crucial for product success

Posted Sep 29, 2019

All development and changes to a product comes associated with risk. The risk of building the wrong thing, the risk of building features that does not speak to the users, the risk of introducing bugs. The list goes on and on!

Even worse is that the risk increases over time. The longer the work, the bigger the risks becomes - Unless you have good and effective routines for continuous feedback. Without feedback-loops you will continuously build your product on assumptions that leads to new assumptions. This leads to an ever-increasing risk of failure.

By working strategically with feedback-loops you can decrease the risk of failure dramatically while at the same time increase product quality and user-satisfaction. This is why feedback-loops has become such a crucial part of product development in today’s popular agile methodologies and principles such as Scrum, Kanban and Lean.

If you have an iterative process around receiving and reviewing valuable, insightful feedback you will directly decrease the risk by validating or invalidating your assumptions.

First, we need to understand which feedback-loops that comes to play during our work. A simple example could be the feedback you get when writing code in an editor. As soon as you stop typing, the editor will let you know if you misspelled a variable or function name. Another feedback-loop could also start from the point you have built a new version of your product until the time when users are able to try the new features out and give you opinions on how well its suites their needs.

Depending on what type of feedback you are searching for you can expect differences in its quality. Some feedback may be definite, other might be harder to analyze and understand. If we have good quality, we can expect a greater risk reduction than if the feedback is more uncertain. E.g. Have you successfully identified a representative segment of users to provide feedback? Are the tools you are using reliable and accurate? This is why you see an increased risk over time even though you get feedback in the illustrated chart. If the quality of the feedback is very good you don’t necessarily need to see that increase over time.

When you have a clear understanding of which feedback-loops that comes into play you can start to roughly list how long each feedback-loop cycle is. For example; misspelled variable names in code will give you feedback in a second. End-user feedback will have a longer feedback-loop cycle. Hopefully no less than every sprint. With feedback-loops and their cycle time clearly listed and visualized you will bring awareness of the loops and possibly their weaknesses.

Imagine what it would be like if you did not get immediate corrections of misspelled variable and function names! Most probably you would continue until compilation and by then it could possibly be a little bit harder and more cumbersome to understand and correct the issue which consumes valuable time. You will be surprised how often this holds true for other types of less trivial productive feedback-loops!

The longer the feedback-loop the bigger the risk. A good practice is to always strive to shorten the feedback-loop cycle to become as short as possible or as short as convenient for minimizing the risks associated with the change.

To spot weaknesses in an area of your product development it could be an eye-opener to also categorize your identified feedback-loops. Some of them might relate closer to engineering practices that will help you increase the quality of the product while other relates more to processes, progress, team building and well-being, insights in market demand etc.

Here are a few examples of some of the feedback loops that comes into play when developing a software product, and you can probably see room for improvement when looking at this chart.

What feedback-loops could you improve and shorten in your work? Would shorten those loops lead to a better product delivered by your organization? Hope you found this interesting and inspiring!