Sell Agile to Customers

People often ask me how to sell an agile way of working to their customers. To the customers who are used to the traditional way of working, customers who are used to requirements and fix scope, fix time, and fix budget, and customers who are used to big upfront analysis.

Don’t expect any magic. Selling is simple. All you need to do is to show the value. Show them what it is in for them. Because if they don’t understand what kind of value they are getting with this new way of working, all they have is fear. Fear of the unknown, fear of failure, fear of change. Always start with why. No change will happen unless you create a sense of urgency.

The value they get will differ depending on the situation and their experience, so my best selling pitch always starts with questions. What would you say about your current experience? What are the typical pains? What is going well? What is important for you? I try to be open to new perspectives and curious about their situation. Then based on what they say I try to offer a new way of working. “We do *something differently* so that *this* and *this* will not happen.” The closer you get to their language, the better. Typically, you need to address lack of transparency, misunderstanding of the customer needs, not keeping the budget, and/or quality issues. They also often ask for a reference, so be ready to give one.

The most important is that you can only sell things you truly believe in. It’s good to already have some experience not only for a reference but also for your self-confidence. It’s always visible from your body language if you don’t believe in it. Plus, it’s hard to answer their curious questions about the details of your work if you never experienced it.

How to Start Good Agile

People always ask how to start, what are the practices we need to do, what is the magic. They are looking for a cookbook, something to copy step by step. And they are often disappointed that I refrain from recommending them where to see the ideal example. Look what good or bad copying Spotify way of working brought to the industry. So if not copy what someone else did, how shall we start?

First step of every change is to create a sense of urgency. If you don’t have it, you won’t change. Ever. Because we are fine, we are good enough. We always did it this way. So to break a habit, you need to find a strong reason why keeping your habits is not a way forward. Only then you can start moving.

  • Why do we have to change?
  • What happen if we don’t?

Often, we see reasons why the change is inevitable. But ask yourself, hat about the others? Do they feel the same way? Communication is the key here. Communicate over and over again. Why are we doing it. The higher the urgency the higher the chance of success.

Second phase is start experimenting. Start small. No big changes. Note we are not looking for perfection, we look for good enough and inspect and adapt form there. One team after another. Learn from mistakes, develop the habit of continuous improvement. Implement the Kizen mindset. You can run the whole transformation in Scrum, iterating is Sprints, learning from retrospectives, getting feedback in Reviews, creating a Backlog with organizational impediments, and through that process inspect and adapt. Very agile, and very simple as well.

And how do you know it’s working? In general, when I go to organizations, I check two things:

  1. Do they work as individuals, or as a team.
  2. Are they delivering work, or end-to-end business value.

Individuals distribute work, deliver it and then try to merge it together. There is my work and your work. They don’t need each other much. It’s the world of work distribution, allocation, and individual responsibility. Team on the contrary are collaborating to achieve a goal. They don’t have roles; they do whatever it takes to achieve the common goal. Teams often leverage the pair work, swarming or mobbing. They learn, help each other. They are more creative and innovative and therefore more effective in solving complex problems.

The traditional world was full of managing dependencies. The skill-oriented departments were not value oriented but optimizing for individual performance. And don’t take me wrong, it totally made sense as the majority of their problems were just complicated, far from being unpredictable and complex. In the world where we know what needs to be done, the whole difficulty is how to plan and deliver it exactly according to the plan. The complexity and unpredictability of the nowadays business environment changed that. We realized we don’t know what needs to be done and all we can do is to inspect and adapt. Find a way how to achieve the business goals. Learn from feedback the sooner the better.

Both points are fundamentally changing the way we work. Both are necessary for agile to be successful. So, you can do a simple assessment 0-10. What is the quality of our collaboration, are we working as individuals, or self-managing, cross-functional, dedicated team? Are we output, skills, and effort oriented or are we outcome driven delivering end-to-end customer value? Just two scales to reflect. Agile is simple, right?

Stop Solving

One of the biggest issues ScrumMasters have at the beginning of their journey is to believe that they are here to solve the problems, but this is just wrong. You’re not here to solve the problems, quite the opposite. Your ultimate goal is to create a self-managing team that can solve the problem. Solving is not your job. You’re not a team assistant, you’re not a team mother, you’re a coach who can help your team to take over the responsibility and ownership, so they will make that problem go away. I think that’s the hardest part of being a ScrumMaster. I mean there is a lot. You need to learn all the agile practices, understand Scrum, learn about different frameworks, different techniques, different tools. You need to be good at explaining things, you need to be a coach, and facilitator, and you need to help them be successful.

