Tag: Scrum

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.

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.

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. 

Top 10 Agile conferences to attend in 2024

Every year I speak at many conferences and based on my experience I recommend some places to go for inspiration. Here is my list of the Top 10 Agile conferences to attend in 2024. It’s not my intention to cover them all, I’m sharing places where I like to return. Inspiring places with interaction, high energy, and great speakers.

  1. Regional Scrum Gathering Tokyo is organized by an enthusiastic agile community in Japan. The purpose is to provide a “Ba” (place) where practitioners share ideas among Scrum practitioners having a great diversity. Regional Gatherings provides a unique experience and even if you don’t speak Japanese, there are some talks in English and others translated. Join me and the local community on January 5-7, 2024.
  2. AgilePrague Conference is one of the best conferences in Europe. In two days, it creates a unique collaborative space. You can expect two parallel tracks with short talks, afternoon workshops, and inspirational keynotes. Plus, Prague is a great city to visit so you can come early and enjoy the weekend in Prague. Join Agile Prague on Sep 16-17, 2024, Prague, Czech Republic. 
  3. Agile Testing Days are almost a festival, not a traditional conference. The full week of tutorials, talks, workshops, and networking events is just awesome. Join Testing Days even if you are not a tester. It’s in Potsdam, Germany on Nov 18-21, 2024.
  4. ACE! Conference in Krakow, Poland is combining two tracks: Agile Software Development and Product Design & Management. It always has a great atmosphere. Join ACE! on Jun 13-14, 2024. 
  5. XP Days Benelux is a conference with parallel workshops for experienced audience. This year it’s going to be in Mechelen, Belgium on Nov 28-29, 2024. 
  6. Global Scrum Gathering New Orleans is the only global gathering this year. So make sure you don’t miss it. Join the global gathering in New Orleans on May 19-22, 2024. It’s always fun. 
  7. Agile Tour Vilnius is a day full of great talks in Vilnius, Lithuania. The conference is organized by the local agile community and I always enjoy the energy and conversation with participants. Join Agile Tour Vilnius on October 22, 2024.
  8. LeSS Conference is from practitioners for practitioners. Since 2016, LeSS Conferences is where LeSS practitioners share their LeSS experience and learn from new experiments. Join this year’s conference in Madrid on Sep 26-27, 2024.
  9. Regional Scrum Gathering Ghent in Belgium is a good candidate to replace the global Scrum Gathering in Europe this year and meet all the Scrum practitioners from this region. Join the gathering on June 6-7, 2024.
  10. Agile on the Beach is a great event to attend and explore the summer in Cornwall, UK on July 4 – 5, 2024. 

The selection is based on my personal preference and experiences from those events.

Other conferences to consider this year

There are many great events that didn’t make it to this list, so please share your suggestions with us and we add them to the following list.

The Power of Metaphors

One of the tools I have started using more over the years is a metaphor. Many years ago I was taught the Speed Boat retrospective and tried it with teams. It brought great energy and fun, it helped us to uncover different perspectives. But it never occurred to me that I should take the idea to the next level and use it in other situations. So let’s have a look at different situations where metaphor can be useful.

Organizations are often used to look at outputs, measure effort, and compare velocity. One of the shifts that need to happen is from functionality to business value or in other words from output to outcome. And it’s not an easy shift, especially when the organization is still project-oriented, running on the “fixed scope” mindset. One of the reasons I’m using the metaphor with Product Owners is to shake with their business as usual – we deliver requirements – and reset their thinking about the product. I’m leveraging the Three levels of Reality concept I learned from ORSC and guiding them through the Sentient Essence level by exploring a metaphor, through the Dreaming level where the most collaboration at Backlog refinement is happening, to the Consensus Reality level they are used to by setting goals and objectives. The Sentient Essence level is about feelings it’s the spirit of things. It’s where the purpose is born. And the purpose is often forgotten in traditional organizations.

Three Levels of Reality

Using a metaphor is also a great icebreaker and team building. You see how different people collaborate, how they react to different perspectives, and look for commonalities. It can help teams to create an identity and become a better team together.

It’s also a great tool for ScrumMasters to reflect on where they like to have the team or the entire organization in six months, a year, or three years.

I’m often starting by letting individuals draw some animal, real or imaginary. Depending on the situation I might help them explore that metaphor more to uncover different aspects of it. Drawing is just one way how to visualize the metaphor. You can ask people to describe it, to create a gesture, song, or dance. There are no limits.

For example “We are like a flock of birds, they can fly fast, but not for long. Some got tired quickly and started falling down but the others continued without noticing. They are strong, they have great eyes, but once they start the journey they don’t like to change the direction.”

Then we compare the individual drawings, looking for similarities and uncovering the differences. And start integrating different perspectives into a coherent picture. It’s different than talking about numbers, goals, and objectives. It brings energy and creativity and I would encourage you to try it. Let me know how it worked for you.

