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.

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.

Top 10 Retrospective Formats

There are so many books, blogs, and sites describing different retrospective formats, but it’s still one of the most common questions I get in the ScrumMaster classes.

When I started as a ScrumMaster, I was only using one format for about two years – and it worked. We got used to it and I learned how to facilitate it and generate meaningful improvements for the team. When I started coaching different organizations, I realized what variety is available and started practicing different formats. I guess that at that time I became more confident with my facilitation skills and stopped being afraid of experiments.

Don’t forget that the goal of a good retrospective is not to complain but to improve so you need to come up with an actionable improvement for the next Sprint. But let’s start with how structure of a good retrospective works. It’s common practice to do some check-in activity, for example by asking “If you are a weather, what kind of weather are you?” to get the focus of everyone. It doesn’t have to be long but it’s a good energizer. Then you explore the possibilities and gather the data so you can reflect. It usually generates too many ideas, so you need to narrow it down to the topics that are most important for the team i.e. grouping, dot voting, etc. Then you explore the most important topic looking for options “What can we do as a team so that this will never happen/improve”. When you generate several options let the team choose what they like to commit to. Too many actions usually don’t stick, and the team will not do them next Sprint, so don’t aim for too many. One improvement is better than many on a to-do list. If you like to get more details on the process check a talk I gave at several conferences.

Now once we summarized the goal and structure of a good retrospective, let’s have a look at my top ten formats.

Retrospective #1 – Plus and Delta

This retrospective format is the foundation most ScrumMasters start with. Team members take turns saying what they like, what they should continue with, and what they like to improve. It’s simple, everyone has a voice, and you don’t need much preparation.
Retrospective

Retrospective #2 – Star

Another popular retrospective format is called star where you expand the classic format of two questions into five segments and let the team look at the given Sprint from different angles – start, more, continue, less, stop. The team usually writes their suggestions on postits. This retrospective format broadens the perspective and usually generates more topics for the team. It is also easier to get the whole team involved as writing is often easier than having everyone speak.

Retrospective #2 – Star

Retrospective #3 – Speedboat

Once you’re bored with classic retrospective formats, try something more playful. I think the most classic is the speed boat metaphor. The wind in the sails represents what helps us, the anchors represent what is stopping us. And there is no limit to creativity in designing the picture. If you let the team design the picture, it will be even more fun. It encourages the team’s creativity and brings up topics that wouldn’t appear in regular retrospectives.

Retrospective #3 – Speedboat

Retrospective #4 – Three Little Pigs

“Three Little Pigs” is a fairy tale about little pigs that build their houses from different materials. The first pig was lazy and built a straw house to play quickly. The second put a little more energy into building the house and quickly built a house out of sticks and ran off to play. The third worked all day and built a house of bricks. The next day, a wolf walked by, smelled a pig through the straw, and was already looking forward to dinner. He blew up the first house, and the little pig just barely managed to hide the second house, when the wolf broke the sticks with one blow the little pigs ran away to the brick house. When the wolf was unable to break it down, he decided to climb into it through the chimney. But the pigs were ready for that, prepare a pot of boiling water and the wolf never returned…

This retrospective uses the story as a metaphor and has the team compare their system and operation to a house made of straw, sticks, and bricks. This retrospective often helps the team identify longer-term stability, sustainability, and technical debt issues.

Retrospective #4 – Three Little Pigs

Retrospective #5 – Mad Sad Glad

This retrospective tries to look at the way of working through our feelings. Team members describe what makes them mad, sad, or glad. As with the previous formats, you can use postits or just let everyone talk. Not everything is rational and measurable, and it’s good to give space to feelings.

Retrospective #5 – Mad Sad Glad

Retrospective #6 – Timeline

Sometimes the team tell you that they don’t remember everything that happened. In that case, you can try drawing a timeline and have them write down the events already during the Sprint. At the beginning of the retrospective, you revise such a timeline and let everyone remember what was happening when the note was written.

Retrospective #6 – Timeline

Retrospective #7 – ESVP: Explorer – Shopper – Vacationer – Prisoner

Sometimes it happens that the team doesn’t work properly, and they don’t want to participate in the retrospective. ESVP format looks at team dynamics and explore individual team member’s attitude. Explorers are ideal team members. They get involved, are active, come up with ideas, take responsibility. The shoppers are a bit more passive, but when they see something interesting, they get involved and ‘put it in their cart’. The vacationers are cool, glad they don’t need to work. They usually don’t get much involved but are not distracting either. The prisoners don’t want to be here and often are quite aggressive. They can poison the entire event.

At the beginning of the retrospective, let everyone where they are. When you find out that you have most people as prisoners, there is no point in continuing the classic retrospective. Instead, try to look for the root cause and how to help them get out of the prison.

