Agile Transformation Metrics

It’s very common that people ask me how they shall measure the success of their Agile transformation. It’s a hard question because there is no meaningful metrics unless you know why you decided to start the agile transformation at the first place at all. Agile is not your goal, it’s just a way how to achieve some of your more strategic goals i.e. address complexity better, be more change responsive, shorten time to market, be more flexible, … And once you know why you are starting your agile journey, then those reasons are exactly the metrics you are going to measure at the organizational level. All are business-oriented and value-driven  (outcome), so there is no velocity, no story points as those are focusing on output.

Team Measures

If you want to have a fast culture check on how far you have moved towards the agile mindset, you may look into how many experiments the teams are running, what are their actions from the retrospectives, and how they help them to deliver more value, how likely your teams take failure as learning vs. blaming opportunity, how close are they to customers, and how they collaborate vs. work individually or in silos. As a follow-up, you can have a look to your positions (are they rather broad supporting cross-functional teams than detail task-oriented), recruiting (are we hiring for approach and personality over the hard skills), performance review (team-oriented based on peer feedback over the individual), goals and objectives (team-based focused on purpose and outcome over tactical and individual KPIs focused on output), … and I can continue.

Looking to technical practices, you can check how your software teams implemented Extreme Programming practices i.e. Continuous Integration (even one-minute old code is old code), TDD – Test Driven Development (and overall attest automation), if they use pair programming or mob-programming to collaborate, having strong Definition of Done, focusing on one story at a time, and are ready for Continuous Delivery.

All over Agile is about team collaboration, customer-centered value-driven way of working, and short feedback loops. The rest are just practices, processes, and tools which might support your journey or not. The most important is not what exactly you are measuring, but what you are going to change based on that metric. If the metrics is helping you to improve and change your way of working, it’s a good metric. Measuring something just so you have it, or so you can draw a chart is a waste of your time.

Failing Fast

To my huge surprise, I realized that the concept of failing fast and learning from failure is difficult for some people to accept. They always feel the frustration when I say that ScrumMaster needs to feel comfortable to let the team fail so they can learn. I wrote about it here a few times, so you most likely know it, but the goal of a ScrumMaster is to make teams self-organized. They are not their assistant nor their mothers (as it might end by being dependent on a ScrumMaster), they are not their managers (the team is self-organized, fully responsible for their decisions), ScrumMaster is a coach, facilitator, helping the team to take ownership and realize they can solve most of their problems by themselves. And with every decision you take, there is a responsibility going hand in hand, and risk that you might fail. It is OK to fail if you learn from it. So ScrumMasters are not responsible for preventing failure, but for making sure the team will learn from it and figure out how are they going to work differently next time, so it will never happen again. And that’s very different from what the project managers have in their job description. And here is why – Project Manager is responsible for making decisions, ScrumMasters is not. It’s either the Development team (for how are they going to organize themselves to maximize the value towards the Sprint Goal), or Product Owner (for maximizing the value, prioritizing the backlog, and achieving the overall product success including the return on investment).

Agile is about safety to experiment and learning from feedback. In the VUVCA world, you never know what is the right functionality which will multiply the value and success. You need to inspect and adapt. Learn from failures. Be ready to respond to changes and be flexible to shift the direction based on feedback. Scrum has it all. Short Sprints which make it safe to fail, Retrospectives which ensure fast learning, Sprint Reviews which create a platform for frequent customer feedback, and Product Owners who take care of maximizing value and return on investment. It’s one thing to read it, and another to live it. What happens in your body if you hear “Your Sprint just failed.” Is it closer to the panic and looking for who to blame or is it closer to being curious and excited to search for improvements? It’s a simple question that indicates the level of agility. Failure is a good thing. All you need to do is learn from it.

Barriers of Agility

In most of the surveys about barriers of agility in organizations, you learn that the top three places are culture, structure, and leadership. There is no surprise. Organizations were designed for a different world where you can analyze the situation, plan what you are going to do, cascade the goals through the organization, and deliver it accordingly with minimum change requests, simply for the predictable world. The problem is that in the last decades the world has become less predictable and changes were more frequent, the VUCA challenges overtake our everyday life reality and the organizations realized they are too slow to respond. Like dinosaurs thousands of years ago. Change is inevitable. Analyzing, planning, and following the plan is not an option anymore.

Innovations, creativity, and flexibility are new norm and organizations which can create environments where teams are self-organized, collaborate on maximizing the business value, and co-creating the organizational goals are taking over positions in the Fortune 100 list. Most of the big corporations are still in the cage of the old-world reality. They optimize for speed. But speed is not that important asset anymore as going fast in the wrong direction doesn’t lead anywhere. Instead, we need flexible environments optimized for creativity. Thinking about flexibility, the organizational structure needs to change to allow it. Departments focused on competences or components, not business value, is meaningless. They kill creativity. Hierarchy keeps responsibility by the managers and prevents people from taking ownership and decide themselves. Again, it kills creativity.

Culturally the traditional organizations are leaning towards competing over collaborating, and controlling over creating. The practices of detailed positions, reward systems, performance reviews, and individual goals and objectives are keeping the organizations in competing and controlling quadrants.

