Thursday, April 30, 2015

About energizing people and empowering the team

Maybe you once read the book Management 3.0 by Jurgen Appelo. If not – read it. Especially the chapters of how to energize people and build up motivated teams gave me insights and ideas that helped me in my current situation.  Let’s see and example.

After about two months of working we introduced additional ceremonies to organize our team work based on our daily work that was (intentionally from my side) somewhat ad-hoc organized so far. In this period we all learned what communication we needed within the team and in collaboration with all the other teams we interact at Digitec Galaxus.

My team members were not that happy that I as the boss did not define ceremonies right from the beginning. Becki once gave me the feedback “your listening. That’s good, I like that. But sometime I would like you to decide and define”. That was my experiment in building up the team. My idea and hope was that a certain state of unhappiness fosters the need for change and motivates every team member to think and reflect about improvements. The hard thing is to get the feeling for the right point in time for a change so that creativity for change does not turn into frustration.

By the way, I really like experiments. Experiments are the perfect instrument to develop a complex system – and every system is complex as soon as more than one person is part of the system. Experiments are small changes, tiny measures that are implemented fast. For a certain topic like the improvement of the portfolio process it is good to have a backlog of potential experiments. Then you apply an experiment. As it is small it is implemented fast. You get feedback very fast. Fallback is often possible in case the experiment fails as the change is small and the impact limited. Experiment by experiment you learn about the system and the number of successful experiments increases. Changes are small for all individuals involved and included in these changes. Ideal all individuals in the organization get used to that the system changes continuously. As most experiments succeed, all involved persons perceive change as something that delivers value. 

Well, back to my first experiment in my team. In the meeting itself – we explicitly took team ceremonies as the topic of our BD team meeting retro – the team expected some statements from the boss. Not too bad. I took the chance. But I did not present a solution. Instead I tried to summarize what problems in communication we obviously face and what goals are expected by the organization when introducing our ceremony culture. Additional I presented some alternatives and good practices out of my work experience that succeeded in other companies in similar context. I added some statements about further reading. Then I pleased my team to present their ideas how to organize our team culture.

Luckily my team took as well the chance. Especially Becki and Andi, the long term Digitec Galaxus employees, started to present their view based on their insights and experiences inside our company culture. For sure sharing my experience and ideas biased and influenced. I recognized this carefully. But this is positive. The influence is mutual. We as a team work on a common goal: to identify and agree upon an effective and efficient ceremony culture that satisfies the needs of our organization.
The result was ok, practicable, a good start. It was not the perfect solution. We all knew this. We agreed to start and to improve as soon as we learn more. Meanwhile we changed our team ceremonies by applying about five additional experiments. These improvements often are agreed upon at the end of a meeting. One team member raises its hand and starts: “By the way, I believe we could improve our meeting culture as following…”. Small experiments are agreed upon fast and implemented at once. If we are not able to agree we move the discussion to one of our BD team meetings.

Now, three months after my start I can say that this way of involving the team in all decisions is an essential step of team development. My personal experience and competence out of my professional life is welcome as part of the team and not perceived as “the expert overrules us”. We learned as well – following the delegation model presented in Jurgen Appelo’s book Management 3.0 – what decision are team decision on eye level and what decision are solely on my side as the head of, but still influenced on the important input and shared knowledge of my team.


Now, three months after my start I ran through the yearly performance process with each of my team members. I recognized and honored the open feedback that I got about what is good and what is not so good. But what I value most is that all of my team members agreed that it is fun to work in our team; that they are happy with their job and fully motivated to engage for  Digitec Galaxus. That again motivates me. We are working on a common goal.

Tuesday, April 14, 2015

Building up a team from scratch – the first steps

You enter the room. Five persons are curious looking at you. Two of them long term Digitec Galaxus employees assigned to the new built department called Business Development. Two of them new hires, one an experienced project manager, one a graduate from university. The fifth a trainee that will work for a trainee time of 6 months in my department. I am myself a new hire with only small knowledge about Digitec Galaxus history and culture.

I had been announced as expert in agile, lean, portfolio management. I had been announced as the one who will help to identify and establish the right way to work and define the portfolio and development processes; as the person that will improve the existing home grown agile way of working into something that enables the next step of growth, while preserving the flexible startup spirit of Digitec Galaxus.  I could feel the one and only one question in this room: “who are you and what will it be like to work with you as my new boss?”

Well it was not that easy this first meeting. In a first round we exchanged our expectations and experiences. Becki was asking for leadership and support as she was missing this for quite a while. Andi and Marcel wanted to develop themselves and act in interesting jobs. Martin, the experienced project manager demanded to take responsibility, Cornelia coming from university wanted to learn and start her carrier. We discussed values and identified our common ground. The common ground was trust – which we need to create – an interesting job with the chance to learn and build up competences, no micro management, open communication and self-organization, mutual respect. We discussed that self-organization and self-discipline are the two sides of the same coin. This common ground was a good place to start from. I marked my first task of my first backlog story – to find a good start as head of my new team – with done.