Hiring ScrumMaster?

One of my biggest passions in the agile space is developing great ScrumMasters and helping them to become successful in their role. I become ScrumMaster in 2005 and I didn’t know much about either Agile or Scrum. I did all the mistakes you can ever imagine. I didn’t know anything about coaching or facilitation. Instead of acting as a leader, I was more like a team mom. Later, when I realized the whole potential of the role, and become the real ScrumMaster I decided I need to give back to the community and I dedicated quite a lot of effort trying to explain to individuals and organizations what is ScrumMaster really about and why is having great ScrumMaster related to the success of the agile journey. But no matter how long is this all Agile and Scrum around, despite the effort, there are still companies who are hiring ScrumMasters who cannot be successful. So let’s have a look at the most common misunderstandings.hiring a ScrumMaster for failure

Scrum “Project” Master

Deadlines are important. So let’s tweak the role a bit and hire a combined role of “Project Manager/ScrumMaster”, “Agile Project Manager” or “Agile Delivery Manager”. They are experienced in planning and making sure we keep up to speed and follow the plan. They usually manage the Sprint Backlog and often micromanage individuals.

Scrum “Manager” Master

We have to be efficient. We need to deliver more functionality faster. Speed is the key to the success. So let’s have the “Scrum Manager” to help people organize. Someone needs to allocate tasks and measure that they are working and not pretending or hiding behind the Scrum process. Someone also needs to check the progress at Daily Scrum. Someone has to make sure there are results. Such environments often take velocity as a key metric and ask Scrum “Manager” Master to create Burndown charts and other reports.

Scrum “Technical” Master

Many organizations are missing traditional Team Leaders. A senior technical person who will guide the rest of the team members, distribute their tasks, helping the Product Owner with the estimates. Decide on the Sprint commitment. So here we are Let’s hire an expert – Scrum “Technical” Master.

Scrum “Ceremonies” Master

This is my ‘favorite’. We have a Scrum Master to make sure the ceremonies are happening. It’s not a valued position as it downgrades into a team assistant who needs to schedule and manage meetings. Therefore it’s not much popular and most organizations would combine it with a developer/tester/business analyst role. In some cases, it turns to “Scrum Police” as the only explanation they are able to come up with is that ‘Scrum defines it this way, follow the rules’.

Scrum “Jira” Master

This is very typical nowadays. ScrumMaster needs to know Jira, update it on regular basis, and generate reports. Such ScrumMasters are often micromanaging individuals, adding complexity through difficult workflow and complicated processes. They are focusing on various different estimates, at the story level using story points which they often link to man days and hours at the task level which are being re-estimated every day to be accurate.

Scrum “Owner” Master

It’s a waste of our time to have two people when in the traditional world we only had one project manager. ScrumMaster can act as a Product Owner at the same time. In their mind, ScrumMaster is some sort of process assistant for 10-15% anyway so why not. Such a person usually doesn’t have enough business knowledge and ends up being a requirements seeker, not looking for value, and not deciding on priorities. They take a backlog as a to-do list where everything needs to be done.

Scrum “Flock” Master

Finally, some organizations have one ScrumMaster for many teams. No matter how experienced are they, they usually burn down. They don’t have enough time to focus on all teams, so they end up being everywhere and nowhere, and therefore their impact is very limited.

Maybe you find yourself in multiple dysfunctions at the same time. That often happens. But no matter how different they are, they all share one common outcome. They don’t work and you end up with “fake Scrum” or even “Dark Scrum” and no ScrumMaster.

So what’s the real ScrumMaster role about? For the beginning, you can start with the assessment below. Take it as just a start. There is more to be a great ScrumMaster, but if you have the following top 10 points right, you are at a great place already.

  1. My primary measure of success is team self-management
  2. My team is continuously improving their way of working
  3. There are no roles in the team
  4. The team is cross-functional and able to deliver end-to-end value
  5. We measure value, not an effort
  6. I can coach and facilitate conversations and collaboration
  7. I’m not responsible for a delivery
  8. I’m able to work at all three levels of the #ScrumMasterWay concept (My Team, Relationships, and Entire System)
  9. I’m a leader, helping others to grow and supporting organizations on their agile journey
  10. I love Agile and Scrum, and I’m an active part of the Agile community

If you are interested about a real ScrumMaster, check out my book The Great ScrumMaster: #ScrumMasterWay.

Positions and Career Path in Agile Organization

