Prioritization means selecting and letting go
May 8, 2012A colleague of mine, Juhani Snellman, gave me an insight a few months ago. He said prioritization is about selecting and letting go. This definition has popped up in my head several times since and I’ve grown to like it more and more. That’s what prioritization should be about. Very simple. Select something and let go of something else. However, we tend to neglect the latter part.
When businesses prioritize they select, but never let go. This is why “I’ll put it in the backlog” is really code for “I don’t think this is important, but I don’t know how to say ‘No’”. It’s acceptable to have items hanging in the backlog for years, but it’s not acceptable to reject them.
Faith No More, in their song Falling to pieces, put it well. We have “droplets of ‘yes’ and ‘no’ in an ocean of ‘maybe’”. The song is not really about backlog prioritization (surprisingly), but the lyrics apply. The majority of work is in a state of ‘Maybe’.
Faith No More continues by pointing out how “indecision clouds my vision”, which is exactly what happens in software products. Never letting go leads to clutter and overhead. We lose vision, because a product is not only defined the attributes it has, but also by the attributes it lacks.
Saying ‘Yes’ or ‘No’ is an attempt to define the product. Saying ‘Maybe’ postpones the decision. While most decisions should be made at the last responsible moment, here postponement is stagnance and binary answers progress. By limiting your WIP, including the backlog, you can force yourself to let go.
Controlling a project leads to poor results
April 13, 2012In 1982 Tom DeMarco published a book called Controlling Software Projects: Management, Measurement, and Estimation. The book is the source for the famous quote: “You can’t control what you can’t measure”.
In 2009, Tom DeMarco wrote an article for IEEE, in which he says the book, while it has a lot of truth in it, ultimately conveys the wrong message. The book says control is important and that we should aim to control software projects. Now, 30 years later, the author no longer believes this to be true.
Here’s a quote from the article:
To understand control’s real role, you need to distinguish between two drastically different kinds of projects:
- Project A will eventually cost about a million dollars and produce value of around $1.1 million.
- Project B will eventually cost about a million dollars and produce value of more than $50 million.
What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.
Essentially: if control is important, you’re heading the wrong way. Controlling a project is not the goal. Finishing a project within the given timeframe and budget is not the goal. Maximizing the value is.
In fact, I believe that controlling a project will decrease its chances of becoming a major success. Using control on a type B project will degrade it into type A. To maximize value we need to be creative and disruptive. We need to do things differently, possibly in an unexpected way. Exercising control will prevent this magic from ever happening.
By controlling a project you can only reach minor success. If you’re willing to let go, there’s no limit.
The best way to succeed at work is to do nothing
March 30, 2012Russell L. Ackoff, a pioneer in systems thinking, categorizes mistakes into two categories: errors of commission and errors of omission. An error of commission means doing something that should not be done. Accidentally deleting a client from a database is an error of commission. An error of omission means not doing something that should be done. Not calling a potential client you were introduced to is an error of omission.
Most policies and guidelines in organizations are in place to avoid errors of commission. Organizations track errors of commission. Some might even have bonuses attached to avoiding them. We tend to be very focused on not doing the wrong thing.
However, the consequences are somewhat counterintuitive. If an organization is focused on avoiding errors of commission, the best thing for an individual to do is to do nothing. By doing nothing you won’t make errors of commission. And if you’re rewarded for not making them, if an issue comes up, it’s better to lay blame than take responsibility.
The two types of errors are also linked. We make errors of omission, because we fear errors of commission. We fear that by trying something new, we’ll break something existing. As a result, trying to avoid errors of commission will lead to more errors of omission.
We tend to focus on errors of commission, because they are easier to find and thus easier to track. However, fixing something that was incorrectly done is easier than catching an opportunity that was lost. Like Ackoff says: “The decline or demise of organizations is generally more likely to derive from errors of omission rather than errors of commission”.
We should focus more on avoiding errors of omission. And we do that by focusing less on avoiding errors of commission. So let’s grab them opportunities and worry less about making mistakes. And when someone does make a mistake, say “Thank you”.
If you liked this post, you might also want to read a short, yet popular post “Always successful? You need to try harder!”.
Your performance at work is 6%. Unless you change the system.
March 13, 2012William Edwards Deming, a famous American statistician, estimated that 94% of variation in a system is attributable to the system and only the remaining 6% to the people working in that system. So if we succeed, in most cases, it’s thanks to the system. And, if we fail, it’s almost always because of the system, not the people.
The exact numbers are irrelevant. Deming’s point was that the system has a bigger impact than the people. When I hear this, I feel discouraged. And it puzzles me. In software development, a top developer can be ten times more productive than the average developer. How could it be true that they only account for a minor part of the performance?
I think the key to understanding Deming’s remark lies in timescale. Deming also said that a bad system defeats a good person everytime. If you put a great developer into a lousy environment, in a couple of years, he’s not a great developer anymore. On the flipside, if you put an average developer into a great system, in a couple of years, you’ll have a great developer.
But why does this matter when, even if you have great people, their impact on the performance is minor? Because great people change the system. The systems that we work in are designed by us, people. We can change them.
Understanding that the system has a major impact should not discourage us. In fact, it should encourage us find ways to alter the existing structures. To change culture. To design a system that enables great performance.
Of course, some people have more leverage than others and some things can be very hard to change. If you feel like a cog in the wheel, maybe it’s time to find a better system to work in. Like Martin Fowler once said: “Change your organization or change your organization.”
Talk about goals, don’t talk about problems – From GROW to GLOW
March 6, 2012Me and my colleague Arto Eskelinen have been running a coaching workshop at several conferences and other events. (It’s also available as a training). The structure that we teach in the session is called GROW. It’s a structure for facilitating problem solving or goal setting. You can use it in one-to-one conversations, team retrospectives or full day workshops.
GROW stands for Goal, Reality, Options and What. In the Goal phase you define the ideal state, in Reality you talk about the current situation, in Options you explore possible alternatives for action and in What you agree on concrete actions.
One of the significant benefits of GROW, compared to just winging it, arises when we discuss the goal first. If we start the session by talking about the ideal state we create a positive buzz that stays with us throughout the session.
We love talking about problems and, without a structure, we easily delve right in and start digging a grave with all the issues that we have. If we manage to get to a point when we try to find solutions, our focus is on moving away from a problem instead of moving towards a solution. Focusing on problems in not productive or useful whereas focusing on a goal or a solution is inspiring.
Problems also tend to swim their way in when we talk about Reality. Yet again, not very productive or useful. This is why nowadays me and Arto talk about GLOW instead of GROW. Reality is replaced by Learning or Lessons. If we talk about what we can learn from the current situation, we still get the relevant facts, but the conversation is much more fruitful and solutions-focused.
Want to try this out in practice? Here’s a short guideline for your next session: Talk about goals, don’t talk about problems. To give you some ideas on how to apply GLOW, here’s an example on how to use it to facilitate a retrospective for a team of 6-10 people.
Goal
- Ask “What would an ideal working day be like?”. You might want to write the question down on a flip chart.
- Have attendees write down their own thoughts silently, by themselves, on post-it’s. One idea per post-it. Give them 5 minutes or so.
- Ask attendees to move close to a blank wall and have them share their post-its. Post one item on the wall from one person at a time, then move on the the next person. Order doesn’t matter. Have attendees shortly explain their post-it, but don’t discuss or evaluate the ideas.
- Have attendees move the post-it’s in to groups, if it seems worthwhile
- Ask ask attendees to share thoughts that occur when looking at the post-it-covered wall
Learning/Lessons
- Ask “What can we learn from the days during the last two weeks?”
- Follow steps 2-5 in the Goal phase
Options
- Divide attendees into groups of 3
- Ask groups to discuss: “What steps can we take to get closer to the ideal?”. Have groups list their top 3 suggestions and write them down on post-it’s. Give them 5-10 minutes to discuss.
- Have groups share their suggestions
What
- Ask “What actions will you take?”
- List each action and the person responsible for it on a flip chart
- Agree on follow-up
Happy birthday, blog!
February 22, 2012Today is my blog’s birthday. I started blogging exactly one year ago. I’ve published 35 posts and they’ve received 73 comments. Thank you for reading!
Most popular posts – TOP 3
- To solve a problem, stop thinking about it!
- Things you don’t learn in the university, but should
- Scheduling work in Kanban
Most liked on Facebook – TOP 3
- Always successful? You need to try harder!
- To solve a problem, stop thinking about it!
- There is no resistance to change, only bad change
Most tweeted – TOP 3
- To solve a problem, stop thinking about it!
- Uninterrupted flow considered harmful
- There is no resistance to change, only bad change
Most commented – TOP 3
- I’m not an agile coach – what am i?
- There is no resistance to change, only bad change
- To solve a problem, stop thinking about it!
Uninterrupted flow considered harmful
February 20, 2012Flow is a mental state in which a person becomes fully immersed in an activity. It’s when everything just seems to flow naturally like water. You may have experienced flow while doing sports, while absorbed in your favorite hobby, or on the job when working on something interesting and rewarding. Afterwards you may realize you’re starving and that hours have simply flown by without you even noticing it.
In a work context, flow can be very valuable. With the concentration of a flow state we achieve amazing results in very little time. And even though we work really hard when in flow, it’s not about slaving away. Being in flow feels great.
Many software developers seem to be able to reach flow while writing code. In software development, flow has become very highly appreciated. It’s a state you should aim for. And when you get there, you should avoid interrupting it at all costs.
On the other hand, Pomodoro, a popular concentration technique, enforces breaks. In Pomodoro, you set a timer for 25 minutes and concentrate on a task for that time. During a Pomodoro you avoid all interruptions, external and internal, but when the timer rings you take a break for 5 minutes and do something else. You then set the time to 25 minutes and go again.
Since Pomodoro will interrupt your flow every 25 minutes, does this mean the two are incompatible? After becoming a regular Pomodoro user, I’ve started to question the value of uninterrupted flow. I’ve started to notice the downsides. Basically, they seem to boil down to one thing: when in flow, we lose overview. We are so concentrated and absorbed that we lose the ability to look at the big picture.
We cut corners to achieve the goal we’re going for. We ignore relevant facts because during flow they seem irrelevant. We don’t realize that we’re heading towards a dead end. We forget that we have tickets to a theater that night.
Uninterrupted flow can also hinder insights. Thinking hard creates noise in our brain and important signals, insights, are lost. Having a break and thinking about something else might actually help us achieve our goal better.
The physical consequences of uninterrupted flow are undesirable. Skipping lunches or workouts or losing sleep by working late probably doesn’t work to your advantage in the long run. Constant uninterrupted flow is not a sustainable pace.
Do the benefits of breaks overweight the drawbacks? Some people argue that it’s not even possible to get into flow in 25 minutes. Or if it takes us, for example, 15 minutes to get into flow then that means we only have 10 minutes of concentrated effort within a Pomodoro.
I believe it’s possible to trigger flow. Prior to starting a Pomodoro we set a clear goal for that Pomodoro and then set the timer for 25 minutes. I believe these repeated actions position us in a place where it’s natural for flow to start from. So in practice, we can spend most of the Pomodoro in flow.
In my opinion, flow and Pomodoro are not incompatible and instead supplement one and other. The benefits of flow are remarkable, and we can get even more out of flow when we regulate it with breaks and learn to trigger it when we want to.
Things you don’t learn in the university, but should
January 23, 2012Tomorrow I will be giving a lecture at Aalto University on the topic ‘Software development – Things you don’t learn in the university, but should’.
My key points are:
- It’s about people
- It’s about the system
- It’s about courage
Software business is a people business. We need to communicate. We need to collaborate. Lone coders don’t build great products, great teams build great products.
We need to look at the big picture. Only optimizing our own area of work is not enough. We must understand the system.
And we must be courageous. We need to get out of our comfort zone. We need to try more, fail more and learn more. We need to say ‘no’ to pressure and ‘yes’ to quality.
The lecture is open so feel free to attend. It’s at 16:15 (on Tue 24th of Jan) in hall T1 of the Computer Science building.
UPDATE 24TH OF JAN
Here are the slides from the talk.
Working long hours? You need to stop and get on your bike!
January 10, 2012Working overtime is like hurriedly walking your bicycle without taking the time to stop and get on it. Let me explain.
Timeboxing means allocating a certain amount of time for work and sticking to that timebox. Even if you haven’t finished your work within that time, you stop. In the short run this might not make sense (you haven’t finished your work), but in the long run it does. Here’s the beauty: when you constantly use the same timebox, you learn to fit your work into it.
When we work overtime we’re actually hiding a real issue. We may have too much on our plate, we might not be prioritizing properly, we may be aiming for perfection when less is enough, or we might be working when too tired to even think. By working overtime, we hide the problem and never fix it.
Working hours are supposed to be a timebox. We work a certain amount of hours and we do our best within that time. When we slip, the pipeline isn’t working like it should. We should fix the pipeline, not work overtime.
When we limit our working hours and stick to the limit, instead of saying “I’ll just put in a couple of extra hours”, we’ll ask
- What can I do more effectively?
- What can I delegate?
- What can I say ‘No’ to?
- What can I skip?
- Can I do this differently altogether?
And each time we find an answer to any of these questions we’ll save time and we’ll learn. And the time and lessons cumulate. So essentially, limiting our working hours will make us work better.
Next time, after working overtime, get a good night’s sleep. The next morning, first thing, spend 15 minutes and think “How can I make sure this never happens again?”. Think about the questions listed above. By doing this, you’re stopping to get on that bike you’re walking.
There is no resistance to change, only bad change
December 20, 2011I resist bad changes. And so should you. It would be stupid not to.
What constitutes a bad change?
- Nothing in it for me
- Poor return on investment
- Amount or speed of change is overwhelming
If any apply, I resist. And I only resist to bad change. If I can win something with a proportionally small amount of effort and not get overwhelmed, I love change.
Understanding that I can personally be very change resistant when it comes to bad change has made me realize something important. Something that I think will help me become better at my work.
My work includes a lot of change management and I sometimes catch myself thinking people are change resistant. And I work with smart people. Most of them much smarter than I am. They shouldn’t resist change. Unless.. unless the change is bad or it’s introduced poorly!
So here’s my new mantra: “There is no resistance to change. There’s only bad change.” Or to put it the other way around, if the change is good and people know it, there will be no resistance. (And just to be clear here, when I say there is no resistance to change, I’m not saying that the psychological phenomenon does not exist. I’m saying that most often that’s not the problem.)
Let’s look at this through Christopher Avery’s magnificent Responsibility Process. When we say people are change resistant we are either blaming or justifying. We are blaming them for not seeing the change as the good that it is. Or we are justifying to ourselves that no one would be able to introduce a change in this environment.
So how do we move foward? By taking responsibility. If you face change resistance, it’s not them, it’s the change itself. Either it is bad or it looks bad. And if you’re introducing it, it’s your job to fix it.
So, when introducing changes
- Make sure the benefits are linked to people’s personal goals
- Make sure the benefits are greater than the required effort
- Help people understand the change (facilitated discussions work way better than lectures)
- Provide certainty by giving enough information in advance, during and after
And remember, if you personally face bad change, resist!