Tag Archives: Agile

Don’t Tell – The Missing Column of the Delegation Board

I love Delegation Boards since I first learned about them in Jurgen Appelo’s book “Management 3.0”. If you have not heard about them yet, you can find a good introduction here at the Management 3.0 website.

A couple of month ago I became the head of a department of Agile Coaches and Agile Project Managers. To help me find my own way of leading, especially when it comes to making decisions, I started to set up my delegation board.

delegation_board

Soon after I was installed in the new position my team, other colleges and the whole company expected me to make decisions about anything. I had no chance to do an upfront planning of my delegation levels and so I decided to fill the Delegation Board on the fly.

It was like saying to my team “Hey team, I decided about this, you see and I did it all alone. What do you think about it?” This helped me a lot to reflect about an appropriate delegation levels for my different responsibilities and it was a clear message to my team, that I expect them to challenge me continuously for advancing to more deliberate delegation.

For instance I was asked by HR if I want to have some trainees in my department. We never had any and so I directly said no. This was a decision and I did not even ask my team what they think about having trainees with us.

So at least I put a sticky note onto my delegation board in the “Tell” column with the topic “Do we need trainees”. I told the team I made that decision alone and I’m not sure if it is a good idea to make those decisions alone. If they feel uncomfortable about it too, they should please actively challenge it to a higher delegation level.

At the same time I came to learn that there are decisions I make, that I don’t even tell my people about. It happened when I was hiring a new freelancer as an Agile Coaches for my department. We negotiated salaries and only the candidate and me were part of that discussion. Finally we came to an agreement about the pay.

That was a decision I made that would not even fit into the “Tell” column, because I did not intend to tell my other employees about the result of the decision. Right now we simply do not have that kind of culture where employees know and discuss salaries openly.

Still I wanted to make transparent that I make those kind of decisions. They should know I decide about salaries for external and internal employees. And they should not that I would not even tell them, what the result of the decision was. Knowing this my employees have the chance to question the status quo. They can think about how they want to deal about salary negotiation and suggest me another more open way of handling it.

Ofdont_telll course they can also decide that they are totally fine with the current situation and they like me to take care for that kind of administrative act as a service for them, which is what they are doing at the moment.

In conclusion I’m convinced that the delegation board is a great tool to shape and develop your delegation and leadership style. And if you really believe in it, you should add another column “0 – Don’t Tell”.

 

Advertisements

Bringing Kanban into Marketing – Part 2

A couple of month ago I started to implement a Kanban system for a marketing team in our company. This team is responsible for planning and running more than 500 internal and external events each year.

As you can read in my previous post they asked me for help because they were missing transparency. They just wanted to see what everyone in the team is doing on a day-to-day basis. They wanted to have their work visible. They wanted to be able to see redundant work as much as being able to recognize if they have forgotten something.

Very soon we set up a Kanban board that visualized the flow of their work beginning with an initial briefing for the event, all the necessary planning, the actual running and finally a closing phase for an event. Every day they met in a stand up in front of the board, updated each other on event preparation task progress, made decisions on how to handle blockers, pulled in new tasks and saw how great they were doing.

It did not took long to remove the primary source of dissatisfaction they had, the lack of transparency. Over time a couple of things emerged, that finally led us to redesign our Kanban board, which I want to share with you here.

One thing that happened really fast in the first weeks after we set up the board, was that transparency decreased again, not because they had submarine projects or did not make proper use of the board and task cards. It just got to filled up with events and tasks.

IMG_20140423_093017

 

What you see here is the board filled up with event cards in the second column. Every card presenting a single event that is currently in preparation. At times there were more than 30 events in preparation in parallel. The next three columns “To Do”, “Doing” and “Done” are reflecting the work on a task level that has to be done to prepare an event. Usually we had lots of tasks floating around in “Doing” even over longer periods of time.

