Tag: board

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.

Online Scrum Board

I belong to the Agile crowd who believe the physical board is very much useful and can’t be easily substituted for any online board. Let me give you a few reasons.

5 reasons why not to use electronic board

  1. We are *still* limited by the screen inches and no electronic board gives you good overall Sprint visibility.
  2. No electronic card takes pride in your handwriting, so the ownership of the whole board is much closer to “someone else’s problem”.
  3. You can’t touch it, move it, or throw it away. It’s annoying how many fields in the *average* system are required to add a task. It’s a tiresome to crumble tasks to one day activities.
  4. It’s hard to draw on it. There is no creativity. It’s just reporting by definition.
  5. Regardless of the ability to share, usually the ScrumMaster controls the board during Standups. Not any team members.

To make it simple, to organize yourself as a Scrum team you need very good visibility of what is already done, what is in progress and what still needs to be done and who is currently working on which part. As there are no assigned User Stories to any team member, every individual is responsible for finishing Sprint Backlog. To be able to organize your daily work yourself as a team, you might need a flexibility – depending on where you are you might decide to distinguish tasks by colors, next time by shapes, then you start tracking dots per day, and the next time tear the task if it get blocked or anything else. You can start right away, and stop any time it suits you and there is no need to win over your system.

To make it clear, I’m not suggesting now your overall backlog should be at the board even if there are companies who work only this way. However, for this time of being I’ve been focusing on Sprint commitment, and simple tool which helps team to synchronize themselves. So keep your *future* – the User Stories – in the system, keep Sprint tasks and team synchronization be driven by physical board not connected to any system, and then link back any commit or important note back to your User Story in the system so you have a history and traceability.

And yes, I understand that some teams might not be at the same location, and can be spread over the world. So if you have such situation, still you might prefer flexible tool which gives you a good visualization. There is no ideal tool like that, but there is one I learned from some of my distributed teams. You can see the picture of that board below. It’s easy to use, it gives quite good overview as well. And yes, I can come up with hundreds of improvements, but I still like the simplicity of this solution. You can try it here.

Scrum Board