Retrospective #7 - ESVP: Explorer - Shopper - Vacationer - Prisoner

Retrospective #8 – Appreciation

Positivity is the key. Research says that the well-functioning teams have a ratio of positive vs. negative events on average 5:1. Therefore in this retrospective, team members will appreciate the contribution of other team members.

Retrospective #8 – Appreciation

Retrospective #9 – Road to the Beach

One of the more creative forms of retrospectives is based on children’s games. It can take many forms, for example, a trip to the beach representing a metaphor of a Sprint where individual members imagine the Sprint as a trip to the beach and begin to describe it. “On the way to the beach a storm comes,” says the first. And another team member continues: “On the way to the beach a storm came, and we got lost and didn’t know where to go.” And another team member repeats what those before him said and adds another event: “On the way to the beach a storm came, we got lost and we didn’t know where to go and the road was wet and muddy…” and so on. Every event in the journey to the beach is a metaphor for what happened in the Sprint. Sometimes the team needs a change, and this retrospective is fun. Everyone has to guess what each part of the way to the beach meant in reality and also be able to remember the whole story.

Retrospective #9 - Road to the Beach

Retrospective #10 – Bingo!

This retrospective format is the most creative. Do you like playing Bingo? Well, that’s good news because you can play it with your team at the next retrospective. Together, the team brainstorms the events that happened within the Sprint either on cards or on an online board. When brainstorming on sticky notes, everyone must write down the same set of events. Everyone builds their own Bingo! board – the cards are the same, but everyone chooses the position of the individual cards themselves. One team member shuffles the cards and reads them one by one. The others mark what has already been said wait for “Bingo!”. The team member that got a Bingo! explains to the others how he experienced the mentioned events. Then the cards are shuffled again, and another person reads. It is a very playful form of retrospective, and it strengthens positivity in the team and shows different perspectives.

Retrospective #10 – Bingo!

Why Some Organizations are Laying of “ScrumMasters”

For some time there was a trend of laying off so-called ScrumMasters from mostly big organizations. At first, it looks like Scrum is over. However, I would be careful with such conclusions. When you look closer, they are not really firing real ScrumMasters but some sort of delivery managers as they often call them or as I described them in my previous blog post – Scrum “Project” Masters, Scrum “Ceremonies” Masters, or Scrum “Jira” Masters. And they are also hiring them for such skills and responsibilities so it is no surprise. Those employees are mostly just pretending to be ScrumMasters. The problem is they often lack agile experience, lack coaching and facilitation skills, are not trained, and their managers often expect them to micromanage the delivery as they were always used to having everything under control. In other words, the environment is still so traditional that without strong leadership, desire for change, and experience in changing organizations they burn out and give up. “It would never work at my organization”, they say.

Indeed without them initiating the change, it will never work. Every change needs significant energy to change the status quo. And one of the responsibilities of great ScrumMasters is to work at all three levels of the #ScrumMasterWay concept:

Firstly, at My Team level, they need to be able to build a team from a group of individuals. Help them to be self-managing and cross-functional so they can deliver value end to end. Explain to them the dynamics of Scrum, facilitate events, and help them to take over the ownership and responsibility for their way of working. Once the initial work is done and the team starts picking up, they need to coach them so they constantly look for improvements.

Secondly, at the Relationship level, ScrumMasters need to work with teams that collaborate on bigger products. Helping Product Owners to shift from a delivery mindset to a value mindset, build a real value-driven Backlog, and prioritize. Facilitating larger refinements with multiple teams, stakeholders, customers, and the Product Owner. Supporting Product Owners to take over the responsibility and ownership for the entire product success focusing on return on investment and customer satisfaction, not just delivery.

Finally, at the Entire System level, ScrumMasters need to help the entire organization to embrace agility. In other words, be more adaptive. Loosen their budgeting the planning cycles, and be ok with uncertainty. Implement a fast feedback loop, and don’t be afraid to inspect and adapt. By increasing the transparency step by step they need to build trust in this new way of working. It’s the only way how to sustain the current world of constant changes and be ready to solve complex business problems. Simply help the organizations to be ready for whatever the future brings.

All over ScrumMasters need to start their ScrumMaster journey at the My Team level. Working with small teams, experiencing what difference can Scrum and agility make at the team level. Learning about the dynamics of Scrum, self-management, and cross-functionality. The same skills and experiences are then applied to larger entities of Relationship and Entire System Levels. They learn on the way.