Finally, the leadership needs to change significantly. Traditional organizations were expecting leaders to be Experts or Achievers. Agile organizations need Catalysts. They need leaders who are visionary, purpose-driven, are able to see the business and organizations from different perspectives. They enhance collaboration and are good at building teams and networks. They search for win-win solutions, are good coaches, and helping others to grow. They support running experiments and use failure as learning.

All over we can say that Agile Organization needs different leaders, cultures, and structures. You don’t have to start with changing all of them at once, but sooner or later such change is inevitable. The fewer barriers you give agility on the way, the more likely the frameworks, methods, and practices make a difference and help you to be successful in the VUCA world.

ScrumMaster Mind

Great ScrumMasters are patient, can give space and dedicate their time to help other people grow. They are servant leaders and Catalysts. It sounds simple and not conflicting at first look, however, the real disconnect people feel at first, when they came across the role, is often about their ability to let things go. As a ScrumMaster, you are not responsible for the delivery. As a ScrumMaster, you need to let them fail. As a ScrumMaster, you can’t make a decision for them. “But I need to make sure they deliver the Sprint!” people often say with fear in their eyes. “I need to make sure they are efficient!”, “I need to tell them … ”.  Not that quite. Being a ScrumMaster is a very different role than being a Project Manager. They actually can’t be more different from each other. Project Managers are responsible for delivery, they shall manage, make decisions. ScrumMasters are coaches, they help other people to grow. They are facilitators, help the conversation to flow, but don’t interfere with the content. The team is responsible for delivery, the team is responsible for organizing themselves, and the team is also responsible for improving their way of working. ScrumMaster can help them, but not push them. The ultimate goal of the ScrumMaster is to do nothing – or if you wish to build great self-organizing teams.

ScrumMaster builds self-organizing teams

For example, imagine a team, which is super confident that they are going to finish all the parts they planned for that Sprint. In the middle of the Sprint, you can see from the board that they are not in the middle of the work, not even close. They started many items but didn’t finish much. It seems to you that they are not well organized, abandoning problematic tasks and not collaborating. What are you going to do? When I ask this question at the classes, most people feel a strong need to guide the team, tell them how they shall organize, and when we talk about the fact that as a ScrumMasters they have no power to decide for them, they are very uncomfortable. “But I have to make sure they deliver it”, they say. “I can’t let it go, what my manager would think?”.  And it’s very hard for them to accept the fact they can’t push them. They can try their best to coach the team and show them what can possibly happen, but if they are still confident and don’t see that as a risk, eventually you need to let it go and let them fail. Failing one Sprint is not a problem. At the end of each sprint, there is a Retrospective and that’s the time where you can help them reflect on what just happened and come up with action steps on what are we going to the differently next time, so this will never happen again. ScrumMasters are not responsible for Sprint delivery (the team is), ScrumMasters are not responsible for the product delivery (that’s Product Owners job), but they are responsible for making the team self-organized and improving. It’s not that hard as it looks. Try to let things go next time, failure is a good thing. Fail fast, learn fast.

Hierarchy

I recently posted a quote from a conference saying that “Removing hierarchy and cross-team dependencies made space for strong collaborative teams.” Interestingly, I got many comments and questions about it. So let’s talk about hierarchy and why we don’t need it in Agile space.

But before we dive deeper… What is the hierarchy? – using dictionary definition: “Noun – a system in which members of an organization or society are ranked according to relative status or authority.”

Traditional Organizations Need Hierarchy

Organizations where employees are ‘ranked according to relative status or authority’ is what we inherited from the traditional organizational paradigm which is built on top of the belief that hierarchy is the key – every organization needs to have an org chart, we have to have a clear line of reporting and decision making. And I’m not saying it’s wrong, you can keep all the traditional practices like a career path, positions, performance reviews, KPIs, etc. however such organizational design is not what I’m interested in and has nothing to do with ‘being agile’. Traditional organizations might be still well functioning, applying some frameworks and ‘do agile’, but the mindset at the organizational level is just not there yet.

Agile Organizations Are Flat

What I’m interested in is applying an agile mindset at the organizational level. Help not only individuals to ‘be agile’, but the organization as well. Agile is fundamentally changing the way organizations operate. Agile organizations are built on a new paradigm. They have a team as the key building block and are forming collaborative, creative, and adaptive networks from them. In a team, we don’t have status, and we have no ranking either. All team members are peers, with no positional hierarchy and power. Indeed, you can gain respect from the other team members in a team, but you can also lose it if you don’t bring value to the people around you anymore. It’s flexible and dynamic. All you need is radical transparency, peer feedback, and honest culture with implicit trust. You might say it’s a lot, and I’m far from saying it’s easy. However, once you experience it, you never want back to the traditional world.

Who decides on the process? Teams. In a flat organization, they are not only self-organized, but self-managed (so they are responsible for the processes), self-designing (so they are designing teams), and self-governing (so they are setting overall direction). To get more insights on those terms, see how LeSS defines them. All over, you don’t need much more than what I already mentioned – transparency, feedback, and trust. If that’s too abstract, you can get inspired by Sociocracy 3.0. It will give you more ideas on how to get there.

