No Comments »

For about four months, I’ve had a draft of a blog post on books that have changed my point of view. I didn’t publish because I felt like no one would care. But after reading Henrik’s post about this books, I had to follow suit.

I’ve always read a lot. But a few books stand out.

• The 7 Habits of Highly Effective People

I read this book ten years ago, but I still remember how it changed me. It changed me in my professional role, but it also changed me in my interactions with my family and friends.

• The Fifth Discipline

This book is about the learning organisation. It’s really interesting sharing the anecdotes of how big corporations can change by making an effort to learn from each other and it’s clients.

• The Goal

This book, and it’s sequels, made me constantly aware of bottlenecks. I can’t drive down the highway without thinking about what could be done to make the movement of cars more effective.

• Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

In Sweden, the word “konsult” is often used of people that work as freelance developers. This book changed how I view a consultant. It also made me use my intuition and my feelings as powerful tools in a client engagement.

• Agile Software Development

I love how this book changed my view of software development. I liked the simile between coding and climbing, and how he explained that making great applications really is all about moving ideas from brain to brain. Everyone working in an agile team should read this book.

• New People Making

This is not really a business book, but more and more I’ve come to realise that consulting is about changing behaviours, and changing behaviours is about understanding how groups interact. This book gave me some great tools to use to better understand group dynamics.

No Comments »

No Comments »

Pat Kua writes:

“At Thoughtworks we run regular rounds of reviews (at least twice a year). We also try to collect project roll off reviews…”

We I first joined Thoughtworks, this is one of the things that really excited me. I’m a huge believer in feedback, and to find out that the company I joined shared that view made me happy.

When the first round of feedback was up, I realised that there was a little problem. The feedback we give each other is also used for our bi-yearly performance review, and our yearly pay adjustment. This is very different that feedback given to help the other person grow.

When I give feedback, I don’t hold back any negative feedback. To me, negative feedback is probably the most valuable feedback, so why would I take that away from my colleague? Well, if my negative feedback is going to adversely affect the other persons pay rise, I personally don’t give it as freely. I care for the person, and this prevents me from being 100% honest about that persons performance.

I’m not saying that the feedback collected and given during the performance reviews are not valuable, just that it’s not the same thing. I tend to see performance review feedback as an answer to the question “How good is that person?”. The question I want to ask are much more like the ones Pat lists.

What I’ve started doing is having one-on-ones with people, asking them to give me the feedback personally. This way I can make sure that they understand that they are giving me feedback to help me get better at what I do and not to influence someone setting my salary. Whatever they then go and write in the official feedback forms, I still have the very valuable direct and honest feedback.

3 Comments »

Years ago I played rugby. We had a great coach who was into mental training. So he had us watch lots of rugby games, and to try and imagine it was us on the television. Before a game, he encouraged us to spend time seeing ourself get to the ball first, making that tackle, having the energy the keep running, and so on. When the actual match came, I sometimes felt like I already played the match hundreds of times. It really helped me become a better player, and the team as well. We would watch the interaction of key players, and players who had lots of interaction would talk to each other over the game and we would figured out how to play together.

This mental preparation gave us a common vision. We never played as well as we imagined that we would, but I think that it made us into better rugby players.

Lately, I’ve been thinking that this is something that I would like to use on the teams I work on. Some teams that I’ve worked with seem to accept the bade state of things merely because they fail to envision something better. The team doesn’t have a shared vision of how they could work together, and so they don’t work towards a better way of collaborating.I think that the most important part of creating and maintaining a team vision on how things could be is regular retrospectives. Taking the time to reflect on how things are working, and talking about what could change is the key to build a common understanding. Not having this team vision is one of the biggest hurdles when I try to introduce new practices to a team that is set on their ways.

I’m curious to find out if you’ve worked actively on creating a team vision, and if you did, what steps did you take.

5 Comments »

Feedback is at the centre of agile development. Test driven development, continuous integration, pair-programming, short iterations, showcases… These are all practices geared towards getting more feedback faster. We realise that feedback is immensely valuable for the team and for the individual, and still we might not do it a lot. Giving feedback can be hard, and receiving it can be emotionally tough, but there are a few rules that will make the process more enjoyable for both giver and taker.

