Scrum - Agile and Scrum Blog

10 Most Common Mistakes of ScrumMaster

Being great ScrumMaster is a journey, where you have to learn a lot about Agile, Scrum, coaching, facilitation, change, business agility, technical practices, leadership… But all over it all starts with having the agile mindset. This time, I’m not focusing on who you need to be, but quite opposite what you should avoid, as one of the very common questions at the classes is what are the most common mistakes of ScrumMaster. So here is the list:

Being a Team Assistant

Taking care of the team, solve issues (impediments) for them, plan meetings… It’s easy to get there as it seems to be helpful. But only in the short term. Long-term, it will create unconfident people who rely on ScrumMaster and never take over responsibility and ownership. Instead, you shall show them they can solve most of their problems by themselves, and be a good coach, facilitator and servant leader.

Share ScrumMaster Role with Another Role

Such ScrumMasters have usually lack of focus. They don’t spend enough time observing, finding better ways for the team to become great, and are happy and done with the role once everything is ok. Instead of sharing ScrumMaster role with another role, have ScrumMaster full time, let them focus on how they can become great ScrumMasters and truly master the agility so it will help the entire organization. Give them space to invest more time to the other levels of the #ScrumMasterWay concept.

Team Only Focus

Speaking about #ScrumMasterWay concept, many ScrumMasters believe that their only role is to support their development team to be great. I mean this is fine, but it’s just a tiny part on the ScrumMaster journey. It’s like a kindergarten. You need to experience it. That’s where you learn and practice all State of Mind approaches, that’s where you get confidence in yourself as a leader and change agent. But even if you are super successful, it’s only changing at the team level. You need to go broader and follow the other steps of the #ScrumMasterWay model and change the entire organization into an agile organization.

Technical Expert

Being a technical expert is dangerous for ScrumMasters. They feel a strong need to advise people on what to do. If you know a better solution, it’s just easier to tell them, then help them to figure it out. Instead, ScrumMaster shall trust the team they are the experts and coach them so they become better.

Manage Meetings

ScrumMaster is neither manager of the Scrum meetings, nor responsible for scheduling them. Instead, ScrumMaster shall be a facilitator, who takes care about the form of the conversation, not the content.

Don’t Believe in Scrum

How many times you’ve seen ScrumMaster who is doubting about the core Scrum so much that no one is following them? You need to be sure it works, need to believe in it, need to be the biggest Agile enthusiast all around. Otherwise, you can’t make the others to follow.

Apply ‘Fake Scrum’

Sometimes ScrumMasters take Scrum as just a process, don’t search for deeper understanding. Just do it (Daily Scrum, backlog, ScrumMaster role, …) as Scrum says so. They don’t have the right mindset. Agile and Scrum is not about practices, it’s a different way of thinking. It’s about “being” not “doing”.

Waiting for Someone Else to Start the Change

ScrumMasters often wait for someone else to initiate a change. They are reluctant to take over responsibility and ownership and the organization is not moving anywhere. Instead of waiting forever, ScrumMaster shall be a change agent, responsible for the entire organization Agile journey.

Scrum and Agile Expert

It’s enough to understand Agile and Scrum. Which is simple so we are done. Being ScrumMaster is a journey, and you can never stop learning. Even if you feel you know Agile and Scrum, there is always something new. And there are those other domains you need to master: coaching, facilitation, change, business agility, team dynamics, technical practices, leadership, … The learning is never ending.

We Are Great Team, We Are Done.

Often ScrumMasters let their team believe they can be done. The team is good, we finished our Agile transformation. Don’t bother us with new ideas. We know how to work. We are self-organized. You can never be done in a complex environment. There is always a better way. So instead of this false believe, ScrumMasters shall coach the team so they see other opportunities to inspect and adapt.

From Good to Great: Cross-Functional Teams

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

Business value

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

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

Impact

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

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

From Good to Great: Collaboration

Next blog in the From Good to Great series (Don’t Copy Find Your Own Way, Radical Transparency, and Agile Mindset) is focusing on the collaboration. There is nothing magical on it, just people are so got used to working as individuals that they forgot what the collaboration is about. However, collaboration is the key aspect of the Agile environment and if you can’t collaborate, there is no way you become Agile.

