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?