I used to do a lot of SQL Server training. At one time, I was doing a SQL Server internals course, and one of my colleagues attended the course. After the course, I asked for feedback, and he told me that I cracked my knuckles a lot, and that it was making it hard for him to concentrate on what I was saying. I hadn’t even realised I was doing this. This is the power of feedback – it allows me as a trainer to learn more about myself as seen through the eyes of someone else. I now take great care not to break my knuckles when I’m doing presentations. Thank you Magnus!

Working in a development team means interacting with team members all the time. Specially in an agile environment that uses pair programming and collective code ownership, you will have to talk to other people about what they have done often.

Giving and receiving feedback is a skill, just like most other things we do at work daily, and you need to practise it often to get good at it. These are my rules of feedback.

#1. Ask for, and give feedback often
Just like using CruiseControl you want to become almost addicted to good feedback. This mindset will help a team learn more and quicker. If you start working with a new group of people, you should start the feedback cycle by asking for feedback, so that people get used to the dynamics before you start giving feedback. Giving feedback often will also help with the next rule.

2. Provide feedback early
It makes it easier to understand something if the feedback is close to the event. Getting feedback while I still have the situation and the facts clear in my mind is better than days or weeks after, when everything has started to fade. Also, getting feedback early on might prevent me from forming a bad habit.

3. Giving feedback is about sharing your feelings
Instead of generalising and making bold claims in the name of science, it’s more effective to give feedback in “me” terms. Instead of saying “you are rude”, you should say “sneezing in my face make me feel belittled and angry”. Whether or not an action is rude or not is up for discussion. My feelings are not. This also prevents you from taking the stand that you are the keeper of the truth, and turns the exchange from a lecture into a conversation, where you both might learn something. A good template is: “When you do that, it make me feel like this”.

4. Don’t evaluate or judge
Good feedback gives the recipient information on their behaviour, and gives that person a chance to change. Ester Derby writes “feedback is information about past behavior, given in the present, with the hope of influencing future behavior”. Whenever I feel that someone is judging or evaluating me, I have a tendency to become defensive, and I stop listening. So using evaluation as a feedback tool is a good way to create an argument, but a bad way of influencing someone. Sticking to concrete actions like “When we pair program you code without explaining what you are thinking, which frustrates me”, instead of “You’re not a good communicator and that’s frustrating”, will make it easier to get the message across.

5. Receiving feedback is about listening to someone else’s feelings
When hold this idea in my head, it’s much easier for me not take a defensive stand, and instead realise that I’m only listening to someone else’s point of view. I can now look at why this person reacted in this manner. Was it something I did? Do I need to change in some aspect? Do I need to communicate differently with this individual, or maybe the whole team? Or maybe the feedback is telling me something about the person giving the feedback.

6. Negative feedback is good
A lot of people think that you should give twice as much positive feedback as you give negative feedback, or “sandwich” the negative between positive feedback. It is my experience that groups of people that consciously give each other frequent and honest feedback, let go of the ego pretty quickly. When this happens, feedback can flow in a more unhindered manner, and everyone wins. Negative feedback is the best possible chance you have to really change. It’s difficult and awkward to give negative feedback, and you have to make sure that you present it in a digestible way, but it might also be the best kind of feedback.

7. Talking about the feedback
Meta feedback is a great way to become better at the art of giving and receiving feedback. It will also help people relax and really listen to what is being said instead of trying to defend opinions. To sharpen your feedback skills I suggest that you pick a person you trust and work with, and talk about this with this person. Then you try to improve each others feedback skills by giving each other feedback about the feedback. It’s well worth the effort.

What is your feedback to me on these rules?

4 Comments »

I’ve been training Brazilian Jiu-Jitsu for a few years now. What I love about it is that it’s so focused on effectiveness. A smallish person like me should, with proper techniques, still be able to fight and win over someone larger and stronger (but having less technique). Since our sparring is done with full speed and full force, if I don’t have good techniques, I’ll use strength instead, and soon I’ll be exhausted. The idea is to use the force my opponent gives me. If he pushes, I’ll pull. To get him to get left, I actually start by pulling him right, and when he resists, I’ll use that force to push him left. It’s a bit more tricky than this in reality, but this is the gist of it.