I knew that the hard part follows. To develop the common ground into a living entity, a team that represents, lives and develops the values that we identified as important.

What we did is to write down our team values on cards, one card per value. Becki proposed to select a random card for the value of the day every working day. Now the value of the day is visible in our team space on a wall and still is changes every day. Oh yes, meanwhile we added new cards. Some are fun like “homemade cookies” or “sleep ‘till noon” – even members from other team started to add cards, which is fun.

Our Team Value of the Day for today: a creative environment 



Meanwhile we introduced Kudo Cards (read the management workout from Jurgen Appelo). As most of us love coffee and the others at least drinks tea we started a regular but still spontaneous morning coffee where we share our weekend or discuss the most important issues in our team. We defined a team ceremony, our monthly BD team meeting for our team retrospectives and to define measures to develop ourselves. We found and agreed about some means and informal ceremonies that support us to build up trust and share experiences. I treat all of this as an important steps to form a motivated team. Let's see how everything develops...

Building up a portfolio management Kanban system – step 1

My blog “Herdingants – so many opportunities, where to start?” listed some of the “post migration” main problems Digitec Galaxus currently is facing. The need to prioritize the work aligned to strategic goals but still preserve the agile and flexible way of dealing with changes was given.
The problem of us was that our backlog contains far too many items. I counted over 1200 items on different abstraction and maturity levels, sizes and of different types (bugs, features, ideas, …). The overview got lost and with this the chance to select and prioritize.

Working on a white wall with sticky notes and a technique like story mapping was not establish in our company. So applying Jeff Patton’s story mapping technique for clustering, selecting the important stories, identifying a walking skeleton and getting rid of deprecated stories just was not possible. Working with white walls besides feeding a sprint was unknown at all. Teaching and coaching this is interesting and valuable. Unluckily that takes some time until the teams are enabled to apply this and produce an outcome. I put this technique into my backlog and moved it a bit down. We needed an approach that produced faster outcome.

Well, that sounds like some kind of implementation of an agile framework might fit, addressing the needs of a larger organization. I personally know and expertimented with elements out of the frameworks and approaches 
  1. SAFe by Dean Leffingwell, 
  2. LESS by Craig Larman, 
  3. Evidence-Based Management for Software Organizations (previous called Agility Path). 
  4. DAD by Scott Ambler. 

With the consulting mindset of my previous work the temptation was high to go for one of these framework and to implement it in some adoption following my intentions. I had a grass play area. Well - I decided different.

I reminded myself on the approach: create a vision about a direction to improve and apply a series of small experiments to move towards the vision. First step in this approach is to create a common vision. To do so you first need to know about the different visions that are around in the minds of the different people. I started with a workshop about “agile portfolio management” with a set of involved persons like the team lead for business analysis, the head of engineering, one of the CEO’s and some team members that already work on a first concept of a portfolio management and innovation process.

Of course the attendees of the workshop expected my again to present a ready-to-go solution that fits for us. I started presenting SAFe with the background not to implement SAFe as it is. I used the SAFe picture to present a potential vision and to point at some important mechanisms and techniques relevant for organizing things in an agile way for a larger organization. This started a positive discussion what the requirements and constraints of the different stakeholders in this room were. We were able to create a common vision and picture as following:
  • We need to manage items on a higher abstraction level then user stories used in the product backlog of (software) engineering.
  • Such an item (a project?) aligns to strategy and shall deliver an outcome that creates business value.
  • We need to re-prioritize items fast in case of external events.
  • No item shall block our system so that other items have to wait.
  • We want to follow the lean idea to limit the number of items we work on in parallel. So to say we introduce a work in progress (WIP) limit for the items in progress.
  • We want to manage all types of work in this system: work that ends up in implementation of software, conceptual work (for example a new concept to organize a core process), organizational work (for example re-organizations), and combinations of these work types.
  • We need a transparency for everybody in Digitec Galaxus. As we are distributed over several location (logistics, retail shops, headquarter) a tool support is required. As we already use Atlassian Jira, it would be wise to go for a Jira implementation of whatever we do.
  • We need to offer the departments the chance to implement tiny software related changes and improvements in a fast way.

The SAFe image for sure influenced. The idea to use three abstraction levels of requirements and a Kanban system around the highest abstraction level was convincing. So we agreed about the first experiment: Beside the two already as default in Jira built-in abstraction levels of user story and epic we create a third and more abstract issue type we called initiative.

That was a start - no we had the tasks to work different from tomorrow on.


Wednesday, April 8, 2015

Herding ants – so many opportunities, where to start?

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:
  1. (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.
  2. (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.
  3. (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.