Many new hires for a position with high visibility believe it is necessary to set a footprint right in the beginning. Reasons are: Expectation are high on the new hire, changes are welcome and expected – better yesterday then tomorrow. This results often in fast and wrong actions just to demonstrate power and deliver results – whatever the value of these results may be.
I decided to act differently. I took my time to walk through the departments, to talk CEO, heads and employees. I listened carefully to what my team is working on. I even worked some days in some departments, for example packing goods in the logistic or entering product date in product management. I am a strong believer that you have to understand the system, the processes and especially the persons working here and there before you start dancing with the system.
What I discovered was:
- Software development (called Engineering) is working Scrum alike. Some practices might be not that good as it could be (there is always room for improvement), but all the teams are living an overall healthy agile process based on one shared product backlog.
- The interface between software development and the functional departments is – hmmm – suboptimal. Very obvious the reason is the very hard migration phase where engineering, especially the business analysts in the engineering, set the pace. Departments felt somehow overruled by business analysts and business analyst felt left alone by everybody. A typical scenario in many companies.
- Digitec Galaxus owns a real mission, vision and a clear strategy. It is short, easy to understand with clear and understandable goals. That was really surprising. Only a few companies I had the chance to work with own these essential communication elements on that level of maturity.
- Digitec Galaxus is working in a good, pragmatic and collaborative style and culture, tool supported on an Atlassian Confluence and Jira infrastructure. There are only very few documents on a shard folders. PowerPoint is treated a poisoning.
- A huge potential exists for innovative features, enhancements, potential improvements, and optimizations of suboptimal implementations of business processes. Problem is: There is no shared agreement of what is important and what to do next.
- With this I found a wild mixture of about 1200 open Jira issues of all different kind and sizes accumulated over the last eight months. Some of the issues are bugs, some enhancements, some are tiny things, and some are essential and large ideas. Some are firefighting rescue things to survive today, some are real innovations for our customers in the future. The huge number of items is a challenge for prioritization or comparison. That is success and malediction of open collaboration. Things get accumulated and then it is hard to find a way through the jungle.
- A first rough idea of a portfolio management Kanban system exists called innovation board. The idea of the innovation board is to list strategic projects.
- A first ideas of an innovation process exists (not to puzzle with the innovation board) that shall enable the functional departments to announce, prioritize and enroll improvements ideas. These improvement ideas shall end up as either local projects or as strategic projects in the innovation board – or as small change requests that can be realized fast and flexible.
Listening to my boss Florian (one of the Co-CEO’s) and all the other people I talked with, I received a strong request to build up a system that supports prioritization, focusing on the important things. A system with built-in flexibility that supports a fast growing company with more and more individuals working for a shared vision, the vision of Digitec Galaxus.
This information base was a good fundament to start. I reminded myself on Deming, Kaizen and Jurgen Appelo. I decided to start where we are and to improve step by step with fast feedback following plan-do-check-act circles. I designed my personal change backlog for my responsibility at Digitec Galaxus as following:
- (story): As the head of Business Development (my official position) I want to empower my team so that we develop competence and are a highly motivated team in its responsibility to drive the agile portfolio. Acceptance criteria are trust, self-organization in the team and the motivation to change the organization following a Kaizen approach.
- (story): As CEO of Digitec Galaxus (my boss) I want a transparent, flexible und lightweight system, so that all my teams work on the projects that generate the highest outcome and get things done. Acceptance criteria are that the existing innovation board is improved and changed into a system that supports the executive team in prioritization and implementation of strategic projects; that the innovative slow down caused by the migration is turned into an alive innovation factory again as fast as possible.
- (story) As a department I want to know that innovative ideas based on the customer demand and optimization ideas based on internal productivity demands do have a chance to get realized in some way and somehow. Acceptance criteria are to work with an easy to apply and transparent system where a department can place, develop and realize its ideas; to get fast feedback and support in the realization of ideas; to get the chance that fast, small and urgent changes run fast through the system creating impact as soon as possible.
Reasons I prioritized my change backlog in this order was the strong believe that I cannot succeed without a strong team. My team and my department was setup totally new as result of a re-organization including three new hires (included myself) and one trainee. Some of the ideas around the Kanban portfolio process and an innovation process are concepts of team members in my team. My team matters. My team always matters. Yes, I set the strong demand of my boss on second priority. I was convinced – and this proved to be a good decision – that the start phase of my boss’ story might be slower in that way, but sustainability and overall speed are ways better with a strong team driving instead with my person acting as an expert and lonely wolf pushing things forward.
In one of my first weekly’s with Florian (what an opportunity to have the chance for a weekly with the CEO) I challenged this backlog with him. For sure we discussed this and that. We agreed upon and added potential following stories in my backlog. But with a self-defined WIP (work in progress) limit we agreed upon these stories as the most important ones.
What I put aside at that time was the interface between the departments and engineering; the stack overflow of 1200 issues in the Jira engineering backlog. I had the strong feeling that on one hand things will change as soon as learned more about us and invisible things get visible and on the other hand that I need to know more about us before we start to experiment in this area.
So my first plan-do-check-act circle was ready to start.