For the longest time, my consulting work has been a lot of force and little technique. It’s left me, my colleagues and our customers exhausted, but didn’t really accomplish much. I don’t mean to say that I’m totally useless for an organisation, just that I wasn’t very successful in introducing new, more effective ways of working.

I’m slowly finding new ways of communicating and working with people that makes this type of work easier on me and those around me. I’ve come up with a set of guidelines that help me stay on course.

1. Stay positive

My BJJ trainer in England has this natural high-energy way of teaching. He’s upbeat energetic and I can’t help it, but it makes me happy just to watch him. During my initial Thoughtworks training in India, I had the pleasure to see people like John Johnston teaching, and it was truly great. He is happy, centred and extremely “there” when he is presenting his material. I didn’t just lean back and listen passively, he made me care and pay attention to what he was saying.

When I’m working as a change consultant, I have a tendency to feel down and frustrated when things don’t move as fast as I’d like them to. I have to actively fight this tendency, and try to stay positive and work with people in a more engaging way. Instead of focusing on the frustration of the current way, I try to make people enthusiastic about how things could be. The funny thing is that after a little while, I actually become happier and have more energy, by just trying to come across as happy.

2. Focus on the pain

Any changes I recommend must come from a need in the team. Trying to introduce new practices just because I think it’s a good idea is doomed to fail. If it doesn’t itch, why scratch?

A great way of introducing agile is to start off by doing a retrospective. During the retrospective I focus on trying to find pain points in their current way of working. I then focus on introducing new ways of working that solve a very specific problem, instead of just because it’s A Good Thing™. In the spirit of TOC, other practices can be introduced later, to problems that might bubble up, but I try to solve the most painful problem first.

3. Dialogue, not discussion
   

People will let me persuade them to try something hard because they feel a connection with me, not because of my superior debating skills. Instead of just pushing my point of view, I try to open myself to the persons I’m talking to. I do this by freely sharing my convictions and my doubts, and to really try to understand the context the people around me are working in. This opens up a dialogue where we can share and listen to each other on a different level.

A powerful technique to achieve this is to watch my own feelings, and steer clear of a defensive posture. Whenever I find that I feel the need to defend something as a knee jerk reaction, I know I’m identifying with the idea too strongly. Instead, I try to find the hidden assumptions behind the argument the other person just made, and ask about it. “My experience doesn’t agree with what you just said. Help me understand where you are coming from.”

4. Only solve the problem they ask me to

Like Jerry Weinberg said in Secrets of Consulting – you should only solve the problems the client is paying you to solve. Often I find myself in the situation of wanting to solve a problem that the client might not even consider to be a problem. To try solving this will at best cause confusion, and most of the time will cause resent. This is the real consultants problem – to get the client to realise their real problems, and ask you to help them with those problems. I value my mental sanity enough that when I feel that the client I’m working with doesn’t share my view of what the real problem is, I try to leave. I have my set of priorities, and working with clients that don’t share these is a truly frustrating experience.

I’m realising more and more that what I want to focus on are the soft parts of software development. How we in the development team collaborate, how we communicate with each other and other people that care about our work. This gives me much greater job satisfaction, and I feel like it’s more valuable for my clients, although it’s very hard to measure.

If you find these kinds of tips interesting, I’d recommend that you read Fearless Change: Patterns for Introducing New Ideas. It’s a good book with concrete advice on how to be a change agent.

No Comments »

We just had an interesting discussion about how to introduce change to a development team. The talk was around how some changes actually hurt productivity before they make things better.

Martin Sahm, a colleague from ThoughtWorks, shared a simile that I thought was funny and helpful. Some activities are like bowling. You don’t have to be an expert to still score some points and enjoy your self. If you keep at it, you will get a lot better, but it is an fun and rewarding experience even for a beginner.

Other activities are like snowboarding. Most people that are good enough snowboarders to stay on their feet think it’s vastly more rewarding and fun than skiing. But it’s not something a beginner will immediately enjoy. You will fall often and hard before you get to the point where you see the benefits.

In agile, some things, like stand ups and CI are for the most part bowling activities – very little effort needs to go into them before you see the benefit. Other things, like TDD and time-boxed iterations are more painful, and require commitment and skill before they pay off.

Being aware that you are introducing a change that will make people fall on their bum might change how you go about introducing that change.

No Comments »

