Thank God it’s Open Friday!

Every other Friday all employees in our company are free to do whatever they think is important. Ever since we started to hold Open Spaces on these days, we make the most of them. It’s how we spread knowledge, solve problems, gather ideas and superseded meetings.

The pace of things seems to ever increase. To stay ahead of the game a company’s ability to learn becomes crucial. Just imagine: What if people in your company shared their knowledge? What if you could gather everyone you needed to discuss a problem without hassle? What if you could try out new technologies easily? What if you replaced drab meetings with high energy sessions?

Sounds intriguing? What would you be willing to invest to reach the above?

We’ve reached it with 10 slack time – for every employee, everyone at the same time. Every other Friday all employees are encouraged to work on whatever they think is important for the company. Additionally we hold an Open Space to match people who need help with people who can support them. So far the results have been spectacular!

Follow us through 4 years from recognizing a problem to arriving at our current setup and learn how the benefits manifest in our everyday work.

sipgate, where we lay our scene, is a small telecommunications company in Düsseldorf, Germany. About 115 employees work in beautiful offices near the Rhine. I like to think that we are quite far in our agile and lean journey. For lack of a better metric suffice it to say that we have 2sqm (= 20sqf) of whiteboard surface per colleague and we use ALL of it. Everybody knows how much money we make with which products. We learn new technology stacks and techniques across teams at an impressive pace. We deploy several× a day. But it hasn’t always been that way.

Join me at the imaginary fire place and I’ll tell you the story of one of the major success factors, the Open Friday.

In the not too distant past, in April 2010, sipgate’s top management decided to adopt Scrum. Back then we were 65 employees, half of which built the actual products (web interfaces, call routing, connections to external APIs, …). We went from the usual waterfall silos to form 5 cross-functional Scrum teams. All Scrum masters served double duty, e.g. I became Scrum master in addition to being a UX expert.

Using Scrum massively accelerated our development cycle. At one time Tim, our CEO, commented: “Before Scrum we had so many feature ideas we never got around to… We thought we needed twice as many developers. Now, with Scrum, we can barely think of enough stories so that all teams have enough work for the sprint.”

Great, eh? We were indeed working much more efficiently than the chaotic way we had been working in before. However, by summer 2011 we noticed some serious problems:

Members of Scrum teams became reluctant to help colleagues outside of their team. Everybody concentrated on the commitment of their own team even if overall company goals suffered. There was no time to reach cross-team consensus on important company-wide matters, even though we all shared the same code base. Knowledge transfer between teams rarely happened. Technical innovation, such as trying out new technologies⊦ implementing new project ideas, had also come to a screeching halt.

Sprint lead onto sprint and everyone felt exhausted. We built products fast butnot sustainable. Some tasks (e.g. maintenance, preparation for upcoming epics, improving the internal helpdesk, …) were never important enough to the POs to bubble up in the backlog for the teams to pull. This bred resentment among the developers and even led to customer-facing problems.

The developers asked the other Scrum masters and me for help. We thought of slack time to mitigate these problems. But wait, isn’t introducing extra time bad and a Scrum smell?

Well, yes. For example we did have a number of systems that accumulated files that regularly needed to be purged by hand. Going by the book we would have had to automate such problems into inexistence.

Given the number of issues and how long it would have taken us to adapt our systems to automatically deal with each of them, we decidednot to delay working on new features for months on end to address all of them but to research slack time instead.

[We fixed the maintenance issues one by one over the years. Today I can think of exactly one area that needs manual fixing at regular intervals.]

We found several descriptions of how other companies handled slack:

• Take a break between sprints. Depending on sprint duration, leave 4h up to 2 days between ending the old sprint and planning the new one
• 6×2 + 1. Mike Cohn described a 1 week break to recuperate and tie loose ends after 6 2eweek sprints
• Developers’ Friday. At Google developers have 1 day per week to work on pet projects
• Gold Cards. For every iteration, each developer gets a token that grants her a day to do whatever she wants
• FedEx-Day. Once per quarter all developers gather for 1 1/2 days to implement cool new stuff

Looking through the approaches we realized we wanted slack time often and shorter rather than rarely and longer, which ruled out FedEx-Day and 6×2+1. We wanted to interfere as little as possible with sprints, which we were afraid Gold Cards might. and we wanted everyone’s slack time to be at the same time, because we often needed larger groups to figure out interconnected issues – a remnant of pre-Scrum×, when there had been a 1:1 relationship between system components and developers. We settled on a one day break between our 2-week sprints for all Scrum teams.

Getting management approval was easy and hard at the same time. It was easy, because they had always been fond of Google’s 20 time approach. They just disliked that people were more⊦ less required to come up with a great side project. We weren’t going to focus on side projects, problem solved. It was hard, because they weren’t convinced everybody would spend their time wisely and in the best interest of the company. The group of Scrum masters and management worked out some rules to help address these concerns. That we did not include the affected people, the Scrum teams, turned out to be a huge mistake. Today it’s obvious to me that it had to tank, but back then the imminent backlash was unexpected.

In July 2011 we Scrum masters presented the rules for a 2 month trial of slack days: The first day of each new sprint would become a developers’ day. Sprints ended on Wednesdays so the slack day was every other Thursday. We called it “NDS”, a completely random name, to keep everyone’s mind as open as possible. Developers could do anything they wanted that was somehow work related: research, maintenance, pet projects, impediment meetings, …

On the NDS days themselves we would meet in a huge circle in the morning. Everybody would say what they were planning to work on so that others might join. People who neither had ideas nor joined others could work on stories as a fallback. In the afternoon we’d repeat the circle to hear about the results. There was cake to celebrate. Additionally we asked developers to track their topics in a spreadsheet as a memo to themselves and for future reference by others.