Also there are only few tasks in “To Do”. The team simply did not use that column to visualize the work still to be done for the reason that if they did, the board would have been exploded with upcoming tasks. In the end you see how this Kanban board was not longer able to provide a good overview about the work in the system.

Delivering events is different – fast is no goal

I came to realize that the nature of work of preparing and running events is very different from the work of a product development team in respect of how the work flows. Let me explain that. When I saw the filled up board of the event team, I initially thought they just have too much work in progress (WIP). So limiting the amount of events that they prepare at the same time, would reduce the number of cards on the board and increase the board’s ability to provide an overview again.

And limiting WIP in general reduces cycle times, which is exactly what we want in product development, where we seek to push out new ideas to our customers as fast as possible to generate feedback and iterate over it. This is totally different for the event team. There is absolutely no sense in delivering the company’s Christmas party in August. Nearly everything that they work on has a fixed dead line. And success for them means to deliver on time, not late and not early.

I got good feedback from Arne Roock on the issue. He suggested that, if they could not finish earlier, they may be able to start later thus decreasing cycle time in another way. Why shouldn’t we try to start the planning of events later? Good idea I thought, but then I was convinced, that it is not helpful for the team to start with the planning of the Christmas party say in early December. All possible event locations would have already been booked out by that time. Same is true with other external dependencies for events like event speakers, caterers and even attendees.

See my problem? I got a Kanban team, that has to start work items as soon as possible an deliver on time. All my talk about reducing cycle times, limiting WIP, working in serial instead of working in parallel just made no sense to them. And so I was missing goals and arguments to improve the team. Kaizen to what goal?

The nature of the team’s work – waiting is normal

Things got clearer for me when I understood that events are work items, which wait most of the time. When you come to plan a new event, you do some things very soon, like book a location or acquire speakers. When you are done with that early preparation, you wait.
Most of the rest of the preparational work for an event is then done in the weeks directly before the event’s “delivery date”. Waiting is normal in that system. So we decided to build that into the board, showing us which events are currently waiting.

IMG_20140616_094318

I got the tip from Wolfgang Wiedenroth to add a space to the board, where events are explicitly allowed to wait. He suggested multiple waiting columns one for each month of the year and that’s what we did. You can see the additional waiting columns at the right on the board.

Now when the team starts to work on an event, it does all the early things to do, like booking hotels and contacting speakers. When this is done the event is parked and the team decides when it will continue to work on it. For instance they decide its OK to park the Christmas party till October after location is clear. The event card is then put in the October column.
When October comes they will decide to pull back the event card for the Christmas Party into the system and do all the remaining preparation tasks for the event.

Using this approach the team’s board is much more expressive again. The team sees what events they are currently working on at a glance as the number of events in preparation in parallel is reduced.

One other change to the board was suggested by the team. Instead of having “To Do” and “Doing” columns on the task level, they wanted to have “Tomorrow” and “Today” columns on the board, reflecting what are they working on today and what are they planning to do tomorrow. This column layout suites the reactive nature of their work much better. Though they have a rough plan when they start to prepare a new event, most of the actual work they do is highly dependent on the reaction of external factors and thus very reactive.

In result these two board changes increased the transparency for the team again. Everyone sees easily what’s currently worked on and who is working on what. The daily stand ups are running smooth and in time again and provide opportunities for the team to help each other and to decide how to organize for optimal progress. Still I am missing some kinds of measurable goals for them like faster time to market would be to a product development team. I am looking forward to get your feedback and ideas for system improvements.

 

Kanban – What’s in for you as a ScrumMaster?

When I first heard something about Kanban several years ago I did not like it at all. Working as a passionate ScrumMaster with a team following good Scrum practices, I was very suspicious about it. The first thing I’ve learned about Kanban was that there are no sprints and there is no commitment and it sounded horrible to me. I just could not imagine that a team will aim for high performance without giving a commitment to the Product Owner and to themselves.