Who set’s the goals and objectives? No one. They are co-created by the teams, reviewed through radical transparency, and inspected and adapted via frequent feedback to flexibly address the business challenges. At the end of the day, fixed goals are useless in the VUCA world. VUCA stands for volatility, uncertainty, complexity, and ambiguity. In other words, we speak about the world which is not predictable anymore. The cascading goals neither unify nor motivate. The more decentralized and autonomous the organizations are, the higher need is there for a strong evolutionary purpose. Co-created and owned by all. Transparent. You can get inspired by Frederic Laloux’s work.

What about budgets? Who says we need to have a budget in the first place. Again, you don’t need much more than what I already mentioned – transparency, feedback, and trust. Make all the finances transparent, and use instant peer feedback to review it. If that is too radical, you can get inspired by Beyond Budgeting.

All over, I guess you got the pattern. In an agile flat organization, we don’t need most of the traditional practices. All we need is radical transparency, peer feedback, and honest culture with implicit trust. No one is saying that you have to turn your organization into a flat structure and an agile mindset. But if you want to do that, be ready to redesign the way you work entirely.

10 Most Common Mistakes of ScrumMaster

Great ScrumMasterBeing 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.

Component teams

Business value

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

Cross-functional teams

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

Impact

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

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

From Good to Great: 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.

From Good to Great: Radical Transparency

I started the series From Good to Great by advising you to find your own way of being Agile. The next blog focuses on radical transparency. Let’s be truthful for a moment, how many organizations you worked for have real transparency, and how many are hiding information behind the teams or department walls, encourage by processes and claimed necessity of being compliant. Lack of transparency is a strong weapon which eventually can kill any Agile transformation as it makes collaboration and self-organization almost impossible. Lack of transparency is a great friend of hierarchical structures supported by fear and politics. “If I’m the only one who has the information, no one can jeopardize my position, and I’m safe being manager… All I need to do to be promoted is wait and make sure that no big mistake happens.”  Sound familiar?

Once you really mean it with your Agile journey, radical transparency is the key enabler. Together with the empowerment raising from the self-organization, it brings the energy and people start to take over the responsibility and ownership. They don’t wait until someone promote them to any function, they don’t wait for any orders. They take it over and collaborate on the solution.

Radical transparency is the key enabler of agility

Understand the Purpose

To understand the organizational vision and have a clear evolutionary purpose is crucial to successful collaboration and self-organization. In order to take over any initiative, people have to understand where are we heading, who are we, and who we don’t want to be. There is a very simple test. All you need to do is to take a random employee and ask him/her what is the vision/purpose/uniqueness of this organization. For simplicity, you can start with the executive leadership team to see if they didn’t lose the track of why they are there. 🙂 The good news is they usually know exactly what is the vision and can explain it in a very clear and engaging way. But when you do a cross-check across the organization, very likely there is a disconnect (usually several or even too many) which results in a very disruptive chaotic way of working. To fix it, storytelling is your best friend. Nothing can set up the stage better. Using serious of collaborative workshops like worldcafe, openspace, etc. involve people in co-creating the vision and help them to be part of it. Storytelling will set the directions. They need to own it, they need to believe it, they need to feel a need to be part of it. That’s the energy you need to begin. It brings innovative thinking, creativity, and empowerment, when people start offering help, ideas, and are ready to sacrifice personal goals in exchange for being part of something bigger.

Experiment, Inspect, Adapt

The next step is run experiments. At every level, you need to be transparent and openly share experiments at the early stage, and last but not least be ready to adapt through feedback. The downside is that before you learn how to collaborate and pass a test that you have the same understanding of the vision, it’s going to be very inefficient, and frustrating. “If we can just do it our way”, “they don’t understand it”, and “we know what to do so why shall we ask for feedback” people often say. But if you are strong enough and sustain the need for shortcut pre-baked solutions, very soon you see the results in higher collaboration, better understanding and some kind of harmony, which all over results in a high-performing environment.

Together with that, you need to run regular retrospectives and be transparent about the action steps. Share the backlog internally and externally. Simply there is no or very few information which needs to be hidden. If you believe you find any, try to double-check it by playing the “Five Why” and make sure you have a plan on what needs to be done so you can make it fully transparent.

Be Inclusive

The last necessary step on the radical transparency journey is to be inclusive. There is no such thing as a closed meeting. They shall be publicly visible with an open invitation so people can join if they are interested and have something to say. If there are many people, the facilitator can use some diverge and merge facilitation techniques, but no restriction shall be applied for the sake of efficiency.

It’s not about being fast without alignment, it’s about building alignment so you can be even faster.

Radical transparency is hard. You first need to have the courage to say things how they are, don’t be afraid to hear difficult feedback, have trust people will help you, and be ready to help others because after all, you all have the same vision, the same evolutionary purpose to achieve. It’s not easy but is a great investment and it will pay back in forming a highly adaptive (agile) high-performing organizations – the organizations which are formed to crack the challenges of the nowadays complex world.