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.

Component teams

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.

Cross-functional teams

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.

From Good to Great: Don’t Copy, Find Your Own Way

Agile become part of our lives and you can see some sort of “Agile” in every other company, but still, many companies are failing to be Agile and understand the mindset. Ron Jeffries talks about “Dark Scrum” for years and I see more and more frustrated people around than ever. So why are the companies failing?

The most appealing way how to fail is to copy someone. When it worked somewhere else, why shall we take a hard time trying to invent it ourselves when we can just apply it. It usually starts with a big push from the top and has often wrong expectation from such a change. Being Agile is going to be hard, you might not see the results right away, and renaming a few roles and departments would not be enough.

Instead, you need to start from the bottom, get the experience from the teams, learn on the way through your own failures, do experiments, have the courage to do things differently. At some time, when you got used to this way of working at the team level and can imagine what needs to change in the business, systems architecture, culture, and organizational design, you might need to get ready to the next step – scaling.

Which to tell you the truth shall be called ‘descaling’ instead as in order to work, you need to turn the organization around and build it around the cross-functional teams who can actually deliver value end to end. Be business value driven, customer-centric. Hold on, yes, you need to understand what the business value actually is and think about the organizational purpose which is matching that value at the same time. Why are you here as an organization, and what would happen if you disappear from the market tomorrow? Would someone miss you? Are your employees living that purpose?

Having the evolutionary purpose is an enabler for Agile culture to finally settle down and stick. Only then, when you have a higher purpose, you can talk about truly being Agile and forming the Agile organization. How many ideal organizations I’ve seen? None. How many companies I’ve seen, being on this Agile journey? Hopefully enough to demonstrate that we can make it. Give us the light at the end of the tunnel that we can actually turn the organization around and make it a better place to be. Make work fun again. It’s not about being ideal, Agile is about inspecting and adapting, learning from experiments, learning from failures. So instead of looking for some ideal organizations to copy, how about if we start with ourselves, get the courage to do things differently. Be brave. Be Agile.