collaboration - Agile and Scrum Blog

Facilitation is Key to the Success of Agile

When I started my agile journey, I didn’t know much about facilitation. I thought it was something we didn’t need, I thought that it was enough to tell people what to do and they would do it. But the more I worked in different environments I realized that forming a well-functioning team or creating an effective workshop, which is engaging and allows people to collaborate, brainstorm different ideas without being judgmental, and create innovative ideas is not that simple. I realized that being a facilitator is a true art and started to read about facilitation and practice different tools and techniques. And there are so many of them… you need to know which tools and techniques you can use to expand the conversation and come up with new ideas. You need to know which techniques you need to use to narrow it down and get closer to creating an agreement. You also need to know some tools and techniques to bring back the energy or help people feel aligned and engaged.

But at the end of the day, I realized that being a facilitator is not about tools and techniques, those are a good starting point, don’t take me wrong, but it’s about being able to read the space, being able to feel the energy, and being able to work with emotions. Notice what is going on in the system. Realize what they need and make sure they are ready to move on.

The hardest on my facilitation journey was not to learn the tools and create a plan for a workshop, but to be ready to throw it away and completely change my plan when the people need it. It’s like a dance. You need to know your steps, feel the music, and move in the rhythm, you can plan to make a big circle around the hall, but eventually, you need to dance at the moment. Be flexible and react to the environment.

In the traditional world we didn’t collaborate that much, we distributed the tasks and worked individually. In agile, we need to collaborate as a team to get creative and innovative ideas. To solve complex problems. We also need to collaborate with our customers. We refine the backlog together. All such collaborations need facilitation, to create a healthy, energizing, and creative environment. Collaboration looks simple but needs a bit of practice. Great facilitators will help you create better outcomes.

Are you interested in becoming a better facilitator? Join our agile facilitation workshop and practice facilitation on scenarios from an agile environment.

Reinventing Collaboration

The recent shift to the virtual space and home office created a more convenient work-life balance but created very new challenges as well. How to grow talents, how to collaborate, and how to build relationships.

In many cases, people simply went back to individual work. In many organizations, the only time where they see each other is some sort of Standup that looks more like a status meeting where individuals who have their own tasks, share their progress with anyone who is interested which is usually close to no one as the don’t collaborate and don’t have the shared ownership.

Such Standup is kind of an energy killing boring micromanaging practice. So maybe you should kill it as well and give people more time to work on their individual tasks. And when I said the only time ‘they see each other’ I was not that accurate either as in many organizations people are not using their cameras. Now what remains from being agile in such environments? Not much.

Another challenge we are facing is how to grow talents in such an individual culture where people don’t see each other and don’t build relationships with either their colleagues or their customers and stakeholders.

People often ask me about this principle of the Agile manifesto, implying that agile cannot be used in a virtual, geographically distributed world.

“The most efficient and effective method of

conveying information to and within a development

team is face-to-face conversation.”

But why not? It doesn’t say co-located, it says face-to-face or as we call it now video-to-video. So that’s not an issue. Technology is not an issue either as Zoom for example can create a team space where people can connect during the day and collaborate, discuss, share, and help each other. Similarly to the office space where they were in the same (physical) space and collaborate, they are now in the same (virtual) space and collaborate. It’s even easier as they can share screen, move to the breakout room, talk to each other if needed, and leave for lunch and come back after.

I guess the biggest issue is not where you are located but if you are willing to collaborate. Is there a need for teamwork, or is the nature of the business simple enough so they can distribute the work and work individually. If the nature of your work is complex, collaboration in the virtual world is perfectly possible. If you choose to work individually, don’t pretend you are doing Scrum as team collaboration is one of the cornerstones and the only thing that can emerge from that would be a “Dark Scrum”, and that’s neither fun nor functional.

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.

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.

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

Agile Board of Directors

Are you also wondering why you shall be Agile and your board of directors and the executive team is not? I wrote about Agile at the executive team last time, now it’s time to have a look at the board of directors.

There is no real reason why the board of directors should not act as an Agile team. Just the habit as most of the directors of the board are coming from the traditional companies and had never experienced it. The governance is important, but the usual committee structure presenting a report to the board each quarter doesn’t help them to react to challenges. I did this presentation at several different organizations, and I thought it might be useful to summarize the key points here as well.

Let’s start with an overview of what any Agile entity needs: Have Agile values of transparency, trust, respect, collaboration, and a shared understanding of a purpose so people are having the same goals. Simply be a great team, not just a group of individuals. But applying radical transparency, get feedback and collaborate is often very hard at this level. Not that it would not be useful, but it’s not going to be easy. Secondly, the board must be consistent with the organization. If Agile stops at the board level, it creates a gap within the organization and governance inconsistency and the whole organization will struggle. Finally, Agile boards are not just governance bodies, Agile boards of directors create a purpose-driven organizations, the sense of belonging which skyrockets organizations success. Having said so, it’s critical that Agile boards collaborate on the key strategic initiatives with the rest of the organization, which if you think about it is very far from filtering anything in and out of the board through the CEO. There are three principles of the Agile board of directors:

#1 Team over individuals and hierarchy

While traditional organizations are formed by stable departments and individuals, Agile organizations form communities build around the purpose. Internally there is usually a quite liquid structure to keep adaptivity and strategy focus in the nowadays complex world. It embraces the team as the key building unit and forms a collaborative network of teams. Similarly, the board of directors is a team which has one goal, even if internally there is a structure of the committees, each committee is a collaborative team as well where all the committee chairs and the board chair are acting more like facilitators then managers of the group. The board as a team is just a small part of the whole picture. We use the ‘team in the team’ concept in Scrum having a Development team being part of the Scrum team, being part of the product team once you scale, and such product teams being part of the entire organization which acts as a team or collaborative network if you wish, where all those pieces only stay together with a strong purpose which creates a common goal for everyone. The same way the board shall form a collaborative team with CEO, the BoD together with the CEO shall form a team structure with management and eventually the entire organization. Too much hierarchy kills the collaborative mindset and a team spirit. There is always going to be some hierarchy in the organization, but maybe the way of work may not be driven by the hierarchy – but the purpose, collaboration, having the radical transparency as a pre-requisite.

#2 Flexibility over fixed plans and budgets

The more are we responsive to changes through the collaboration, the higher need for adaptiveness is in the organization. Agile organizations are moving from year fixed budgets into the Beyond Budgeting principles. Valuing the purpose driven continuous planning over annual top-down fixed goals and plans. You will see more voluntary based virtual teams over fixed departments or speaking about the board the committees. People are groping around the common cause instead of the fixed plan while the planning is a continuous inclusive process instead of a top-down annual event. Anyone shall be invited to join when they have something to add to the purpose of the event. Keep it transparent, inclusive, open. All that is an iterative process with regular feedback and an opportunity to inspect and adapt.

#3 Strategy over operational

The good board shall be focused 80% on strategy and significant business issues, 20% reporting. Nothing new, right? It’s the same old 80/20 rule which we often used in the Agile product ownership, organization in general or economy. The Agile boards are going through significant shift refocusing into strategic over operational. Don’t take me wrong, the governance is important. The same as the importance of the processes in the Agile Manifesto: “While there is value in the items on the right, we value the items on the left more”. The same applies here. Reporting is part of the transparency. It shall almost not be even needed if the transparency is there as everyone can just see it. The board doesn’t have to meet to get a status. They shall meet to discuss, understand each other, have creative conversations, visionary sessions, give feedback. The boards shall meet frequently every 1-2 months (that’s their Sprint time), and focus on a communication and work between meetings. There is no need for reporting, all the documents shall be visible so you save a meeting for conversations about the direction. Similarly to the product environment, the shorter Sprints ends up with better understanding, feedback, and higher delivered value.

Finally, keep in mind that the less fixed is the structure and the plan, there is a higher need for a good facilitation, as without it you might end up in the chaos.

Contracts in Agile and Scrum

One of the very common questions I got at my trainings is how to do agile contracts. In a traditional world where there is neither trust nor collaboration, the contract is the key. It must be detailed enough so we can defend ourselves or blame the other party. Agile is trying to change this contract game, heal the relationship and build a partnership.

In the agile world with high trust and transparency, I believe the traditional contracts shall be abandoned. They are not needed anymore. In my business, we exchange a couple of emails, have a call or scribe a few notes in a Google Doc to make sure we understand each other and collaborate. We treat each other as partners and share with high transparency and honesty that needs to be shared. On contrary, the more organizations spent effort with me on writing a formal contract, the less likely we did any business together. Not because I would make it difficult and argue with lawyers, I usually signed, but I guess they didn’t have the primary focus on the business.

On the other hand, Agile is not preventing you from using any contract at all, so everything starting from

“Fixed time, cost, and scope & you pay fee if you don’t deliver it this way”

“We want to work together as partners, help each other, be honest and transparent.”

can work. Though some contract will distract you from delivering value and other will help you with that. It’s always your choice. You can keep the status quo and contracts or change the mindset of not only yourself but your customer (including lawyers).

For some bigger software deliveries, we did frame contract with NDA, a general link to the way of working and tools to be used (Continuous Integration, Backlog management, etc.). Such contract pretty much said we keep certain standards. And that we collaborate to identify and deliver scope. Any details, content, and problems were discussed at the time they emerged.

In summary, my recommendation is to spend your valuable time on building relationship and partnership. Increase transparency, understand each other, collaborate. If you still feel you need to read more, read Agile Contract Primer or join Agile Prague 2018 Conference.