Considering the shift from siloed based departments with subject matter experts focusing on their specialization in traditional organizations to more general cross-functional teams where members combine different skills to maximize the value in agile organizations, there is a trend to generalize positions and flatten the career path as the hierarchy got less important. Agile organizations are moving from fixed detailed positions to t-shaped skill positions or even no-positions at all, with emergent roles depending on the actual need. They abandon the skills based positions and creating a competence based model where employees are deciding what is their journey going to be. We optimize for flexibility and career mobility. The reason for such shift is again dealing with VUCA challenges as the world becomes too volatile, uncertain, complex, and ambiguous for pre-defined skilled based roles. Agile organizations need flexibility. They need to react fast on any changes in the business environment, are there new competitors offering different value, are there new technologies emerging, are there new challenges in the market, those are just a few questions you can ask. But there is no doubt that the world is not the same anymore. To deal with changes and support the people growth, Agile organizations invest in developing coaching and mentoring programs, and encouraging the internal workshops led by employees where they teach each other.

From my experience, from organizational design perspective, the hardest to imagine is the flat structure where leadership is emergent, and no fixed positions even exists. People are developing roles for themselves based on the current situation and needs, teams are forming around business challenges and adjourning once the challenge is solved. It’s a liquid structure. Very flexible, and very purpose driven. It’s one of those things you need to experience to be able to believe in it. And that’s a chicken – egg problem. What helped me was the experience from our Scrum teams, where I could see how self-organization works at the team level. And then applying it to large ecosystem was simply just using the same skills I was used to apply at the team level. In such environment where people take over the ownership and responsibility for doing their best to maximize the value and achieve the purpose, the detailed positions become irrelevant as teams are cross-functional and individuals t-shaped skilled. Then you can freely remove them, as they are not needed anymore. Quite straightforward. The culture and mindset goes first, the practices will follow. 

Now if my last paragraph was way too far for you, the first small step you can start with even in very traditional environment is to shift from managing individuals to team collaboration. The more they collaborate, they develop the T-shaped skills for each individual. It still doesn’t mean that every single person can do everything the same way as anybody else, but they can actually help each other, they can review and test each other’s work, and they understand the whole little by little. T-shirt are not taking too much effort and are creating a ground for forming cross-functional teams. Once you have a cross-functional team, as first step, you can shift from skill-based roles which are not applicable anymore – like tester, software developer, UX designer, business analyst, etc. to general roles – i.e. team member, engineer or as Scrum call is ‘developer’ (note in Scrum we don’t mean ‘software developer’ but ‘product developer’).

It’s not that hard. Collaboration is fun and t-shaped skills are going really fast. On that journey, detailed positions becomes very soon redundant, and soon after, the career path will reflect the dynamics of the organizational design. People in such organizations are not motivated by given career ladder. They care about their opportunity for growth and personal development.

Top 10 Agile conferences to attend in 2023

Every year I speak at many conferences and based on my experience I recommend some places to go for inspiration. Here is my list of the Top 10 Agile conferences to attend in 2023. It’s not my intention to cover them all, I’m sharing places where I like to return. Inspiring places with interaction, high energy, and great speakers.

  1. Business Agility Conference is one of my favorite conferences every year. Two days full of stories from organizations on their agile journey by executives, practitioners, and thought leaders. Join us in NYC on Apr, 26-27, 2023.
  2. AgilePrague Conference is definitely one of the best conferences in Europe. In two days, it creates a unique collaborative space. Two tracks with short talks, and inspirational keynotes. Join Agile Prague on Sep 18-19, 2023, Prague, Czech Republic.
  3. Agile Testing Days is Europe’s greaTEST Agile Testing Conference. Join Agile Testing Days on Nov 13 – 16, 2023 in Potsdam, Germany.
  4. Scrum Australia Sydney is another conference in an awesome city with awesome speakers. Join Scrum Sydney 30-31 March, Sydney, Australia.
  5. LeSS Conference is for practitioners. Since 2016, LeSS Conferences is where LeSS Practitioners share their LeSS experience and learn from new experiments. Join this year’s conference in Berlin on Sep 27-28, 2023.
  6. ScanAgile is one of my favorite conferences. This year is planned for March 28-29, 2023 in Helsinki, Finland.
  7. Scrum Day Colombia has a great program this year and it’s definitely worth visiting. Join Scrum Day Colombia on 24-25 de March 2023.
  8. Agile2023 conference brings agile enthusiasts together every year to share experiences and make new connections. Join passionate agilists from around the world to learn about the latest practices, ideas, and strategies in Agile software development from the world’s leading experts, change agents, and innovators. This year it’s on July 18-22 in Orlando, Florida.
  9. Agile on the Beach is a great event to attend and explore the summer in Cornwall, UK on July 6 – 7, 2023.
  10. XP 2023 is the premier Agile software development conference to combine both research and practice. It is a unique forum where Agile researchers, practitioners, thought leaders, coaches, and trainers get together to present and discuss their most recent innovations and research results. The theme for XP 2023 is Whole Team Sustainability. The conference is planned on June 13-16, 2023 in Amsterdam, The Netherlands.

The selection is based on my personal preference and experiences from those events.

Other conferences to consider this year

There are many great events that didn’t make it to this list, so please share your suggestions with us and we add them to the following list.