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.

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”

to

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