Friday morning, May 18th 2018, time for our biweekly team meeting! The entire Organize Agile team is standing in front of our development portfolio board. I enthusiastically share I have been working on our Agile HR convention with Àpun, our marketing specialist. Mikel asks for help in preparing a proposal for a new client. In no time at all we get caught up in a discussion about our leads process and start to lose focus. We are sharing some great ideas, but at the same time the energy level drops and frustrations are rising.
In the previous six months we have worked really hard. By coaching our clients we have helped them to liberate themselves from old-fashioned command and control structures. We have helped organizations deliver more customer value more quickly and have helped teams to work together more effectively. Yet at the same time we notice frustration in our own team. Why are our own meetings so sluggish and are we talking so much? Why do we energetically start new things, but struggle to finish them? Why do we suffer from all this when this is exactly what we coach out clients on?
The proverbial Cobbler’s children are going barefoot. Time to get them some shoes.
Part of the problem is that the company is growing. This of course is not a bad problem to have, but is does make it increasingly hard to communicate and cooperate effectively. In other words, we are suffering from our own scaled agile problem.
It is rather ironic to have to admit that we are suffering from the exact same issues our clients are. Fortunately we are all highly motivated to address the problem. Also, because it might enable us to help others more effectively. More and more rapidly growing organizations ask us for help in their quest to become an agile organization. They do not only want do agile, but truly become agile as a person, team, or organization. A common problem in teams is that they simply do not reserve enough time to actually work together.
So what are we doing wrong ourselves? It turns out that as a group of agile coaches we should not facilitate our team simultaneously. We all have an opinion on everything and easily get sidetracked in discussions about how the process should be run. We do not free up enough time to do our own development work, and when we do, often urgent ad-hoc things pop up that we choose to deal with first. On top of this we tend to do our development work in many different small groups, or — if we’re brutally honest — solo. At the same time, we make decisions by consensus, requiring all sorts of superfluous coordination. We all care deeply about our work so we often work evenings and weekends to get everything done. There is real passion for our work, but that is not a healthy situation.
The team mob programming this blog
Much needed repairs
We all agree some major changes are required, but where to start? We decide to take a page out of our own book and start by restructuring the company into stable teams. We self-select into teams taking into account our own personalities, knowledge, skills, and ambitions: excellent! From experience we know that getting the basics right is key. We do our best work when we are co-located, so we decide to physically work together at our offices every week, not an easy task as we spend most of our time with our clients. We decide to prioritize what is important, rather than what is urgent and free up time. At the same time we shorten our cycles by going from a bi-weekly to a weekly team meeting. Working together with the entire team in a single location every Friday allows us to improve communication and produce better results. Focus! We still have limited time (only two hours every Friday) but we spend all of it working together on the same deliverable. During the week we constantly groom, discuss and prioritize our team backlog using Slack and Trello so we can spend our time on Friday working on what is most valuable.
As it turns out it is hard to stick to dedicated development time. Despite the fact that we are all very much aware of the value of focus and prioritizing, we still tend to go with what is urgent, rather than what is important, which is when development time falls by the wayside. We decide development time is sacred, it doesn’t matter what else pops up, development time is always more important.
At first we don’t appoint a team facilitator because we assume a team of agile coaches should be able to self-regulate, but in our team Michiel gradually assumes the role.
Getting shit done
Let’s jump ahead in time a bit. Friday morning January 18th. For the first time in the new year the entire team is complete. After exchanging new year’s wishes and checking in, the stable teams go to work. Each team is free to decide how they do their work. Common denominators are they all have a open and transparant backlog, and we use our portfolio to visualize and coordinate their work. Where we used to fully self regulate, both teams now have a product owner who takes responsibility for the backlog.
The product owner of my team Nienke has prioritized our backlog. Despite the fact that we only have two hours every Friday, our team of five is getting things done by swarming on a single issue. This blog for example, was written as a team co-production in two hours. Including coming up with the concrete idea, writing, adding photos, and putting it live on our website. Our Friday has evolved from a day full of meetings, which we would leave with a to-do list for the weekend, to a productive two hour sprint. The rest of the day is for sharing knowledge , sparring about challenging clients, and yes some vital meetings. Having such a tight time-box ensures we focus and spend our time on what is truly important. We finally get things done every week.
Originally published at www.scrumcompany.nl on January 18, 2019.