Collaborative Environment

Speaking of creating the right environment – even in the agile world you sometimes need to make a decision. While that’s not surprising to most managers, it’s often something that agile coaches struggle with. On the other hand, managers often struggle to collaborate and participate, while agile coaches are usually much better at it. All over in an agile environment, you need them both. Decision-making and collaboration.

Agile Leader Wheel

Decision-making is not that hard once you have a clear purpose of what you like to achieve. But without a clear vision, there are so many options to choose from and the nature of the complex world makes many of them looking good, they all are ok, but it’s impossible to know which one of the right ones, without trying, inspecting, and adapting. And again, the ability to hear feedback and learn from it is critically needed. As in a VUCA world we can’t know which option is the right one, all we can do about it is to experiment and learn from failures. Fail fast, learn fast. There are environments where people react well to what I’ve just said. They understand that it’s better to know you are not going in the right direction sooner than later, they work in short iterations, experiments and get open and honest feedback regularly. They know it’s better to return after a week than when the entire delivery is done in a year from now. Those environments are already agile, they have high trust and are neither afraid of transparency nor failure.

But there are environments where people react with frustration on my sentence. “What do you mean by failing?” they ask. “We can’t fail here!” they say and you can sense the fear and stress growing in the space. “We would be fired if we fail.”.  And I’m not surprised. They are living in a different mindset, where they still believe the world is predictable and the business problems can be analyzed, planned, and solutions delivered accordingly. They try to pretend that unpredictability doesn’t exist and that the world is not complex. Just analyze, plan, and do it. That’s it. And all the difficulty is in how to manage it. That’s a traditional mindset and if you like to change it, and increase the agility in a space, you need to start with increasing trust and transparency. Without it there is no real collaboration happening.

In collaborative environments, there are two soft skills needed – coaching and facilitation. You might never be as good at them as professional coaches and professional facilitators are, but be able to use them and help people to raise their awareness about the situation and have an effective conversation and collaborate better is always useful.

Finally agile is a change. Change of the way of working, change of culture and mindset. You can address it at three different levels – changing yourself, through your own behaviors and habits. Becoming a role model. In my mind, this is the most powerful change. Leaders need to change first, the organization will follow. Secondly, you can change the way we work by implementing different frameworks and practices. Thirdly, you can influence the organization and the system level and change the culture and social system.

Agile Journey

Agile is a journey. In the beginning, people think it’s about different tools, new processes, new names. They keep comparing it to what they know and they are frustrated that the new way of working doesn’t fit the world they know. They still try to analyze, plan, estimate, and track delivery. The problem with that is that they are changing to agile not because there is a new improved method, but because their current way of working is not as successful as it used to be. There is a strong need for significant change. The traditional way of working was effective in solving predictable problems, not in dealing with complexity. In the current world, organizations need to be more flexible, innovative, and creative to address VUCA challenges. Agile brings new paradigms, a new mindset, a new way of working. It’s not comparable anyhow to the traditional ways of managing and delivering work.

Once they pass the initial phase, stop comparing and start looking for understanding, people often fall into a trap of taking all agile as a ‘religion’. Just follow the process, implement tools, do scrum according to the Scrum Guide! This phase is not much fun either. But they are on a journey, not fighting with any strong resistance anymore, and deepening their knowledge about various practices. People are interested, they want to understand it, do it well, however they are usually asking fundamentally wrong questions, looking for the best practices, believing they can copy & paste practices.

When they experiment, fail, and learn from failures enough, they start realizing the real agility, which is not in practices and tools, but in a different culture, mindset, and approach to things. They start realizing the organization and leadership need to change in order to finish the transformation and allow the agility to be successful. Agile becomes the way you not only organize the work but the way you live. It will bring different values and different perspectives.

 

Top 5 Books You Have To Read Building Agile Organization

People are always asking me what to read. I created the three lists recommending books ScrumMasters shall read, books Product Owners shall read, and books agile leaders shall read. And recently I got some great books from my friends, so I thought I will write one update page referring to them. This list is intended to help people on their agile journey who want to deepen their understanding of what Agile organizations are about and how leadership needs to change.

