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!
Removability of code
December 6, 2011We had an interesting discussion with my colleague Arto Eskelinen a few days ago. We discussed the removability of code.
Before we get into it, let’s agree on one thing. Source code is a liability, not an asset. The more lines of code you have, the more time you will spend maintaining them, the more bugs you will have, the harder it will be to implement new code. When it comes to code, less is better.
We add lines of code when the business environment changes and we want to accommodate. We accept the fact that we add complexity because we expect to gain more in money than we lose in flexibility.
But what about the features that become obsolete? If code is a liability, wouldn’t it make sense to remove them when they become obsolete? I’ve personally never seen a post-it on a task board saying “Remove feature X”.
Removing features is tricky. Just like it’s tricky to test code that wasn’t designed to be testable, it’s tricky to remove code that wasn’t designed to be removed.
What if we designed code for removability? Like we design for testability, we’d design for removability. When writing new features we’d make them as easy as possible to remove. Would it make our codebase easier to maintain?
To solve a problem, stop thinking about it!
November 15, 2011We’ve all had moments when we’ve been working hard on a problem, trying to solve it, but failing to do so. We try to focus more and we stay at the office for an extra hour, but no, still nothing. Eventually we decide to give it a rest and head home. And then, on the bus, while not really even thinking about the whole problem anymore, a solutions pops up. And it’s a magnificent solution!
Why does this happen? Why couldn’t we figure it out when we were really trying, but could when we weren’t? In those moments we’ve managed to harness the power of the “nonconscious” mind, which has a far greater ability to process information than our conscious mind.
Harnessing the nonconscious can make a tremendous improvement in our problem solving skills. However, the key to becoming a better problem solver seems a little counter-intuitive: To solve a problem, we need to stop thinking about it.
In the image above you can see what’s going on in your head while your still at the office, trying to solve the problem. You’re feeling stressed out, you’re tired, you’re thinking really hard. All that is creating noise in your brain and the insights can’t get through. They’re weak compared to the noise. It’s like when you can’t hear your phone ringing in a loud and busy shopping center.
When we get on the bus and stop thinking so hard, we relax and the noise level drops. Suddenly we have an insight. This is illustrated in the image below.
The lowered noise level allows insights to get through. This is why great ideas pop into our heads at seemingly random times. This is why, in order to solve a complex problem, we need to stop thinking about it. We need to allow our nonconscious mind to solve it for us.
However, we can’t control or force insights. Trying to do so will create noise and actually hinder insights. What we can do is increase their likelihood. So, next time you’re really stuck on a problem, remember this blog post. Instead of trying to focus more, take a walk. Get some fresh air. Think about something else. Give the insights a chance to get through. Or, to put it simply: sleep on it.
This post is based on David Rock’s article “The ‘Aha’ Moment” (PDF). If you want to delve deeper, I strongly recommend reading the article. I’ve also blogged about other stuff I’ve learned from David Rock and Results Coaching Systems:
Kanban daily, revisited
November 11, 2011When we had just started doing Kanban I wrote about our daily Kanban meeting. What I didn’t realize at that moment was that our daily meeting was based on the following underlying assumptions, which are both false.
- We’re most interested in what has changed on the board (=what people have been working on)
- We can plan everything on-demand
I think the first assumption came from the three questions in Scrum daily. After a while we started having items on the board that simply weren’t moving anywhere. And we weren’t paying attention to them in the daily meeting since they hadn’t moved. We realized that, actually, we should be most interested in the items that are not moving.
The second assumption probably stemmed from my idealism. The idea was that we’ll do planning (=breaking work items into tasks) on demand when the WIP-limits allow an item to be pulled. However, in practice, the quality of the planning was poor.
A developer would finish an item, look for new work and notice that he needs to plan another item. Others are busy working on other stuff so he would plan the item by himself. And so, items were misunderstood, decisions were being made with very little information and planning would lack healthy second opinions. We were also missing out on all the knowledge sharing benefits of planning.
When we realized what was happening, we changed our Kanban daily. Here’s the agenda we switched to.
- Expedite items
- Status of build
- Walkthrough of items from right to left
- Planning needed? (min. 3 devs, tester, domain specialist)
- Notifications
First two steps remained the same. A brief look at the expedites and decisions on whether we need to make adjustments to be able to respond to them. Then, someone reports the status of the build and we pick a shepherd if necessary.
Previously, in the third step, we would only look at the items that had moved. When people moved items on the board they would attach a small piece of red tape on the items and during the daily we would walk through all those with red tape on them. In the new agenda, we started going through all the items on the board.
In the fourth step, which is a new step, we figure out whether we need to do planning. If there’s a slot available we might want to plan. We also sometimes decide to organize a planning session when developers say there will be a slot available very shortly. We’ve agreed that the planning sessions must have at least three developers, one tester and one domain specialist present to avoid the issues mentioned above.
During the daily meeting, if we decide to organize a planning session, we ask people to volunteer for it. We write down the names on a post-it note and put the post-it note on top of the work item to be planned. The people who volunteered will agree on a time and place for the session after the daily meeting.
The fifth step in the agenda remains the same. It’s a slot for notifications. It’s not for sharing knowledge or having discussions. It’s for notifications. If someone wants to have a discussion on a topic he would say “I will host a discussion on topic X at 11 in the coffee room”.
When introducing the changes we were slightly worried that the daily meetings would grow longer. They didn’t. We have a facilitator running the meeting and we always manage to get through it in 15 minutes or less. We have around 25-30 people present in the daily meeting.
Scheduling work in Kanban (PDF)
November 2, 2011A while ago I blogged about scheduling work in Kanban. I also talked about the topic at the Lean & Kanban Benelux conference. People showed interest in it so I decided to write a slightly more detailed description of the things we’ve done.
The schedule is a week-by-week calendar that captures our current understanding on when we’re going to work on a certain work item. Work items are plotted on to the schedule collaboratively with stakeholders.
The schedule has two primary goals:
- To create a mutual mutual understanding of priorities and their reasoning with stakeholders
- To communicate the plan to those interested (e.g. developers)
Problems the schedule can solve include:
- Business owners’ need for predictability and certainty
- Sense of direction for developers
- Coordinating work
- Linking work to calendar time
Here’s the 6-page paper: Scheduling work in Kanban (PDF).
This is the first version of the paper so feedback is very welcome. Thanks to David Anderson and Hermanni Hyytiälä for their comments so far. If you start applying these concepts, I would be delighted if you drop me an email.
I’m not an Agile coach – what am I?
October 19, 2011I used to to introduce myself to people as an Agile coach. Not anymore. Nowadays, I don’t really know what to introduce myself as. Here’s why.
The term ‘coaching’ is overloaded. There’s sports coaching, agile coaching, life coaching, business coaching and many others. All of them are similar, but not the same. On top of coaching, there’s mentoring, consulting, advising and whatnot. These terms are sometimes used interchangeably and sometimes they seem to overlap. I’m guessing I’m not the only one who’s had trouble differentiating between the terms.
Lately I’ve studied coaching with Results Coaching Systems. They have a very strict definition for coaching, which says coaching does not have an agenda. In coaching, according to their definition, the goals are always set by the person being coached. I’ve grown to like their definition of coaching.
However, this does raise a conflict. How can I call myself an agile coach if coaching shouldn’t have an agenda? Agile is an agenda. Agile is a solution that I’m proposing. And coaching shouldn’t have an agenda. Calling anyone an agile coach actually starts to sound very contradictory if you see coaching as not having an agenda.
So I’ve started introducing myself as a software development coach. That’s better. Right? Well…
John Seddon has recently thrown more fuel into my existential fire with his talks. Seddon is the father of Vanguard, a systems thinking approach for service organizations. One of his key points is that if the organization as a whole is doing the wrong things the significance of the method used in software development is very small. He says “Agile is about doing the wrong things faster”. And I think he has a point.
The fact that Agile revolves so much around software development has started to feel like a constraint. Like a sub-optimization. I’ve had this feeling for quite a while, but Seddon seems to have reinforced it. This is also a discussion that has been on going in the Agile community for quite a while already.
I would like to see myself as someone who looks at the whole. And of that whole, software development is only a part of. I want to help organizations do the right things with the right methods. Focusing on software development is not enough.
Thanks to Seddon, even ‘software development coach’ feels weird. So what am I suppose to call myself now?
Always successful? You need to try harder!
October 13, 2011Today is National Fail Day in Finland! How amazing! Congrats to the organizers for such a magnificent idea. They have understood one of the most important lessons in life: failure is an opportunity. Failure is an opportunity to see things differently, to do things differently, and to learn.
In improvisation theater there’s a principle that says you should succeed 80% and fail 20% of the time. If you succeed more often than that, you’re too much within your comfort zone. You’re doing things that are too easy for you.
When you fail 20% of the time, you’re doing things that are challenging, but achievable. You’re getting positive feedback since you’re succeeding a lot, but you’re still pushing the limits. This where you want to be.
Have you failed enough lately?
More vision, fewer problems
October 10, 2011David Rock, in his book Quiet Leadership, explains a model to help you focus your discussions and thoughts. I’ve found it very useful so I’d like to share it with you.
The areas of focus are:
- Vision (e.g. What do we want to achieve? What is the goal?)
- Planning (e.g. What’s the plan? How do we ensure success?)
- Detail (e.g. What action should we take? What should we complete by next week?)
- Problem (e.g. What are we going to do with these customer complaints?)
- Drama (e.g. Why do we always fail in this?)
Generally, in work life, we tend to spend way too much time in Detail and Problem. Sometimes we might even sink as low as Drama. Would you agree?
With the help of the Choose your focus-model we can consciously focus our thoughts more on Vision and Planning. I’ve found it especially useful when facilitating meetings or workshops.
First, simply write down the focus areas on a flip chart. Explain them in the beginning of the meeting. Ask whether the participants would find it beneficial to focus on clarifying the vision and planning the work. Ask for permission to interrupt discussions when you notice that they’ve drifted out of the preselected focus areas. Asking for permission beforehand is important. When you’ve asked for permission, people accept you interrupting them.
When you notice discussions going towards details or problems, which they will at some point, simply point a finger at the flip chart containing the five focus areas. Most often that’s all you need to do. If you really do need to interrupt, I recommend you do it by asking “What is the area of focus in this discussion?”
The Choose your focus-model can also be effective in focusing your own thoughts. Spent enough time on problems today? Maybe it’s time to consider what you really want to achieve in the bigger picture?