But I think the most difficult part is to stop solving things. That’s the beginning of your leadership journey. From being an expert to becoming a catalyst leader or agile leader. And here is the problem. If you are not solving things with your own hands, you often feel you are not creating value. You feel redundant. When I started it was not much different for me. I was helping the team with everything I could without realizing I was in their way to becoming self-managing. I never gave them an opportunity to make their own choices nor learn from their mistakes. I was always there to save them. My lack of patience was actually limiting their progress to become a high-performing team.

You are not here to solve anything, ScrumMasters are here to create an environment where people can grow, and take responsibility and ownership for their own journeys. Help them, support them, and let them make their own choices even if that means they can fail. We all learn through failures. Develop the patience to observe and let go. Build the trust they can make it. Soon you will be surprised how great teams emerge from such a trustful environment.

Facilitation is Key to the Success of Agile

When I started my agile journey, I didn’t know much about facilitation. I thought it was something we didn’t need, I thought that it was enough to tell people what to do and they would do it. But the more I worked in different environments I realized that forming a well-functioning team or creating an effective workshop, which is engaging and allows people to collaborate, brainstorm different ideas without being judgmental, and create innovative ideas is not that simple. I realized that being a facilitator is a true art and started to read about facilitation and practice different tools and techniques. And there are so many of them… you need to know which tools and techniques you can use to expand the conversation and come up with new ideas. You need to know which techniques you need to use to narrow it down and get closer to creating an agreement. You also need to know some tools and techniques to bring back the energy or help people feel aligned and engaged.

But at the end of the day, I realized that being a facilitator is not about tools and techniques, those are a good starting point, don’t take me wrong, but it’s about being able to read the space, being able to feel the energy, and being able to work with emotions. Notice what is going on in the system. Realize what they need and make sure they are ready to move on. 

The hardest on my facilitation journey was not to learn the tools and create a plan for a workshop, but to be ready to throw it away and completely change my plan when the people need it. It’s like a dance. You need to know your steps, feel the music, and move in the rhythm, you can plan to make a big circle around the hall, but eventually, you need to dance at the moment. Be flexible and react to the environment.

In the traditional world we didn’t collaborate that much, we distributed the tasks and worked individually. In agile, we need to collaborate as a team to get creative and innovative ideas. To solve complex problems. We also need to collaborate with our customers. We refine the backlog together. All such collaborations need facilitation, to create a healthy, energizing, and creative environment. Collaboration looks simple but needs a bit of practice. Great facilitators will help you create better outcomes.

Are you interested in becoming a better facilitator? Join our agile facilitation workshop and practice facilitation on scenarios from an agile environment.

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.

5 Reasons Why to Attend AgilePrague Conference 2024

#1: Inspirational Speakers

Several years in a row we managed to achieve high-quality program while keeping it affordable to the participants. This year you can be looking forward to awesome speakers, for example, Mirko Kleiner the Thought Leader in Lean-Agile Procurement, Roman Pichler a leading product management expert, and Per Beining the only FaST Autorized Trainer in Europe. And I can continue.

Register soon, the conference is sold out every year.

#2: Practical Case studies

Every year we find interesting case studies from agile journey companies where they share not only their success but failures as well so you can learn from real-life scenarios.

See the program.

#3: Coaches Clinic

You can discuss any area you are interested in and get free help from experienced coaches at our Coaches Clinic. It is a unique and free service designed to help you with specific challenges you’ve encountered on your way to a more Agile way of working. The Coaches Clinic is prepared and organized by Certified Agile Coaches – Certified Team Coaches (CTC), Certified Enterprise Coaches (CEC), Certified Scrum Trainers (CST), and other experienced Agile coaches.

#4: Open Space

AgilePrague Conference is not just about listening. We want you to participate and come up with your own session. Every mid-day there is an open space where you have an opportunity to share ideas, discuss topics with each other and join a deep dive conversation with our speakers. Open space is an opportunity to create your own program and bring your own topics to the conference.

#5: Visit Prague 

Prague is an awesome city, so why not combine the sightseeing & conference? Have a beer, wander through old town & narrow streets, and enjoy one of the greatest historical cities 🙂

Looking forward to seeing you on Sep 16-17, 2024 at AgilePrague Conference!

Challenge the Status Quo

Over the years, I was hoping that if we, agile coaches and trainers do our job well, we can multiply the success we experienced. I was part of the early adopters’ wave of agility. We were open to trying new things, experimenting with different ways of working, trying one step at a time, and inspecting and adapting along the way. And it worked. I experienced the new energy, better outcomes, happier customers, and more successful products.

