This article first originally appeared on December 18, 2015 in the Harvard Business Manager.
When we started building websites professionally in 1996, we were still operating on intuition. Meticulous project planning was foreign to us. The business developed, we grew and quickly reached a point where we began looking for professional processes for developing our projects. We tried several (Gantt-Charts with MS Project and project checklists we developed ourselves), but none had the result we hoped for. For a while, project managers could decide how they wanted to develop their projects.
In 2008, we learned about the Scrum and Kanban methods. We assembled a pilot team that worked on developing a proprietary product tailored to our specifications in accordance with the (few) official Scrum specifications. Even though the pilot team was laughed at by our other software development teams (“You get away with this because you are working on an internal project without pressure from customers”), we started talking with employees outside of the software development department about their work. We introduced successive task boards and stand-up meetings which quickly brought first successes. We determined that this was our kind of work and it felt right. And once the pilot team celebrated its first successful customer projects, the other development teams came along bit by bit and thought, "We should give it a try too." Since then, Scrum and Kanban have established themselves as standards for us. As a result, we've been able to successfully complete every project to date.
Today, it is clear to me that the consistent implementation of Scrum led us to realize our company needed to change. The Scrum method includes a retrospective that allows our team to reflect every two weeks on its stumbling blocks and how they can be overcome. This time to reflect quickly resulted in individual teams challenging the purpose of company-wide processes because the organizational framework which //SEIBERT/MEDIA offered the teams was not optimized for this type of work. An example is our central vacation approval system. A person could decide on whether an employee could go on vacation without knowing what was going on in the team. It became clear that we needed to adjust company-wide processes to suit the needs of self-organized teams.
At this point, I realized it made sense for us to work with the employees on these necessary changes. That was the birth of what we now call our “Agile organization" process. Our goal is to continue developing the organizational framework with our staff to create optimal conditions for our autonomous teams. We’ve already come quite a way. Examples include the creation of individual objective agreements, the introduction of mentor teams for each employee (instead of traditional supervisors), the harmonization and increase of vacation days and a shared vision linking us all which is supported by all.
If we talk about the impact of Scrum, we must also address the following point: Scrum is not just a project management tool. It also has a set of new values that changed my view on collaboration altogether. The following are Scrum values: commitment (a development team commits itself to delivering a functional product in the agreed quantity), focus (concentration on the things currently important), openness (transparency towards the client), respect (mutual relationships on equal footing) and courage (trying new things and learning from failure).
At //SEIBERT/MEDIA, we consider two of these values particularly important: transparency and openness. For some time, we have provided complete and open access to our company wiki and discuss current issues openly with each other in our internal microblog.
I am satisfied with our self-organized teams. For me, that is one of the success factors ensuring our company does not become an immovable behemoth. Instead, we use the hive intelligence of all our employees to develop products and services based on market demands. The internet market is a dynamic environment whose future is unknown. This is why internet companies must show a willingness to change and adapt. Simply put, they must be agile. And this requires the pooled knowledge of our entire staff and agile organization.
But how do you establish self-organization?
This is a question that management typically asks. We were lucky in that we already preached and practiced flat hierarchies as a young company. There was never an organizational chart that made managers worry about their position and status. Nevertheless, as the CEOs of //SEIBERT/MEDIA, my brother and I had to ponder our managing style. Simply bowing out ("You'll figure it out!") doesn’t work. Authoritarian leadership doesn’t allow self-organization in the first place, and a laissez-faire attitude leaves employees feeling uncertain about decisions. We had situations where employees asked for help, but we left them to their own devices. The better response would have been, "How can we help you make a decision on your own?” Or more simply, "What do you need?”
Our path is one of cooperative management. Still, there will always be decisions which I want to or even must make. If this isn’t clear to employees and they "simply make" decisions, they might get shocked by an invisible electric fence so to speak. That is poison for self-organization. If this happens, they will no longer be sure of themselves when it comes to deciding the next time around and risk running afoul. At this point, Jurgen Appelo (consultant from the delegation board) helped us realize this and showed our employees the guide rails for their actions. What can I do alone, what should I disclose, when do we decide together, when should others question me, and what do I just have to accept? The delegation board describes the decision areas relevant to us.
At //SEIBERT/MEDIA, we experience the volatility of internet business a lot these days. We used to promote ourselves as an internet service provider with all-around worry-free services and satisfaction guaranteed. Now, we have to establish ourselves as the go-to experts for special use cases and offer solutions that meet customer requirements. For us, those solutions are intranets, wiki and task management systems and agile software development. However, this also means I really have to understand the market to put companies on the right track. The peach model propagated by visionary and author Niels Pfläging helps us immensely in this process. We now ask our team the right questions: What solution do you offer the market? What kind of support do you need for that? And that applies to all our employees because internal teams like accounting and marketing are the core of the peach model who look at the teams on the market as their customers.
In this discussion, we determined that we need a common vision: Why does //SEIBERT/MEDIA exist? How do we want to improve the world? Where we previously just "did everything the customer wanted," the answers to these questions helped us to establish a core focus and design our solutions for the market.
"That certainly sounds like paradise," I once heard an audience member say at a conference after our presentation on our agile organization. In reality, work at //SEIBERT/MEDIA is not easy and sometimes couldn’t be further from paradise. Of course, it is important to us that our employees feel happy. At the same time, our kind of business management also means that every conflict inevitably surfaces. After discussing conflicts, we can work on solving them. I am convinced other companies face these same challenges but do not properly address them due to an authoritarian management style and lack of transparency.
I see this work as an investment in our company culture of togetherness. I believe it will pay off in the long run and make us a more robust company that can thrive in this complex environment for many years to come.
In Deutsch lesen.
Additional Information
Agile organization at //SEIBERT/MEDIA: from brainstorming to realization
Budget planning in Scrum projects and possible reactions to cost explosions