top 5 books Agile organization

#1: Johanna Rothman – Modern Management Made Easy

The first recommendation is a trilogy Modern Management Made Easy from Johanna Rothman. The books are full of stories and practical examples. Here are few quotes from the three books so you can choose which one is the most interesting for you.

1. Practical Ways to Manage Yourself is focusing on you as a leader. Modern management requires we first manage ourselves—and that might be the most challenging part of management.

“When we exercise our personal integrity, it’s true, we might lose our job or a specific role. However, even I have never immediately lost a job. Very few managers lose their jobs if they say, ‘No,’ to a management request that lacks integrity.”

2. Practical Ways to Lead and Serve (Manage) Others is looking on how to work with other people. Great managers create an environment where people can do their best work.

“Many first-line managers see themselves as the expert, as the sole source of knowledge for their group. You may have started as the expert. However, as soon as you become a manager, start moving out of that expert’s seat. You can’t be the expert for the team.”

3. and finally the Practical Ways to Lead an Innovative Organization are looking at organization as a whole. Learn to create an environment where people can innovate.

“Great managers solve culture problems. And, culture problems are big, messy, systemic problems. You’ll address something over here and something over there will break. You’ll never run out of problems to solve. Maintaining a culture of integrity might be the most challenging job a manager can do.”

All over, the three books bring a nice overview of modern management practices, are easy to read, and give practical examples of how to change your leadership style. Each book covers several myths which help you to reflect on your current practices and change the way you work.

#2: Michael Spayd, Michele Madore – Agile Transformation

Another book I recently got is Agile Transformation: Using the Integral Agile Transformation Framework™ to Think and Lead Differently. It’s looking at agile transformation

“Becoming a transformational leader challenges us to make room for our own deep passion for change, coming up against the personal limitations in us that prevent this change from occurring through us.”

In the world we live in, which is complex and unpredictable, we need to re-think how we are thinking about organizations, leadership, and transformation. How can you work with other leaders, what kind of leadership is required to successfully lead transformational change, and what is realistically required for agile transformation?

#3: Zuzi Sochova – Agile Leader

The third on the recommendation list is my new book The Agile Leader: Leveraging the Power of Influence. It continues where the Great ScrumMaster book finished and is focusing on how to change the organizations and leadership in the agile space. It 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.

“Having a critical mass of agile leaders is the key factor to organizational success in the VUCA world. Supporting agile leadership and growing agile leaders is one of the most important tasks on your agile journey.”

#4: Heidi Helfand – Dynamic Reteaming

The fourth recommended book is looking at evolutions of teams. Dynamic Reteaming: The Art and Wisdom of Changing Teams got recently it’s second edition and it’s a great book for all people interested in the team dynamic.

“Whether you like it or not, your teams are going to change. People will join your team and people will leave your team. You can grow your organization with dynamic reteaming in mind so that you have a resilient and flexible structure, or you can adjust your existing organizations to enable dynamic reteaming.”

#5: 97 Things Every Scrum Practitioner Should Know: Collective Wisdom from the Experts

Finally, there is a fifth recommendation for a very interesting book collected and edited by Gunther Verheyen. This book is a collection of short essays from 97 thought leaders (97 Things Every Scrum Practitioner Should Know: Collective Wisdom from the Experts) who share their insights from their agile journey about transformation, product value delivery, collaboration, people, development practices, ScrumMastery, organizational design, and Scrum.

“Bring the agile values to the organizational level. Address the system in its whole complexity and turn it into a self-organizing network of great teams. At this stage, you can see your organization as a living organism. Being a ScrumMaster is a never-ending journey. The #ScrumMasterWay concept can guide them.”

Emergent Leadership

Agile organizations are collaborative, creative, and adaptive networks. They are like living organisms, operating on different principles. They naturally flatten the hierarchical structure, making the Org chart quite unimportant. They are based on autonomy, self-organization, and empowerment, leveraging the power of self-organization and instead of hierarchical leadership, they rely on emergent leadership which is not tight to any position but can emerge from different situations and needs on the fly. In Agile organization everyone is a leader. Everyone can take a step and take over an initiative. If that initiative gains the interest of others, they form a team and support it. The radical transparency takes care of feedback and corrects any ideas which are not supporting the overall purpose we are all trying to achieve.

