Today at Crisp, we had a short discussion about effective meetings where I described what I think are needed in order to have successful meetings. Meetings, like work meetings, are used to produce some kind of result, achieve a agreed on decision or solve a problem. The discussion got me thinking about how often we are overloaded with meetings where many of them give little value back to the project and organization.

Paul Graham describes two different schedules, the manager and the makers schedule, where the former is run by managers working through the day participating in a lot of different meetings, and the latter is run by the workers, the developers and project participants, working through the day developing new versions of the product they are accountable for producing. These two schedules have their place in an organization, but we may get in trouble when the two schedules meet each other, which they do now and then during a normal working day.

Meetings cost quite a lot, and it is often not obvious for the managers working under the manager schedule how big that cost really is. I believe we need some kind of structure, an agreement between the meeting participants and the organizer of what they need to prepare and do before the meeting, in order to guarantee that it will be as efficient as possible. This to ensure that the organization get some kind of ROI from having the meeting.

Continue reading

Not long ago I met with a manager who during a discussion ruled out the possibility of success of a solution. I was a bit surprised and afterwards asked why that was not doable. It turned out one of the reasons was the managers fear the team would kick off with unrealistic expectations and leave 

I am currently working as a Scrum Master for multiple teams at Projectplace in Stockholm, Sweden. One of those teams is the Mobile Team. They are developing Action Boards for both iOS (iPad) and Android platforms. These Action Boards are also available in the Customer Preview of the Projectplace web service. Both Web Team and Mobile Team share the same API’s. The iPad app is planned to be released in 2-3 Sprints from now.
This case study can be written from many perspectives, but in this article I am going to focus on how we are working with the challenges of having a distributed Scrum team.

Continue reading

I just finished working on a short presentation that I will give this week about agile and lean development. In the presentation I display a few quotes by Deming regarding management and the system perspective managers should have in their work. One of the quotes is the famous one stating that 94% of all improvement possibilities are in the system and only 6% by special cause (in other words, only 6% are caused by the individuals).

“I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this: 94% belongs to the system (responsibility of management), 6% special”

This got me thinking about the 1-on-1 and performance review meetings that I have used at previous job positions, and of which I have written about before in this blog.

Continue reading

Every organization has its culture that you can see when you observe people at their daily work. This observed culture should be aligned with, or congruent to, the official organizational culture. In reality there is often a gap between the intended culture and the real observed one. For example, management might say that quality is above everything else, while pushing  to release new versions of low quality product riddled with defects. Or an organization touts its focus on learning and removing impediments, while the reality is the complete opposite. This post discusses the impact and importance of cultural alignment.

Continue reading

Continuous improvement is a central part of both agile and lean; it’s the way to increase the productivity and ensure that the organization delivers an ever increasing level of value to the customers and the organization. Lean is derived from Toyota and the Toyota Way, which has inspired a lot of companies in the western world in their quest to increase their productivity as well. But we often focuse on the techniques and practices and do not see the more fundamental parts of the Toyota system that enable their very high level of improvement each year.

I worked at a company that tried to implement the Toyota Way and reach the same level of continuous improvment with what I believe to be the wrong focus. My company estblished a goal to reach seven improvements per employee in average per year. A goal that was inspired from a report that stated that Toyota implemented 1,000,000 improvements per year, which of course, is very high. This is one of many aspects that show why Toyota has managed to grow they way they have done during the last 50 years.

Continue reading

I’ve been thinking lately about the effects of transparency and information on decision making. After observing situations like:

• Teams flooded with report requests
• Costly measurements requests, but without explanation of why they are requested
• Holding back decisions in wait for complete information (even though just enough information seems to be present)

I’ve have wondered if more information can actually delay your decision making and what is really required to make correct decisions.

In short: More options can actually impair your decision making (more likely for inexperienced people). Experienced people are more likely to make the right decisions even in situations with incomplete information.

Continue reading

A couple of years ago during a visit to Japan I had the the great fortune of talking to the CEO of Fujitsu Applications, Jun Watanabe. Before we left, I asked him  "What is the most important thing in your work?" He’s response was  "At the end of the day, all that is asked, is what have I improved"

Jun is a manager who expresses his commitment to improve the capability of his organisation. And to improve it, you first need to understand it 🙂

What is capability? It is your team’s systematic performance, what it is constantly delivering. Examples could be your teams cycle time, your velocity or the number of production bugs you are getting.

How are you doing in this respect? Test yourself by answering these three questions in your mind:

There are a lot of interesting experimentation going on within the kanban community regarding visualization. While I truly support this (seeing the problem is the key to understanding it’s nature) and find this promising and exciting, I doesn’t correspond all that well to the problems team’s I have helped have had to struggle with.

Let’s face it:

• What good do WIP limits do if there is no one ready to take a stand for them?
• What’s the added benefit if visualizing a problem that no one cares about solving?

So a question (going through my mind for quite a while) is: Shouldn’t we be expecting something from management, and if so, then what?

So, you’re planning the future. There are is a lot of stuff you are eager to do. But stop and think – are you pushing forward in the right direction?

Make sure there’s a balance between:

• Product – what would makes up evolving in the eyes of our customers?
  We are not pushing features for ourselves right?

• People – what would make this a better place to work in?
  Are we leveraging the skills at our disposal?

• Process – are we limiting WIP, improving quality, surfacing problems early?
  Done right we should gain time to experiment and fulfilling creative ideas.

• Purpose – are we contributing to the society around us?

So, you’re planning the future. There are is a lot of stuff you are eager to do. But stop and think – are you pushing forward in the right direction?

Make sure there’s a balance between:

• Product – what would makes up evolving in the eyes of our customers?
  We are not pushing features for ourselves right?

• People – what would make this a better place to work in?
  Are we leveraging the skills at our disposal?

• Process – are we limiting WIP, improving quality, surfacing problems early?
  Done right we should gain time to experiment and fulfilling creative ideas.

• Purpose – are we contributing to the society around us?

Here is a real world story about Steve Jobs:

(Excerpt from an interview with Ed Niehaus at Coopers Journal, full story here)

Two views:

• I’d love we had more product owners working like this! Not about making an ad campaign that has to be this or that, – it’s about making a great experience!
• How would we have experienced Steve in any other role? Probably like a egocentric lunatic complaining and whining  "not good enough" all the time. A "non team player". People like Steve are rare but when whining they simply express a need for role where they can outlive their excellence. Our job is to create an environment so that can happen.

In a famous Leadership IQ study, we surveyed 48,012 CEOs, Managers & Employees about their performance appraisals. Here’s the shocking results: Only 13% of Managers & Employees thought their performance appraisals were effective. And only 6% of CEOs thought their appraisals were effective. We also discovered that only 14% of employees say their performance appraisal conversation offered meaningful and relevant feedback.

So are we
 a) continuously allowing people work on what they like to do, with minimum overhead, or
 b) adding makeup to broken processes

Read Esther Derbys excellent followup

When running Scrum (or Kanban), you will need management involvement. And it is actually better that you secure it from the start.

Don’t get me wrong – I am not advocating  detailed control and interference. No, what I am talking about is getting some punch behind dealing with impediments that your team will surface.

Here are the slides from my Scrum Gathering presentation “The Managers Role In Scrum“. The pictures will make most sense if you were at the presentation :o) Slides in powerpoint format Slides in PDF format