value - Agile and Scrum Blog

Focus on Value

One of the biggest shifts in the agile world is from output to outcome or in other words from being busy to achieving something meaningful. It looks simple. If we plan it well, the two are supposed to be the same, right? So, what’s the problem?

The more we deal with complex problems, the more possible solutions are available, and the harder it is to find the right one, that will bring the business value. We have so many options and it’s hard to evaluate their impact.

Let me give you an example. Imagine you’re having a gaming company. The company creates free games for mobiles which you can just download and enjoy playing. So how do they get money as a company? They make their players buy something at the game store. In a traditional environment, somebody smart has an idea to build more items for the game store to get more money. And the teams in traditional environments are done when they implement the feature that it’s up and running in the store. No bugs, it works, and they implemented it that fast, according to their estimates. That’s how success is defined in the traditional environment. We don’t question the plan, we just deliver as fast as we can.

In the Agile world, the implementation is just a prerequisite. We don’t do it so that we have it, we do it because we want to achieve a business value. Now how do we know if we achieved a business value? Well, that’s a bit tricky right? It’s much harder to measure value than to measure velocity. To be able to get a sense that we are delivering value, we need to have a good relationship with our customers and get frequent feedback to know if we are going in the right direction. As an example of value metric, the team can start measuring things like how many people bought this new item in the game store and if it’s growing, they call it a success. Value was delivered. But that might not be the real value either as you might realize people only bought it once and never again, and then it was actually a waste of your money implementing it. So you improve the metric and start measuring things like returning customers and if it grows you call it a success.

And after focusing on value metrics for some time, you realize that more features don’t necessarily bring more value. You can implement ten new items to your game store and people might even stop playing the game as they say it’s confusing. In a complex world, more doesn’t mean better. So stop focusing on speed. Stop caring about velocity. The only important thing in nowadays constantly changing complex world is to be able to inspect and adapt quickly based on the feedback. Measure value, not effort.

Agile Mindset

We talk about changing agile mindset for years now, and it’s hard to describe. People who are far from being Agile are often saying “That’s what we are already doing, so what is this buzz about Agile about?” or “This will never work in reality, Agile is only for unicorns.” So let’s see how that agile mindset is changing.

Delivery Focus

At the beginning of the Agile journey, it’s all about output. The delivery is the key. People care about efficiency, measuring velocity, estimating effort and complexity using Story points, T-shirt sizes, drawing Burndown charts. “How can we deliver faster?” is the most common question. People want to measure everything. They still believe the work which needs to be done can be analyzed and planned, so they create mini ‘stories’ aka business requirements with all the details specified, often using acceptance criteria to add even more details and make it even closer to detail specification as they’ve been always creating. They also believe that we only need to follow the plan and deliver everything as described as soon as possible to be successful. Nice and simple world. But that’s not what Agile is about so you can freely forget most of the practices mentioned above. They might be better than some other from pure traditional world, but most of them have nothing to do with being Agile. It’s just ‘fake Agile’. On the other hand, most of the people couldn’t learn how to dance overnight, so a bit of ‘fake Agile’ might be a good step towards the mindset change. To be fair there are some aspect teams need to master at this level, mostly going back to the XP (Extreme Programming) like continuous integration, shared code, TDD, regular refactoring, and pair programming or mob programming. Without those, nothing else will work.

Strategy Focus

The more you apply the agility, and aspects like self-organization to raise empowerment, cross-functionality to be business value driven, and frequent product reviews to be customer-centric, the more your focus turn from delivery to the vision: Why are we doing it? For whom? What makes it different? What is the value? How are we going to change the world? People start to see that delivery is important, but just as a prerequisite. And it’s definitely not about delivering faster (when there is a risk we go to the wrong direction). Instead, it’s about maximizing value, which actually can be achieved by delivering less features than you were used to do before. 80% of the value is only in 20% of functionality, and it’s not distributed linearly. The million-dollar question is how can we know this item brings value. The answer is surprisingly simple: Feedback. You can start with the implementation of Scrum. Short Sprints help teams to focus value delivery through defining Sprint Goals, cross-functional teams enable fast feedback on the value delivered from customers through regular Sprint Reviews, and good Product Owner brings decent business knowledge and creates a relationship with customers so the feedback makes sense. Practices like User Stories and Story Mapping, which are by definition customer-centric and value-driven (if used how they are supposed to be) are useful concepts to start a conversation about the business value. At this stage, people believe that if they have a good vision, and understand the customer well, they are going to be successful. Sounds great, the only weak point is that often that’s not enough in nowadays constantly changing the world.