And here is the reason why traditional organizations are generally afraid of loosening the fixed positional power structures and giving teams autonomy. They are often scared of emergent leadership and I’m not surprised by that. In order to make it work you need to have a collaborative culture with high trust, transparency and safety, and strong evolutionary purpose which creates alignment among different parts of your organization so they are heading towards the same direction. Without a clear purpose, everything might look like a good idea worth of trying and higher autonomy usually only creates chaos, while strong purpose helps people to test their ideas by asking a simple question “If we do that, how does it going to help to get closer to the desired state defined by the purpose?” and if it doesn’t we don’t do it and figure out something else which will help us to get there. Radical transparency will allow any initiative to be tested by the crowd and filter weak ideas already before they start. The safe to fail environment encourages people to take over the responsibility and come up with their own ideas. Finally, the collaborative environment will support good ideas. In an agile organization, nothing is fixed. Sometimes I came up with an idea and others form a team around it, next time I join the initiative as a team member. Leadership is emergent and structure liquid.

Now, do you need it? That’s up to you to decide. It all depends on the overall business environment and the challenges you need to work on. Are they predictable and repetitive? A fixed structure will help you to be faster. Are they unpredictable and hard to plan? Are you regularly facing the VUCA (volatility, uncertainty, complexity, and ambiguity) challenges? Then more flexible structures with emergent leadership will be necessary to crack the challenges and be successful in nowadays constantly changing world.

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.

Scaling Success

Companies are not scaling Agile or Scrum, they are scaling success. At our agile journey, we were often wondering how to start, what practices, tools, and processes shall we use. What I learned on my journey is that we don’t need another method. None of these are silver bullets anyway. They are all great for the beginning to change the way you work and to change the mindset. But the most important part of your journey is success. Can you share a success story? Using your own language, describing how your own environment changed, showing the impact the different ways of working created? If yes, people start picking up and trying to achieve a similar impact. The most successful agile transformations I’ve seen started exactly like it. With a small team experimenting with practices, and sharing the impact with others and depending on the starting point, sharing the various different success stories, i.e. 5 times less bugs reported by customers, 3 times more value delivered by the given time (which is not the same as more functionality but quite the opposite), significantly faster time to market, higher motivation and engagement score, more innovations which result in higher customer satisfaction, … the impact varies depending on the environment. For us a few years back it was higher flexibility, faster learning, and higher customer satisfaction.

Sharing success is not anything new in change management. It’s one of the Eight steps for successful change by John Kotter which for some reason are still not widely known in an agile community, so I thought I remind you about them here:

  1. Create a sense of urgency – 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, or Kanban is your goal. They are just ‘walking sticks’ helping you on your journey to success. You need to have a higher purpose defined which will be stronger than their individual goals and therefore unify people.
  2. Build a guiding coalition – You can never change the organization alone. You need to find supporters (agile enthusiasts in this case) who will create a team that will help you change the system. So, at the minimum two additional people who are true agile believers, as three are the smallest team possible. The rest will join you in seeing the results.
  3. Form a strategic vision & initiatives – Sometimes having a purpose is not enough as people don’t see a way how to get there and the whole change is too abstract. That’s a space where frameworks, methods, and practices are useful.
  4. Enlist a volunteer army – Finally, it’s a time to make it bigger. Make it a movement, not just another project. Get buy-in from larger crowds. Get them involved. Again, if you skip some of the previous steps, there is no way it’s going to scale.
  5. Enable action by removing barriers – Now, once you have the energy by your side, you need to help it and remove barriers (hierarchy, silos, detailed positions, individual KPIs, … ), otherwise, all the initial enthusiasm is gone before you realize it.
  6. Generate short-term wins – Show the success early and often, make it visible to everyone. Share stories talk about improvements, celebrate even small steps. Success is a strong engine for change. Accelerate, multiply success. Without it, any change will die.
  7. Sustain acceleration – You can celebrate, but you can’t stop pushing after the first win, being too satisfied with your progress. There is always a better way. Find another challenge, discover a better way of working until the vision of the new way of working defined by the original purpose becomes true.
  8. Institute change – Finally by creating connections between the new way of working and success you keep the change stick. It’s the final glue that prevents the environment from flowing back to the old way of working again.