In the last two years I had a lot of touching points with Kanban. I listened to talks, read books, drank coffee with Kanban enthusiasts and finally even worked with several teams making use of Kanban implementations. My perceptions about the usefulness of Kanban in software product development changed completely. Nowadays I would not want to set up a Scrum team without making use of the principles and practices of Kanban. Otherwise I would not set up a Kanban team without using some of the Scrum ceremonies like retrospectives or daily stand ups.

I know ScrumMasters who are still very suspicious about Kanban and only think of it as being Scrum without commitments. If you are one of them, I want to give you a brief list of things Kanban can do for you to make your Scrum better.

Flow management

A Scrum team is self organized. That means after pulling a set of stories into the sprint or after committing onto a sprint goal, they can do whatever they want to have a successful sprint. Kanban has practices for your team to manage their work flow from generating ideas to delivering product increments to customers. It gives your team good guidance on how to use the freedom of self-organization successfully by explicitly visualizing the complete work flow and limiting work-in-progress for instance.

More to see

When set up properly you as a ScrumMaster will be able to learn more things about your team using several metrics and charts of Kanban. Those will add to your Scrum toolbox and your ScrumMaster’s intuition to evaluate the fitness of your team and to guide them to become better.

Experimental learning

There are retrospectives in Scrum. And your team is expected to use them as learning opportunities and to commit to improvements. Kanban in addition wants you to set expectations for each change your team commits to do and later on asses if your change was successful or not. By using learning models like the Deming cycle for instance Kanban shows you how to evaluate you improvement ideas in a complex environment and how to keep track of them.

Greater adaptability if needed

I love Scrum and I believe it is the best fitting framework for many software development teams working on innovative products. But Scrum is also very strict about many things, like its roles and ceremonies. It even expects me as the ScrumMaster to defend it against framework changes. This will sometimes put you as a ScrumMaster into the very uncomfortable situation to foster the team’s self-organization but not allowing your team to modify Scrum to their individual needs.

Kanban gives you a broader perspective. It helps you to see your team from a systems thinking point of view and encourages you to continuously change your process as long as there are sources of dissatisfaction left. Kanban helps you to let go and even to encourage your team to modify their process beyond the borders of Scrum if it increases their business agility. The evolutionary change that Kanban fosters will help you control the risks involved when crossing “safe Scrum borders”.

Less resistance to change

If you want to successfully change how people work you need their acceptance and trust. Many teams which are confronted with Scrum for the first time perceive it as a big revolution. It might initially scare them so much that they don’t even want to start changing at all and even if they start it might take a long time until they really see and feel the benefits.

Kanban encourages you to start with your team right where they are and even accept all roles, job titles and responsibilities. From that starting point you will change continuously and step by step. Most of the time it is much easier for others to follow your change management that way.

Scalability

From my perception scaling a Kanban system is a very straightforward process, though it might not be easy in terms of getting more teams, departments and management into the system. Starting with the visualized flow of your team you can scale out by taking into account what is happening with the things your team builds and where does all this work for your team come from. You grow your Kanban and integrate more and more of the complete value stream.

By following the same principles and practices you can also manage the flow of many teams, departments or the whole organization as you do with Portfolio Kanban. You just have to choose the appropriate granularity for the work items on your board.

For me there is absolutely no Scrum vs. Kanban question. I see both of them acting in different dimensions and helping each other just the same way I would encourage my Scrum team to make use of XP practices like TDD or pair programming. Kanban made my Scrum better, I believe it will improve yours to.

Scaling The Happiness Index

How we started – the need for more direct feedback

Early in 2012 we (some ScrumMasters, team leads and other IT managers of Germany’s top real estate portal ImmobilenScout24) found value in the idea to have something like a continuous employee happiness feedback.

By the time we already had 500+ employees and we were making use of several annual employee feedback surveys. Those surveys gave us good insights into the thoughts, feelings and wishes of our employees. They had comprehensive and sophisticated questions covering all relevant aspects of work. And of course there were always parts dealing with all kinds of feedback related to leadership and management.