In order to be successful, large traditional organizations need a certain number of ScrumMasters experienced with the entire system level so they can coach the organization on their agile adoption journey. Hiring Scrum “Project” Masters, Scrum “Ceremonies” Masters, or Scrum “Jira” Masters will never help and can only result in “Dark Scrum” that not only doesn’t help the organization achieve their business goals but demotivates everyone and often results in firing those “fake” ScrumMasters. It’s sad, but it’s quite a common step for traditional organizations on their agile journey. Indeed you can skip it, and hire real ScrumMasters and start changing right away, but for many organizations, it’s too radical approach. They still hope they can be successful in dealing with complexity in nowadays constantly changing world without change. I don’t think so. I believe the change is inevitable. But we’ll see what the future brings, and what organizations will struggle, and what organizations will survive.

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.

Agile is a Change

It’s more than 20 years since Agile Manifesto and some organizations still take Agile as another process or tool. But it can’t be farther from reality. We try to explain that it’s not about “doing” agile but “being” agile. That it’s about changing the way of working and thinking, the overall mindset. But companies are often looking for shortcuts and searching for simple solutions. Rename some processes, create a new role, or buy a different tool. Though that could be useful, it’s not the core of the change.

But let’s start with who should be driving the transformation and who should be implementing Scrum in the organization. Surprisingly for many people, it’s not some manager but someone who has their own experience with agile, scrum, self-management, and end-to-end cross-functional teams – the ScrumMaster. Indeed that person should be an experienced agile coach who is ready to demonstrate leadership and take ownership of a change, working at the Entire System level of the #ScrumMasterWay concept.

There are many concepts that they should be familiar from System Coaching (i.e. ORCS) to classical change management i.e. (Kotter’s Eight Steps of successful change). But in a nutshell, you can start a change with the following steps:

  1. Why – create a sense of urgency – Why is it important to the organization? What will happen if we don’t change? Unless you can create a sense of urgency, the change is unlikely to be successful. Do others see it the same way? Do they feel the same need?
  2. Who – find your allies – Identify the supporting team that will support you and helps you to implement the change. It can be the group of ScrumMasters, but it’s not limited to this group. You are looking for enthusiasts who would be willing to invest their time and name into promoting the change.
  3. Vision / Dream for a change – Do you have a dream of the future? In a year from now, where would you like to be with this organization/group/team?
  4. Communicate. Communicate. Communicate. And then again. Communicate.  It’s a new way of working so one presentation will not kill it.
  5. Celebrate success – don’t forget that it’s not processes and practices but the success that scales. Make it visible and don’t forget to celebrate each successful step. Instead of focusing too much on what we are struggling with, start with what is working well and make sure it sticks. The rest will be improved step by step.

Sustainable Agility

One of the very common questions people ask is why companies are failing their agile transformations and what do we need to do to create sustainable agility? Let’s start with the most common mistakes. The first one is starting the change without creating a sense of urgency. If you don’t know why you need to change and what happens if you don’t change, there is only a little chance to be successful. Unless you know why you are changing the way you work (to be more agile, Scrum, or Kanban), then don’t do it. Neither Agile, Scrum, nor Kanban is your goal. They are just some sort of a ‘walking sticks’ helping you on your journey to success. You need to have a higher purpose defined which will be stronger than people’s individual goals and therefore unify them along the way. There needs to be a strong sense of urgency in the environment. Being different or implementing agile is not enough. There is another reason why the real strategic reasons need to be defined and that’s because those are exactly the metrics you need to measure to know if your transformation was successful. For example, if the real business reason for a change was to increase flexibility and fasten your learning, that’s how you can measure the success of the agile transformation. Neither velocity nor number of retrospectives matters.

The second most appealing way how to fail is to copy what someone is doing. Take their current way of working as a strict process and call it the only right way. When it worked somewhere else, why shall we take a hard time trying to invent it ourselves when we can just apply it as it is. Let’s rename it to some fancy name and fix it. It usually starts with a big push from the top and has often wrong expectations 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. You need to experiment and develop your own way of working. Only then you get the right habits and mindsets. MyCompanyAgile, nor Agile2.0 will help you.

To create your own flavor of the way of working, you need to start from the bottom, get experience from the teams, learn on the way through your own failures, do experiments, and have the courage to do things differently. Turn the organization around and build it based on the cross-functional teams who can actually deliver value end to end. Be business value driven, customer-centric. At some time, when you get used to this way of working at the team level and can imagine what needs to change in the business, systems architecture, and multiple team picture and you might need to get ready for the next step of scaling (implementing the agile way of working to larger products and ecosystems) and eventually the overall system of business agility (changing the way an organization operates, it’s structure, culture, and organizational design).

In summary – reflect, create a sense of urgency, experiment to find your own way, start small at the team level, and only once it works scale it through the entire organization. There is no silver bullet, you need to create your own way of working.

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.