Agile is a change, and without driving it as a change you can hardly be successful. So don’t forget the define how success looks like, celebrate it, and make it better over time.

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.

Autonomy

Autonomy is a topic that is in my mind for a while. How come that in some environments it’s so simple to let it grow and some others are so much struggling with it. The more I think about it, the more I feel it’s about trust or fear of losing position, power, or comfort. And environments with no trust are not places where agile is much successful. In order to allow autonomy in even a small group as a development team, the trust must be there. I’ve seen the companies which were struggling to allow teams to choose their own name. “What if they choose something offending?” Like really? Now if you deal with such low trust, there is no way Scrum can work. I’ve seen organizations where they track when people are in the office and have so many restrictions that their computers become useless. “What if they don’t work and play games? Or not coming to work?” Isn’t that funny? The more restrictions you create, the more time people spend on breaking them or the more demotivated they are. Neither will help you to create successful products.

“Trust is prerequisite, transparency enabler, and purpose of the driving force for autonomy.”

Building trust takes time. Start small, don’t be afraid to be vulnerable. Ask yourself what is the worth thing which can happen. Ask what are those people around you scared  and how can you help them to feel more confident. The second ingredient in the mix is transparency. Being transparent about what needs to be done, what the success looks like, and what are the things we want to avoid is crucial. People learn by doing. Be transparent with the feedback. Perfection is not useful, it’s all about learning from small failures. Finally, the third ingredient in the mix is a purpose. Autonomy without a purpose only creates chaos. The higher the autonomy, the stronger the purpose needs to be to glue it together. To give everyone the same goal, belonging, identity, the reason for why they are there.

Imagine a kid’s camp. The Red group is defending the castle, the Blues are trying the take it over. Kids are naturally forming small autonomous teams, making their own decisions on the fly. They share information as they move forward. They don’t need any detailed instructions, any KPIs, any manager to give them process. All they have is a strong purpose. Your organization is not any different. Trust is a prerequisite, transparency enabler, and purpose of the driving force for autonomy. Building such an environment requires a portion of agile leadership.

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.

Employee Engagement

Most of the organizations are doing some employee engagement survey nowadays. Mostly they do it on yearly basis, then it usually takes a few weeks to generate results, so then when they finally communicate the results, no one remembers the situation when they responded anymore, talk about aggregated results and then forget them for the rest of the year. Next year they compare them with the previous year, talk about it for a while and let it go for the rest of the year, and so on. Employees complain it takes so much time to answer that many questions and there is no value in doing so. Not surprising, and not much agile either, right. But how many organizations have agile HR? Not many. So let’s change that. Agile is about regular cycles, fast feedback loops, and continuous improvement. If you apply those principles to the Employee engagement survey, you realize that you may not ask 25 questions every year at the same period of the time, but instead, how about if we run employee engagement in sprints and every week or two ask one question. It cost almost no time to answer that, and you can make the results automatically transparent to everyone right away. They are actual and visible to everyone immediately. Then every now and then, when there is a theme emerging from the results ask the people who care about improving it for input on how can we get better as an organization. Openspace is a great tool to address such challenges, smaller sessions can be organized as world café. Communities are formed on the fly to help organizations address the challenges and come up with ideas on how to change the system, environment, and the way we work. Straightforward and simple.

If you are looking into more theory about Employee engagement the Business Agility Institute brought together a group of researchers to examine general steps and programs that may help boost engagement, present an overview of the many drivers that can impact engagement, and discuss techniques to develop engagement strategies. We’ve shared the highlights below. Read more about Employee Engagement https://businessagility.institute/learn/whitepaper-employee-engagement/.