The slack day was not as well received as we had hoped. Although developers had had expressed their wish for slack time, they felt scrutinized by the opening closing circle and the spreadsheet. They had fine antennae for management’s lurking lack of trust.

While the morning circles were well attended, less took∂ in the closing circles and after an initial morale boost we returned to past morale levels within a few weeks.

All those agile ideals we tried to followed broke down when it came to NDS. What we worked on was anything but transparent. It appeared that many plans were ad-hoc and barely thought out. We started lots of things and rarely finished. People worked alone and suddenly put stuff into production that they hadn’t talked about with anyone.

We tried to address these problems with even more rules. We asked people to phrase their plans as user stories and h and them in a day prior to NDS so that NDS projects would be more thought out. We required pairing so that a topic would be validated by at least two people thinking it was important.

The new rules did not help. NDS stayed non-transparent and the attendees felt even more bossed around. It was clear the day was not all that it could be. Management thought about revoking NDS several× but all things considered it was better than without slack time. It did solve some of our problems, e.g. it allowed for manual maintenance and researching new technologies.

At the time we were a little Scrum and change weary, so for lack of a better idea we kept NDS around. When teams stopped having synchronous sprints it moved to Friday, but it didn’t change substantially.

It took a whole year until Stefan, one of our web developers, came up with something better. He attended a BarCamp in August 2012 and fell in love with the Open Space format. Open Spaces are a way to create an ad-hoc agenda for multiple rooms and time slots, similar to conferences, but more “open”. People can propose “sessions” during the opening ceremony. They write their topic onto a sticky note, briefly introduce it and place the note into a slot on a big bulletin board.

Example: Session Topics on May 8th:

• Fraud Prevention
• Pattern Library Retrospective
• Accounting
• lunch @ sipgate.de
• How to change our communication towards clients
• IPv6 @ sipgate – talk rehearsal
• Git for Beginners
• Porting numbers
• Team phases
• sipgate @ conferences

At the set time and space everybody interested in the topic shows up to discuss it. The session sponsor has to take notes and publish them.

Stefan proposed to run an Open Space on an NDS and thus hosted the first “Open NDS” in October. It lasted half a day and about 20 people (½ of all product team members) took∂. They held many insightful sessions and Open NDS was considered a huge success! Stefan summed it up like this in his wrapeup mail:

“tl;dr: NDS with Open Space was great – we’ll do that again, everybody should come, next time more cake!”

The rest, as they say, is history: We have held an Open Space each and every slack Friday ever since. A product owner renamed it Open Friday by accident and that name stuck. We’ve extended the Open Space by starting at 10 am and still closing at 4 pm. Even though it was official that everyone was encouraged to take∂, people outside the product teams hesitated to join. Today about 2/3 of all employees take part in any given Open Friday. It’s only difficult for customer support. So far we have not found a solution for having to staff the support hotline. That’s why colleagues from customer support take turns to attend.

The session board plays an important role, because it allowed for more than one touchpoint throughout the day. Instead of the NDS morning circle with exactly one choice to team up and nothing written down, the Open Space session board enables us to switch topics and groups several×.

The initiative for Open Friday benefited from raised trust levels between all groups within the company between 2011 and 2012. The session board further elevated this trust with enhanced visibility and transparency. The same applies for documentation: Open Space rules are widely accepted. They call for session documentation. Consequently we have a searchable record of sessions that we can refer to when memory fails us.

Last but not least, the fact that colleagues from all over the company collaborate – marketing, accounting, support, design, developers, sys admins, management – has brought us together to a degree we couldnot have foreseen⊦ planned for.

There are “slow” Open Fridays on which only a h andful of sessions are proposed, inducing a bit of doubt. Maybe we need to try something new? But 14 days later we will bounce right back with a host of interesting topics. At then it feels like magic! Open Fridays have an extremely high energy level that NDS lacked.

Open Friday solved all of our original 2011 problems to an extent NDS did not.

On top of that it facilitates help across teams and departments. We hardly have meetings anymore. Most issues become Open Friday sessions. They are much easier to set up: It’s exceedingly easy to find a date when everybody has time. And it’s exceedingly easy to find out who wants to come to a “meeting”. As attendance is 100 voluntary, sessions consist solely of people who want to be there and are actively interested in the topic. How energizing!

Open Friday is our primary means to transfer knowledge, innovate and research new technology. It’s given us a bias for action, because it allows us to act on what we think would be great rightaway. We’ve got a way to rally others to support our initiative. In unclear situations we can reach consensus and take decisions.

Because all employees take part, information between departments flow easily and empathy abounds. When one of us has got a problem, the solution is just one Open Friday away.

As an additional perk, proposing a session gives everybody a chance to practice leadership behaviors such as speaking out in front of a crowd, moderating a discussion and popularizing a topic.

Oh, and have I mentioned fun? No? So fun. We have it! Lots of it 🙂

It pays off to have a time during which everyone e not only Scrum team members e is available. Open Space helps us make the most of this time by matching interesting topics to interested people. Open Friday gives everybody opportunity to bring their ideas and initiative to fruition.

Thank you, my colleagues at sipgate, for the privilege of working with you! Thank you, Tim, for enabling us to try out so many different ways to work! Thank you, Stefan, for introducing us to Open Space Technology!

Thank you, Linda Rising, for coaxing this paper into ship shape!

Liz Sedley describes Gold Cards in http://www.agilecoach.co.uk/Articles/Motivation.html

.