Later I leveraged that experience, became an agile coach, and started helping various organizations with their agile transformation. I was able to smooth their journey and help them to avoid some mistakes we made when we started. Then early majority came, it felt harder, but also good because they were able to pivot and get better. They were genuinely trying to change. It might have looked difficult at the beginning, it was definitely not a straightforward journey, but it worked as they developed the continuous change and improvement muscle. After a while, it was not that hard to help those organizations to shift. They were open to change and therefore successful.

When the late majority hit, it brought those tough environments where people apply various scaling frameworks, trying to find a recipe, looking for shortcuts. They wanted to be done with it quickly and go back to normal. They were often not willing to stop and rethink how they wanted to progress. That’s the golden era of consultancy companies, with their big bang agile transformations. The satisfaction with a change was not always great, as to achieve something they needed to go through several waves of agile transformations, trying to get out of the habits, complicated project structures, hierarchy, and irrelevant metrics. As they were often repeating the same mistakes over and over again, success was not that easy to get. But eventually, they realize that agile is not another process and reconnect to the mindset.

Now, I start seeing some of the laggards and it makes me wonder why they feel a need to pretend they want to change because their constraints are often so fixed that it simply won’t work. Implementing agile without changing the way you work will only create pain and no meaningful outcomes. And yet I do the same as I always did. Try to find enthusiastic individuals, who are ready to start challenging the status quo. For the rest, I put a seed in their minds. It will grow eventually. Maybe they can’t do much about it now, but in some time, they remember it and go for a different way of working.

Success is not about practices, it’s not about tools, it’s about the ability to challenge the status quo and change the way you work. Let’s together transform the world of work.

Reinventing Collaboration

The recent shift to the virtual space and home office created a more convenient work-life balance but created very new challenges as well. How to grow talents, how to collaborate, and how to build relationships.

In many cases, people simply went back to individual work. In many organizations, the only time where they see each other is some sort of Standup that looks more like a status meeting where individuals who have their own tasks, share their progress with anyone who is interested which is usually close to no one as the don’t collaborate and don’t have the shared ownership.

Such Standup is kind of an energy killing boring micromanaging practice. So maybe you should kill it as well and give people more time to work on their individual tasks. And when I said the only time ‘they see each other’ I was not that accurate either as in many organizations people are not using their cameras. Now what remains from being agile in such environments? Not much.

Another challenge we are facing is how to grow talents in such an individual culture where people don’t see each other and don’t build relationships with either their colleagues or their customers and stakeholders.

People often ask me about this principle of the Agile manifesto, implying that agile cannot be used in a virtual, geographically distributed world.

“The most efficient and effective method of

conveying information to and within a development

team is face-to-face conversation.”

But why not? It doesn’t say co-located, it says face-to-face or as we call it now video-to-video. So that’s not an issue. Technology is not an issue either as Zoom for example can create a team space where people can connect during the day and collaborate, discuss, share, and help each other. Similarly to the office space where they were in the same (physical) space and collaborate, they are now in the same (virtual) space and collaborate. It’s even easier as they can share screen, move to the breakout room, talk to each other if needed, and leave for lunch and come back after.

I guess the biggest issue is not where you are located but if you are willing to collaborate. Is there a need for teamwork, or is the nature of the business simple enough so they can distribute the work and work individually. If the nature of your work is complex, collaboration in the virtual world is perfectly possible. If you choose to work individually, don’t pretend you are doing Scrum as team collaboration is one of the cornerstones and the only thing that can emerge from that would be a “Dark Scrum”, and that’s neither fun nor functional.

Where Detailed Positions Can Be Harmful

Traditional organizations are based on hard skills. They hire for detailed position descriptions and look for certain experiences, and once you are hired, they evaluate your hard skills and focus on growing them. It’s all based on the presumption that we know what needs to be done. And because we know what needs to be done, we can plan the work and allocate people with needed skills. Such organizations optimize for individual performance and that is usually supported by detailed position descriptions, and it all works really well, until the business becomes unpredictable, and you wake up in VUCA (venerable, unpredictable, complex, and ambiguous) world. That’s where Agile was born and that business shift turned everything around. Positions, way of working, and also the basic assumption that we know what needs to be done. 

So on the contrary in an Agile environment, we realize that we don’t know what needs to be done. The business is changing so frequently that we can’t really plan, the changes are so frequent, the expectations so unpredictable, and there are so many possible solutions that all we can do is inspect and adapt. Experiment and learn from feedback. Late 90s the world was not like that, and nowadays organizations are still created about that old belief. In a modern world, it is very hard to plan which skills we need. Technologies are so dynamic that the only skills we really need are flexibility and fast learning. And then, the more detailed position description you have, the more you are fixing the status quo and are unable to adapt to changes and innovate your business. 