I’ve joined a new project recently. And they have a bunch of problems. The team consists of really smart developers, but over time, stress and too little focus on quality have seriously hurt their code base. Today, they are struggling to deliver at all.

ThoughtWorks has been invited to help them clean up a little of the mess. We’re working with introducing tests and clarifying their somewhat unclear design. At the same time, we’re being asked to not change the code unless it’s really important, because they’re merging branches of the code that split up years ago. Yes, I know this a Bad Thing.

I can’t help myself thinking that their problem is not in the design or the lack of tests. There is an underlying problem that no one seems to want to talk about. Tom DeMarco writes in his book “Slack”:

“In such an organization, there is a characteristic mantra that goes something like this: “Hurry up, hurry up, hurry up, hurry up, hurry up…”

When everyone in the team is constantly busy solving today’s problems, no one is preparing for tomorrow. If you think of software development as a cooperative game, not only do you have to make a move right now, you have to set up the board for the next move as well. If you fail to do this, you’ll be in trouble real soon. Of course, now and then it makes sense to take on technical debt, as long as you realise that sooner or later, you will have to pay, and probably with interest.

Sometimes, to continue building on a bad code base will only make the problem worse. At times like this, it’s good business to stop delivering at the same rate for a while, to be able to deliver even faster later on. It’s a tough discussion to have with the business, but a necessary one.

I’m not saying you should stop everything and refactor code for a few months. What I suggest is that you make high quality a primary concern, and delivering to a schedule secondary. Start introducing tests where you touch the code. Decouple as you go. Start having design discussions that involve everyone. Work on the teams communication skills – daily stand ups can help, as can retrospectives. You might want to start a design patterns study group to create a common language.

There are lots of things that can be done to improve how well a team works, but until you make a commitment to high quality, you won’t be able to make any lasting improvements.

1 Comment »

I was reading this post by Phil Haack, and I felt myself react strongly. You see, for the longest time, whenever I had to estimate my work, I felt stupid and like a liar. I had no idea! It was all guesses to me. I tried to learn from people that did this better than me, and we talked about doing the estimation in a deep enough level. I read the book that Phil talks about in his post, and it didn’t help me. It’s a great book if you want to learn about the rule of diminishing returns in estimation, and the cone of uncertainty, and the normal distribution of actual implementation times. But it’s all an awfully complicated way of guessing.

What are the problems with the traditional way of estimating then?

The first that comes to mind is that you might have experience with the technical problem before you, but has the team worked together before? That is not only the developers, but has the project manager worked with the developers? Have the QA people worked with anyone else? Change the team and you are introducing unknowns into something that is already rather unknown.

Another problem is how hard it is for our brains to try to measure something absolutely. That’s why the image above is there. Look at the two knights above, and try to see which is the black one and which is the white one. If our brains where wired to see absolute shades, you would see right away that they are the same shade of gray. But our brains are much, much better at seeing differences than at seeing the absolute shade.

The last problem I’ll talk about is how changes to the team affect the development speed. If you’ve measured in absolute time, it’s hard to predict what doubling a team will do to the deadline. Will it cut the remaining time in half? Will it double the time? Even after you have doubled the team, and worked for some time, it’s still hard to predict when you will finish.

Agile estimation and planning differs from traditional methods, because we estimate complexity and not time. We don’t talk about how long time something is going to take, we talk about how complex it is.

In an agile project we use our historic performances to show how we will perform in the future. We don’t try to guess what the future will look like – we extrapolate it from the past.

I won’t reiterate how good agile estimating and planning is done. Others have already done it. I’ll just quickly recap what I think are the most important points.

• Keep it relative. It’s far easier than absolute, and also more exact.
• Count on features signed off by the business and not on technical tasks.
• To plan, look at how you have done in the past. You’ll probably do as much today as you did yesterday.

Agile estimation is easier, less painful, and in my experience, far more accurate than the traditional ways of estimating. I’m sure your spread sheet is great, but my burn down chart beats your Excel any day of the week.

If you want to become better at planning and estimating software development efforts, you are better of buying this book instead of Steven McConell’s.

Edit:

After publishing this, I realised I should have been clear that I’m not talking about the way of agile estimation and planning, just my way. I know you can be agile and still measure time and not complexity.

2 Comments »