Impact Focus

Finally, the last stage of the Agile mindset change is acknowledging that we don’t know where the value is, we can’t analyze it, we can’t plan it. All we can do is to iterate and inspect and adapt. This stage is finally where we stop pretending we know where the value is, and start heavily experimenting. Note, that 80% experiments must fail by definition, so you need to run very small tiny reality checks which are expected to be opportunities for learning. Teams learn fast from day to day failures, always looking for better ways, and when every experiment goes as they expected they take is as an indicator of lack of transparency, honesty, and relevant feedback. All over radical transparency is their best friend, empowerment doesn’t stop at the at the team level but goes through the entire organization, and emergent leadership is the key engine to creativity and innovations. The organization is purpose driven and do whatever it takes to achieve it. The delivery at this mindset stage is needed but is quite unimportant. It’s like walking. You would say you need to walk to get somewhere. But if you don’t know where the ‘somewhere’ is, walking no matter how fast only makes you tired. At this stage, it’s not even about a strategy that much as the strategy is emergent and changes depending on the feedback. It’s all about if the outcome we produce created impact. If you know what do you want to achieve, you can measure if it’s happening. The sooner the better. Impact Mapping is a good tool to start. You don’t implement functionality because you know how to implement it, nor because someone believes or say it is a good thing to be done. You do it, to achieve your goal. If you have any evidence that the impact you need to achieve it is happening, you continue. If not, you stop and find another assumption to test. If you think about it, this is a very different way of prioritization, working, and thinking. That’s the real agile mindset. Once you embrace such a way of working, you are truly Agile.

From Good to Great: Cross-Functional Teams

Next blog in the “From Good to Great” series (Don’t Copy Find Your Own Way, Radical Transparency, Agile Mindset, and Collaboration) is focusing on cross-functional teams. It seems like basics, but I realized that organizations still don’t fully understand why the cross-functional teams are critical to Agile and Scrum success. I guess it is grounded in the fundamental mindset shift, where the organizational focus is moving from functionality driven to the value driven. In traditional organizations, the delivery of functionality was the key. That’s what we focused on and that’s what we measure. It’s the world of allocation and reworks caused by misalignment which all over creates so many dependencies, that delivering end to end feature is a nightmare and takes forever.

Business value

In agile organizations, the focus is changing to deliver business value. And here is the problem. Business value is hard to measure before you get feedback from the customers and users. There is no formula. All you have to do is to get feedback fast and inspect and adapt based on that. And here we are: the cross-functional team is an enabler of fast feedback as there is no way users will give you quality feedback on the backend or one system change while they have a hard time to imagine what does it mean for them. They give feedback on the end to end functionality, that actually often goes across all the technologies and systems in your organization. As such, teams need to be able to deliver value end to end. Otherwise, you are mentally at the manufacturing line where teams work in sequential mode and trying to parallelize this work creates so many dependencies that are making your life hell and preventing teams to focus on the value. They micro-focus on the part of functionality without seeing the whole and the feedback will suffer.

The typical misunderstanding is that cross-functional team means that everyone needs to be expert on everything. But that’s not needed. All we need to have is a team willing to learn and take over responsibility for the end to end value delivery. A team, which can take any item from the backlog (which is end-to-end functionality which brings the value by the definition) and finish it together. They don’t need to take it as individuals, they collaborate as a team. In most of the cases, it’s not that hard in reality once you overcome the initial resistance of team members and the overspecialization mindset of the organization. Try it, and see that I was right :).

Impact

In addition to what has been said, we don’t do functionality because we can, we don’t do it because we believe there is a value, we implement it as we expect something to happen. It is impact driven, strategic approach. And that’s a game changer. In order to be able to measure impact, we need to be able to deliver working product frequently so you can really see how different functionalities changing people behavior. And to do that, cross-functional teams are the essential enabler.

During their agile journey, companies often ask what shall we do if we can’t have cross-functional teams. And the truth is I don’t know, except make it happen. It only needs courage and focus, which are two of the Scrum values after all so nothing new. All over, Agile without cross-functional teams is only empty process, kind of a fake agile where we are using the terminology but not changing the mindset at all.