In agile organizations or if you wish in organizations that require a higher level of adaptability because they are experiencing the VUCA challenges, positions are not only not needed but often harmful. Therefore, many organizations widen their descriptions and start hiring generally for team members, and engineers, or just removing positions at all as something that stays in the way of our flexibility, collaboration, and innovations. They form individuals and teams around problems and ask help people to do their best to solve them, even when it requires learning new skills or changing their practices. 

Positions are not always bad, they create a clear path where to grow and what is expected from individuals, but such a defined position often creates boundaries and gaps and limits the learning. “It’s not my work people say. Somebody else shall do it”. But people are smart. When they change jobs, they always learn new tools, practices, and methods. But for some reason we often try to limit their learning by defined positions when they work for the same organization. So if you care about creativity, adaptivity, and agility, forget positions. People don’t need them to do their job. Give them a clear vision and goals and trust them, they do their best. You won’t regret it. 

ScrumMasters Only Make Sense in Scrum

Quite often during the last few months, I heard people being frustrated with not functioning ScrumMasters. One reason for it described in a post Why Some Organizations are Laying of “ScrumMasters” is that those are not the real ScrumMasters, but hiring Scrum “Project” Masters, Scrum “Ceremonies” Masters, or Scrum “Jira” Masters which will neither help organizations to achieve their business goals nor people to feel better or do a better job and as such it can only result in “Dark Scrum”. But surprisingly there is a whole bunch of experienced ScrumMasters who are unlucky enough to be hired to traditional organizations as ScrumMasters to “manage” individuals who only focus on delivery. There is often no intent to change the way of working, managers are trying to keep the status quo and make sure the ScrumMasters have no power to introduce any practice. “You need to ask HR if you like to work with people. Just manage the ceremonies,” they say. I guess I don’t have to say that the whole experience is very frustrating for everyone. Teams are saying the ScrumMaster is not helping them and ScrumMasters burn out very soon. I usually say no to such an environment as they are not ready for a change. Personally, I always try to look for someone who would sponsor a change. If there is no willingness no bigger vision, then why am I here in the first place at all.

However, if I take such an opportunity, you need to start looking at the ScrumMaster role differently. In the first place, ScrumMaster is a leader. And that brings a whole new perspective on his role. As a first step, it’s about the vision, or I would even say a dream. Where do you want to see your organization or team? Why is it important? I rarely do anything because my job description says so, of it was in my KPIs. I did that because I believe that the individual people, team, and organization will benefit from that action. I often fight the system and most of the time challenge the status quo. So that’s where you need to start. Have a strong enough dream that is that you go for it no matter what. Even if you win the lottery, you will be going to work and trying to change things so that your dream becomes true. Sometimes there is a wrong perception that agile is about that sunny smiling environment and no performance. So let me be clear, the first thing you need to start with is business. I often ask organizations before I start helping them with change, implementing agility, or improving their current Agile/Scrum implementation why do you need to change, and they almost always say a number of reasons why is it important – predictability, time to market, customer satisfaction, flexibility, quality, technical debt, innovations, … Then I ask them what happen if they don’t change. Surprisingly, very often they pause and say well, nothing really. We are successful, we earn some money, we are good enough. So in many cases, they don’t feel the sense of urgency needed for a real change. And unless you help them to have a sense of urgency, no real change will ever happen. Can they improve? Yes. Can they adopt some practices? Most likely. But would they change their mindset and their way of working? Not that likely. So if you take a job somewhere, here are a few points you need to take care of.

To start with, answering the following three points is essential:

  1. Why – define business goals. How the organization is going to benefit from a change? Why is it important for us to change? What happens if we don’t change?
  2. Who – define your allies. Changing an organization is never one man show, it’s too complex for that, so create a team. It’s more creative and innovative and will better address the complexity of the system. Create a transformation team that will guide the organization around its agile journey.
  3. What – define your dream together, your vision of the change. What needs to change? What would it look like?

Once you initiate the change, you need to keep going.

  1. Communicate. And when you do so, communicate again. And again. And again. Agile brings very different way of working, different mindset, and different perspectives. Hearing it once is usually not enough.
  2. Remove obstacles. Transformation teams often create a transformational backlog with impediments and things that need to improve. For example, education and understanding, legal and contracts, PR and motivation, but also things like cross-functionality, self-management, individual goals, etc.
  3. Celebrate success. Even a small step is worth celebrating. Don’t forget that. It works for both teams involved and also for the people around who might get inspired and give it a try. Don’t forget that it’s not agile that scales. Success scales.
  4. Keep changing. Agile is about continuous change. Look for small improvements, and change step by step. You never going to be done, but you will always see progress if you look back. So don’t stop changing. There is always a better way.