The survey results were useful to us and they still are but they were lacking of prompt feedback. It was hard for us to see how for instance management decisions are taken or how people think about events or new strategic directions by assessing happiness half a year later. Because of the comprehensiveness of the annual surveys it was no option to simply do them more often. We wanted more direct feedback but we don’t wanted people to do surveys all day.

What we were looking for was something lightweight. Something that will take only five minutes to do and still delivers valuable content for us. We found it in the Happiness Index which was mentioned in a blog post by Jeff Sutherland and which was originally invented by Henrik Kniberg at Crisp.

The Happiness Index

If you are not familiar with the Happiness Index, let me introduce you to it. The basic idea is to ask people only few questions about their happiness but regularly and often. This will then enable you to chart happiness over time and recognize trends and impacts of events to the happiness of your team members.

The underlying believe is that happy employees are better employees in terms of creativity, productivity etc. and that one important aspect of good management is to make sure your employees are happy at work. This follows all the findings about motivation that are covered so well by Dan Pink or Simon Sinek for instance.

The Happiness Index originally asks the following questions:

  1. What’s your name?
  2. How happy are you? (on a scale from 1 “very unhappy” to 5 “very happy”)
  3. What makes you feel best right now?
  4. What makes you feel worst right now?
  5. What would increase your happiness?

The second question gives you a simple number as answer, which makes it very easy to aggregate and to do all kinds of fancy statistics with it. The questions three to five are free text and allow people to express their feelings about happiness in natural language.

Adopting the Happiness Index and rolling it out

The Happiness Index was originally used on a team level to visualize a team’s mood over time and to help teams and management to improve their happiness. We wanted to use it for all our IT product development teams and we already had about 25 with a total of 150 people in early 2012 when we started.

The level of trust within a team is naturally higher than the level of trust between 150 people of a whole IT department. So we decided very soon to have our Happiness Index anonymous. No name field would be part of the survey.

One other thing that we wanted to have differently than the original Happiness Index was the general happiness question “How happy are you?”. This was too general for us as we wanted to learn about things that we might be able to influence. We made two distinct questions out of it.

  1. How happy are you in your team?
  2. How happy are you with the company?

Building and maintaining good teams is one of the core management responsibilities and so the question number one was aimed to give us direct feedback about the quality of our work as team leads or ScrumMasters for certain teams.

The second question was intended to give us more insights on how people think about the bigger cultural and strategic topics in or organization. We intentionally avoided to define what “team” or “company” means. We hoped to learn where employees draw the borders here.

After some time we dropped question number four “What makes you feel worst right now?”. The given answers were highly redundant to the answers given to question five “What would increase your happiness?” and the last one seemed us to be better in enabling people to make suggestions for improvements. We find it to be more proactive.

For the amount of data we expected to collect would be too much to be visualized completely and directly we came up with the idea to have a Quarterly Happiness Review meeting with Management and all employees. For that I committed myself to dig into the collected data of the last quarter, analyse it, find trends, visualize everything and then present the results.

Running and maintaining the Happiness Index

For the high number of people we wanted to address regularly and since some of them were working remotely we looked for a web survey solution. Pretty soon we decided to go with a Google Drive survey which writes its input into a table. I spent some time figuring out how to use Google Drive functions to continuously fill in additional data into the table with every newly inserted row. But I got it working and now every survey answer got the right “next even calendar” week assigned.

happinessForm

The survey and the generated charts were then included into our wiki, so that our teams could use the survey and see the feedback in a happiness chart directly on one page. The chart with the aggregated team and company happiness was placed right beside the survey form and updated every couple of minutes.

Google Drive gave us this instant charting of happiness over time and allowed for some spreadsheet analysis and Excel exports to do more comprehensive analysis when needed. When I’m preparing a Quarterly Happiness Review I always end up in Excel. I play around with pivot charts to find new interesting connections in the data we have.