The traditional organizations are all about processes, rules, and delegation. All we need to do is to analyze the situation, come up with the way we want to handle it, and describe it in a process, and follow it. It shall be enough. It’s the world where we simply rely on processes in our day to day decision making. In simple situations, it works well, as the transparency and predictability of the situation are playing in favor. In complicated situations, it might not be flexible enough and people and organizations will struggle to react properly to the situations. In a complex situation when it’s hard to predict what happens it’s mostly failing.

“Tight processes are killing creativity and only work at simple and predictable situations.”

The more complicated is the situation you face on day to day basis, the more are companies failing to describe the process to be followed. It seems to be unavoidable that rules and practices are not enough to be successful, delegation come in place and the situation results in creating new roles and position for those who are responsible for certain part of the process. It allows more flexibility and responsiveness as people on the contrary to the processes can make a judgment based on the particular situation and solve it better. It’s the world of individual responsibility, where we create a single point of contact we can blame when things go wrong. Similarly to the previews process-oriented world, there is no real collaboration happening. Either I do it, or you do it. And it must be clear who is the owner.

“Individual responsibility kills collaboration and team spirit.”

Finally, over here we cross the line of collaboration. At least from a technical point of view.

This already starts feeling like a collaboration. At least at the first look, as there are more people working together. However, there is still one person responsible and the other just helping them. It’s a good first step, but at the end of the day, it’s closer to the delegation scale, than collaboration as the unequal ownership make one side more invested in the results than the other, where the owner usually makes decisions, plans, and responsibility, while the other support them with the inputs. It’s still more likely to create blaming than shared ownership and responsibility. While it may be a good first step, it’s not collaboration as we speak about it in an agile environment.

“Helping each other on their tasks is not a collaboration. Collaboration needs equal ownership.”

Finally, there is a real collaboration, where people have shared responsibility, shared ownership, and one goal together. It’s not important who does what, there is no task assignment up front, they all just do what is needed and make their decisions at the time. This is a type of collaboration, is what makes teams in Agile and Scrum great. Such collaboration creates high performing environments. If you truly want to be agile, and not just struggle to pretend that following practices are enough, it’s time to get rid of individual responsibility, which is often grounded in your org chart, position schemes, and career paths and learn how to create a real collaborative environment with shared responsibility and ownership. Learn how “We can do it together”.

From Good to Great: Agile Mindset

The next blog in the From Good to Great series which started by Don’t copy, find your own way and Radical transparency is focusing on the most important part of being Agile – Agile mindset. The mindset change is very difficult 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.” But it still exists so I thought I will share with you the picture how I see the Agile mindset change journey now.

Delivery

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 more details. 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 others 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, but that’s not enough to be agile.

Strategy

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 prerequisite. It’s not about delivering faster (but wrong things). It’s about maximizing value, which actually can be achieved by delivering less than before. 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 from customers through regular Sprint Reviews, and good Product Owner brings decent business knowledge and creates a relationship with the customers so the feedback makes sense. Tools like User Stories and Story Mapping, which are by definition customer-centric 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

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 experiment. 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 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 created impact. If you know what do you want to achieve, you can measure if it’s happening. The sooner the better. Gojko Adzic and his Impact Mapping is a good tool to start. As he often shares in his stories 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 Agile.