We decided to remind all the teams to give us happiness feedback every two weeks. I do this by simple sending out an email which contains the link to our wiki page with the embedded survey. Every two weeks is the level of granularity we found appropriate for keeping track of our employee happiness. We therefore aggregate all votes given over a period of two weeks into one data point like “calendar week 16”.

When sending reminder emails I sometimes add some ad hoc analysis. For example I give the top or low three topics of the last two weeks. This motivates people to vote as they see something is happening with the data and it is not just stored somewhere.

For the Quarterly Happiness Reviews I try to figure out about trends in the quantitative happiness values and show how they might relate to certain contexts in time. More important to us but more difficult to generate is the qualitative analysis. What is making people happy? What do they want to change? As those survey fields are free text by design I end up reading each end every post. To get a first impression I put all given answers in a tag cloud generator and get an intuitive visualization about the relevant happiness topics.

happinessTagCloud

I then assign clusters to all the given answers. Some answers are more related to the work environment and others relate to management. Some mean something about working Agile and some speak about the teams. Over time I empirically invented a set of clusters that seems to fit the answers of our people very well. The set is precise enough for us to draw conclusions from it and still it contains not more than a couple of clusters, which makes it easy to handle.

What have we learned so far?

From Happiness Review to Happiness Review I was able to better analyse and visualize the data and learned how to interpret it. Now after two years of measuring continuously and after the sixths Quarterly Happiness Review meeting I will give you a brief summary of what we’ve learned so far about ourselves.

happinessChart

We always had the feeling to work in an open, friendly and collaborative company culture which is making us happy and it was no surprise to us that this shared gut feeling is reflected in the data too. We see that all in all our employees are very happy with and in their teams. The happiness with the company is good too, but slightly lower than the team happiness. We interpret this to be an expression of the very team focused Agile working culture that we have established in IT product development. You identify with your team first and then with the company.

happinessSourcesEnglish

From the qualitative data we’ve learned that the main sources of happiness of our IT product development teams are working in a good team, having high performance and working Agile in that order. Nearly three-quarter of all answers to the question “What makes you feel best right now?” go into on of these three clusters. Lately the cluster “Good management” is getting bigger and people give more and more positive feedback in that direction.

As one of the responsibilities of management is to keep and maintain the happiness of their teams, this learning can be seen as an empirical leadership guidance. If we want to have our IT employees happy then we must care for team building and bonding, help them perform and let them live Agile values.

On the other hand we’ve learned that certain things exist that make people unhappy too. Most of the time the change requests go into “Better management”, “Work environment” or “Be more Agile” clusters.

happinessDomains

Since a couple of month we also have our colleges from the Sales Department on board. This enables us to recognize what happiness sources we share between IT and Sales employees and where the needs and perceptions differ between people of departments so different.

It showed up that IT and Sales share the importance of good teams and high performance for their happiness. Additionally we could see that performance is more related to reaching goals for the colleges in Sales whereas it is more related to delivering product increments for the IT teams.

In addition to that the people in the IT gain some of their happiness from reaching technical excellence which is not a surprise. The Sales teams on the other hand gain happiness from providing customer excellence as they have direct customer contact each day. Interestingly we never got any happiness feedback related to customer excellence from our IT teams though we work Agile (which the teams love) and customer happiness is an important goal for us.

This way the happiness index helps us to recognize a learning opportunity. I am convinced that we have to make Sales and IT people to talk with each other regularly about the products we build and the quality we deliver as the IT teams can only benefit from the customer excellence point of view the Sales teams have.

One last thing that I want to mention is the way the Happiness Index affected happiness directly. Like in the management wisdom “you get what you measure” just by having it set up and running and reminding people to tell us how happy they are every two weeks, our happiness became something more tangible, something that we took more serious. We had more moments to reflect and talk about it and thus treating it with special appreciation. From an employees point of view, having the Happiness Index shows that our management cares for their happiness.