I travel and speak at many conferences per year, and often to help them promote their event I draw a picture from some interesting talk. This time I decided to share Gojko’s keynote sketch from Agile Vilnius (#9 to attend this year 🙂 ) here as it is well aligned with my blog post and there is never too little visualization.

Top 10 Agile conferences to attend in 2019

I travel & speak at many conferences each year. Here is my list of TOP 10 conferences you shall attend in 2019:

#1: Business Agility 2019 Conference (New York, USA) March 13-14 2019. This conference has the most innovative format of all Agile conferences – three short industry experts’ talks are followed by facilitated conversation around tables.
#2: Agile Prague Conference (Prague, Czech Republic) – September 16-17, 2019. An awesome program, collaborative atmosphere of open space format, good value for money.
#3: Big Apple Scrum Day (New York, NY, USA) – May 10, 2019. Enthusiastic community, great space.
#4: Agile Austria: (Graz, Austria) June 25-26, 2019 – great place to meet Agile enthusiasts. Have fun with games and workshops.
#5: ACE! (Krakow, Poland) – May 23-24, 2019. Innovative form & great atmosphere. Focusing on not only Agile but good design, LeanUX, and Design Thinking.
#6: Agile 2019 (Washington, D.C., USA) August 5-9, 2019. Top Agile conference for the size and speaker selection. It’s a huge event which is unfortunately very expensive, but always worth the visit.
#7: Agile Days Istanbul (Istanbul, Turkey) April 4, 2019. Very interesting conference organized by local community focused on Organizational Agility.
#8: Scandinavian Agile (Helsinki, Finland) – March 13-14, 2019, Interesting speakers, inspiring content.
#9: Agile Tour Vilnius (Vilnius, Lithuania) October, 2019 – enjoy the day full of fun.
#10: Agile Testing Days (Potsdam, Germany) November 3-8, 2019. Interesting keynote speakers, deep insights in testing.

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

Other conferences to consider this year:

(Please share your suggestions with us and we add them to the following list.)

- Beyond Agile Israel 2019 – January 27, 2019, Tel Aviv, Israel.
- IAF EME Conference “Agile and Facilitation” – May 2-4, 2019, Milan, Italy.
- Agile for Automotive – May 15-17, 2019, Detroit, MI, USA.
- Business Agility Vienna 2019 – May 20-21, 2019, Vienna, Austria.
- Global Scrum Gathering Austin 2019 – May 20-22, 2019, Austin, TX, USA. Talk to Scrum practitioners, join coaches clinic, get hands-on experience.
- Agile on the Beach – July 11-12, 2019, Falmouth, Cornwall, UK.
- Agile Islands 2019 – September 24, 2019, Åland Islands.
- Global Scrum Gathering Vienna 2019– October 28-30, 2019. Talk to Scrum practitioners, join coaches clinic, get hands-on experience.

Deadlines in Scrum

One of the topics most of the project managers and traditional organizations at the beginning of their Agile transformation journey are struggling are deadlines. How can we do Scrum and commit ourselves to the date when we don’t know the scope? Let’s make this clear. Scrum is purpose driven, not functionality driven. What does that mean? It’s not about delivery, it’s about achieving the certain outcome. And that’s a game changer. Instead of fixing the whole scope at the beginning, we spend the time to understand the purpose. Form a vision. What do we want to achieve? For whom? Where is the value? How are we going to change the world once it’s done? What makes it different?

Once you have enough mutual understanding of the business value and the vision, you are ready to continue. So, we agreed that in long-term, you need to achieve this, what about mid-term? What is the most important to achieve now? Where is the biggest risk we need to mitigate by feedback? What impact do we need to get? Once you have this release agreed, you are ready to start Sprints. Again, Sprint is not about precise functionality delivery, but achieving certain impact, deliver value and learn from that. Therefore, there is a Sprint Goal – a small vision for a Sprint, answering a question what do we need to achieve in the short-term.

Finally, none of those deliveries can actually fail. Of course, you can learn that your business idea was wrong or the value was not where you would expect it. That’s why we use Scrum, to test our hypothesis. But the nice thing is, that neither Sprint nor release can actually fail the delivery if you prioritize well because 80% business value is hidden it 20% of the functionality. If you prioritize the value, you always achieve the goals.

So next time when your customer ask when it’s going to be done, you can invite him in the conversation about the value, vision, release charters, and Sprint Goals. Don’t ask what they want, ask what they need and why. Only then you are both going to be successful with Agile.

Agile at executive team level

Agile can’t stay just at the team level. Agile transformation only creates disturbance and gap between the management and employees. And the more Agile the teams are, the bigger the disconnect is. Managers feel lost, forgotten and start to be frustrated that those self-organizing teams might eventually not need them. Part of the problem is they’ve never been part of any Agile or Scrum team themselves. They’ve seen them working, joining them for Reviews and listening to their stories, but that’s not the same. People need experience to understand a different way of work. You might still remember your first feeling, when someone told you that this Agile and Scrum will be great. “What?” you thought, this stupid process will never work – what if… At least I still remember how I felt several years back.

One important thing companies often forgot during their Agile transformation is how to get management on board. Managers deeply need their own experience with Agile and Scrum. They can’t just read about it. Otherwise you continue hear such funny remarks like “I got it, you are a team, you collaborate, but who is responsible?”, “We don’t need ScrumMasters, some developer can take it as a second role” or “We don’t need Product Owner, we have a product committee”. If you really mean the Agile transformation seriously, it’s time to change the way you implement it. It’s not just a different process decided by C-level executives and implemented without them noticing. It’s a significant change of the culture and mindset. So why don’t we start from the other side, forming the first team from executives. Let them experience Agile and Scrum. Make them feel the pain of being the group of individuals with their own goals, no common passion, no trust. Or no unifying purpose. Let them experience what the self-organization is about, how the cross-functionality works. Let them do their refinement, planning, standups, reviews, and retrospectives. It’s always fun. And the same way as such first pilot is painful and difficult for a product development team, it is even more painful for the executives. They would hate it. If they can, they would kick you out of the door. So be ready for that and have strong enough sponsor who understands that such painful experience is critical for the organizational success. It’s like any other exercise. Starting is difficult. We all are great at finding excuses why running today is just not a good idea. I will run tomorrow. Or when it’s the right weather. Actually, I don’t think I need to run, I’m just good without it. The other people need that, not me. Familiar? If you force yourself to start and develop a habit, it is fun and you would miss it if you skip that for even a day. The same with Scrum, the first time you experience the power of the true team spirit you never want to be back. No matter where you are in the company orgchart. It works the same way.

Unfortunately, executives are rarely going that way. There are two reasons. First, it is a painful journey. That’s why I’m not running every day. It’s not that bad that I would have to, right. The company is still fine. Not struggling enough. But maybe when that happens it’s too late to change. Second, most of the Agile Coaches need a day job. They care about 6+ months contracts. They are afraid of losing it if they would push too much. They often forgot that their job is not to please the customer, but to change them. Guide them through that painful experience with all the risks that they will not like it, and stop. Very often you hear from them “I know that this is not the way how it shall be but this is a corporation, you have to do it differently” so they still have PMOs, no Product Owners, weak ScrumMasters and not real teams either. It’s a much more painful experience for everyone involved then starting this fake transformation repeatedly all over again and again.

If you mean it, get a real Agile coach. Not a consultant. Find someone who would guide you how to do it. Not do it instead of you. Who would be with you once per Sprint / month / quarter. Do their intervention, show you the way where to focus next and let you exercise. Start with smaller pilots. The first Agile bubbles. The more bubbles you make, the better. Aim for our own experience and learning. Inspect and adapt. Don’t forget that your executive team forms one of the first bubbles. They have to learn in the first wave. If you do it that way, Agile mindset will grow organically and very soon you would be ready to share your own Agile success story and inspire the others.

Five books every Agile leader should read before they start Agile transformation

To continue my with my book recommendations (check Five books every ScrumMaster should read and Five books every Product Owner should read), I have several books here, I would recommend every Agile Leader and manager in Agile Organization to read before they start Agile transformation. It’s a mix which will help you to understand Agile Leadership, Agile Organization, it’s structure, design, and culture and allow you to adapt to the different leadership style. Enjoy reading 🙂

Niels Pflaeging – Organize for Complexity: How to Get Life Back Into Work to Build the High-Performance Organization is about complexity and work – and about how to deal productively with both. A condensed introduction to the theory and practice of organizational high performance. A manifesto for contemporary leadership and profound transformation in organizations of all kinds. It is “practically theoretic”, featuring cutting-edge insight. It proposes new language and thinking for a new way of work and organizations.
Frederic Laloux – Reinventing Organizations is a must. The way we manage organizations seems increasingly out of date. Survey after survey shows that a majority of employees feel disengaged from their companies. The epidemic of organizational disillusionment goes way beyond Corporate America-teachers, doctors, and nurses are leaving their professions in record numbers because the way we run schools and hospitals kills their vocation. Government agencies and nonprofits have a noble purpose, but working for these entities often feels soulless and lifeless just the same. All these organizations suffer from power games played at the top and powerlessness at lower levels, from infighting and bureaucracy, from endless meetings and a seemingly never-ending succession of change and cost-cutting programs.
Large-Scale Scrum: More with LeSS is looking at the organizational design from a different perspective. Rather than asking, “How can we do agile at scale in our big complex organization?” a different and deeper question is, “How can we have the same simple structure that Scrum offers for the organization, and be agile at scale rather than do agile?” This profound insight is at the heart of LeSS. In Large-Scale Scrum: More with LeSS, Craig Larman and Bas Vodde have distilled over a decade of experience in large-scale LeSS adoptions towards a simpler organization that delivers more flexibility with less complexity, more value with less waste, and more purpose with less prescription.
The Responsibility Process: Unlocking Your Natural Ability to Live and Lead with Power is about FREEDOM, POWER, and CHOICE. Leadership is innate. The Responsibility Process proves it. The Responsibility Process is a natural mental pattern that helps you process thoughts about taking or avoiding responsibility. How you navigate it determines whether you are leading toward meaningful results or just marking time. This book gives you precision tools, practices, and leadership truths to navigate The Responsibility Process and lead yourself and others to freedom, power, and choice.
Leadership and Self Deceptions shows how most personal and organizational problems are the result of a little-known problem called self-deception. Through an entertaining and highly instructive story, Leadership and Self-Deception shows what self-deception is, how people get trapped in it, how it undermines personal achievement and organizational performance, and- most importantly the surprising way to solve it.

BONUS:

Finally, there is a bonus book which I wrote a few years after this blogpost 🙂 The Agile Leader: Leveraging the Power of Influence Book published in December 2020 will help you to unleash your agile leadership potential and guide your entire organization toward agility. It’s a great overview of concepts for managers, directors, executives, and entrepreneurs―anyone, regardless of position, who’s ready to take ownership, challenge the status quo, and become a true agile leader. See more at https://greatagileleader.com.

5 reasons why to attend AgilePrague Conference 2018

#1: World-class Program
Several years in a row we managed to achieve high-quality program while keeping it affordable to the people in the Czech Republic. This year you can be looking forward to awesome speakers – for example: David Hussman, Roman Pichler, Evan Leybourn, Marsha Shenk, Yves Hanoulle and many more.

#2: Business Agility Focus
The theme for this year is Business Agility. Agile is more than an IT process. We are going to talk about Agile transformations, scaling, the new ways of running your products and businesses, Agile Leadership, collaborative culture and great teams.

#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.

#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, wonder though old town & narrow streets, enjoy one of the greatest historical cities 🙂

Looking forward to seeing you on Sep 10-11, 2018 at AgilePrague Conference! Register for Agile Prague 2018.

Is Agile for us?

It seems to be a very common question. In general, if you are willing to change yourself, yes. There is no bigger enemy than yourself. There is no environment, size or business restrictions. Any company can change if they find a strong enough reason for a change. However, there are few questions which can help you to identify if you are ready or not.

Agile is not for us if…

We are looking for “magic” that helps us deliver everything faster.
We want to allocate individuals on tasks based on their specialization.
We focus on a buyer-supplier relationship and customer acceptance.
We focus on specification, requirements, and change requests.
We optimize for local efficiency (individuals, component, technology).
We just want to be “modern” and copy some terminology (tribes, squads, etc.).

Agile is for us if…

We are ready to build real self-organizing stable teams.
We are ready to form real cross-functional teams.
We are ready to build a partnership with customers and looking for feedback.
We are ready to focus on fast value delivery in a working product.
We are ready to optimize for adaptiveness, flexibility and change responsiveness.
We are ready to change our way of working to achieve some strategic goals and sustain the current complex world.

The first list is grounded in a misunderstanding of what the Agile and Scrum is about and leads to “Dark Scrum”. The second implies a significant change of your approach, values, the way of work, simply the change of mindset. It’s up to you 🙂