The Mikado Method book

The book is coming …

The Mikado Method book cover

For quite some time now I have been working on a book together with my friend and colleague Daniel Brolund. It is a very technical book about how to restructure software but despite it’s technical focus we are sure that team leads, project managers and people that have a bit of a technical background can benefit from reading it.

As of mid May 2013 it is available as a part of our publishers early access program, MEAP.

Find out more here: http://manning.com/themikadomethod

Solving problems

If I’m stressed and run into a really difficult situation I behave rather irrationally (read panic) and my first response is usually very ineffective. Escaping problems or not solving them at all is a rather ineffective but commonly used. More often we want to use another approach in order to reach a more sustainable solution.

Developer Exchange Model (pt. 1)

Usually when I am new on a software development team I wonder who might be a good pair programming partner. I also think about how to get to pairing quickly and stay in that mode. In this blog I will describe a simple model that I use when I reason and think about this.

Thinking & acting

If you plot the activities you engage in over the course of a day on a horizontal line where the far left is thinking and the far right is acting, it might look something like this.

Thinking and acting

Some activities require more thinking, more creativity and more reflecting whereas others are more routine like and straight forward. With practice some of the activities can be pushed towards the right as you internalize the knowledge, but some activities never change and remain purely thinking or acting. Let’s call this categorization ‘activity type’.

Collaboration & cooperation

Another dimension of our work is how we interact with others. We help each other learn, we move furniture together or perhaps participate in bi-weekly retrospective meetings. At some point or antoher we are more or less forced to interact. These modes I refer to as collaborative or cooperative. The difference between the two usually calls for some explanation since these modes are often confused or generally not understood at all. Lets start by catergorizing them as ‘interaction modes’.

The two interaction modes, Cooperation and collaboration, differs from each other in the same way a relay swim team differs from a rowing team. On the swim team you build upon each team members previous effort, whereas on the rowing team you are dependent on the efforts of the rest of the team during the whole race.

Real time collaboration

One of my favorite ways of collaborating is pair work — especially when I work with software development. It boosts my productivity but it also gives me a chance to see how other people learn, think and act.

Pairing is also a great vehicle for ideas, culture and knowledge sharing. And when it works, there is nothing like it.

Hopefully you have also experienced great teamwork at one point or another and maybe you can even recall a situation which can be described as a state of teamwork flow. The pairing was smooth, conversations took place and things you couldn’t accomplish on your own comes out of the collaboration, and it is the coolest thing you have ever experienced.

A Bumpy ride

Then again, there are these other situations when it just felt awkward, nothing worked and it felt like you were working solo but sat together. Much like trying to work on public transportation. Noisy, unpredictable and quite a bumpy ride.

Groups of people that work together usually strives for that elusive flow and how you interact with colleagues as you try to complete tasks during a day have a big effect on both the outcome and the way to the result. Some people prefer pairing on difficult tasks, some prefer prototyping alone to validate something while others have conversations. In short, different situations call for different modes of interaction as well as different types of activities.

A simple model

Even if pairing was very easy to get to and even if thinking together was equally easy there are times when it’s not the perfect interaction mode and something else is more suitable.

Developer Exchange Model

In order to reason more easily about this, I’ve combined the ‘activity type’ and ‘interaction mode’ in a diagram. Take a look at the picture and note how four squares emerge.

I refer to this simple model as the Developer Exchange Model, as it is about exchanges between individuals on a team or in a group setting.

The mikado method and non code changes

A common question Daniel and I get when we talk about the Mikado Method is — ‘Can it [the Method] be used outside of the programming domain?’. The answer is yes, but there are a few things you need to consider.

The real world vs. code

One major difference we stress is that the real world lacks an ‘undo’, or a ‘restore to a previously working state’ — that slows us down. Once you’re past the undo-hurdle, a real world Mikado-approach is more or less the same as a code change.

Impact management — attacking from the right

In this previous blog the concept of risk as an area was introduced. The area is the product of ‘severity of undesired effects over time’. The reason I choose to call it ‘risk’ is because the software I’ve seen so far contains more or less undesired effects and there is always a probability that these can cause harm rather than good. The reason it is an area is because it is made up of two dimensions: the severity and the duration of the exposure of these effects.

Bugs, errors and unwanted effects

This is not my idea but since Joakim hasn’t blogged about it, I almost feel obliged to.

Some time ago Joakim, Tobias and myself where discussing and giving each other feedback on three upcoming lightning talks we wanted to present at the yearly Agile Sweden conference. Joakim had come up with a topic that had a lot to do with bugs, errors and mis-functionality that the users of a computer system has to deal with.

In his excellent talk Joakim ended up introducing a word ‘Felyta’ which roughly translates to ‘Error surface’ or ‘Error area’, The word doesn’t translate very well in my opinion but the concept is universal. I will try to explain it and then add to it.

How I’m using the feedback framework

Controllers, sensors and systems

Earlier I’ve written about my journey towards better interpersonal feedback and how that changed my approach in several different (social) situations. In general terms I
believe that no improvement can be done without change but there is an equally important ingredient. Timely, accurate and undistorted feedback.

Judgement

The concept of feedback plays a very central role in our lives, so central that there is a whole field of science called Control Theory that been dedicated to formalize the concepts around
feedback and controlling systems. In Control Theory there are basically three main components: A ‘controller’, which is used to manipulate the input to a ‘System’ in hope
of regulating the output, and finally a ‘Sensor’ that feeds back the information to the controller.

Implementing the framework

Whenever we ‘receive feedback’ or ‘give feedback’ we are essentially closing the feedback loop by ‘installing a sensor’ to our system. Back in 2007 Esther and Diana introduced a framework for feedback to me back which I see as an abstraction of the steps required to add a sensor in a social context, i.e interpersonal relationship. Since then I’ve been actively practicing giving and
getting feedback in a lot of situations and I am glad I have. The way I use this framework has however changed over the years and I will try to describe how.

Learning new stuff

Whenever I start out with something new I have this urge to ‘do it right’ which often conflicts with ‘doing it at all’. It doesn’t matter if I’m programming, practicing a new badminton serve or learning a new technique for giving feedback, I pretty much act the same way. I want a safe environment, enjoy short experiments and get encouraged by small successes.

When I started using the feedback framework I often did a couple of dry runs in my head and played out possible different scenarios to get used to the thought. Especially if my feedback was about correcting an undesired behavior. Before we continue with a few examples, lets refresh our mind and look a the four simple steps that makes up the ‘framework’:

– Find an opening
– Describe the behaviour or results
– State the impact
– Make a request

Finding the opening

In the beginning finding the ‘perfect’ opening could take me forever. I felt a need to prepare, I didn’t know much time I’d need and I procrastinated a lot because of insecurity. The procrastination phase passed once I learned a few standard opening lines like; ‘Steve, can we chat, there’s something I’ve been meaning to ask’ or ‘Wanda, do you have 5 minutes, I would like to discuss something with you’.

I found it easier to get someone’s attention if I was very precise about the time needed and if I could keep it short, i.e under 5 minutes, that helped as well. Waiting for an answer is of course also important. I also make sure the conversation is a 1-on-1 conversation as I believe feedback is something that should be delivered from one person to another, without stress nor an audience.

Describe the behaviour or results

When you are face to face and begin your ‘feedback session’ there’s usually a brief moment right at the beginning which is really tense. That brief moment was my second hurdle when improving my feedback skills. My trick is [still] to stay focused, keep the end in mind and start to deliver the feedback as soon as I can without stressing it.

When it comes to describing the behavior I try to be objective and stick to observed ‘facts’. “I noticed that you checked in over 40 files late last Friday afternoon” is a lot better than, “You broke the build again, right before you went home last Friday”. The description of other peoples behavior is easily interpreted as criticism if you’re not objective and there’s always a risk of falling into the trap of passing judgement, which  rarely results in insights nor changed behavior.

I constantly need to remind myself of this and try to stick to observations in order to avoid a very defensive conversation. I’ve also found that counting to five silently in my head after I’ve described the other persons behavior gives them a fair chance to respond when they give me their view of the course of actions.

State the impact

After I’ve listened to their part of the story I tell them how their behavior affects me. I am usually very careful about bringing other peoples opinions to the table, unless there is a very good reason to. This keeps the conversation and the feedback on a personal level. So, instead of saying “Peter and Jane thinks you’re a jerk whenever you check in code and just split without making sure all the tests run” I try a more personal view like, “It took me 3 hours before I could start on that new feature because I had to do a 3-way-merge of the code you checked in last Friday”.

Sometimes the impact is tightly connected to the behavior or the results, in that case deliver them together and pause longer afterwards.

Make a request

After the impact comes a really important part that I used to miss a lot before I knew about the framework — a suggested new behaviour or a request. I like to express myself in positive terms so I ask for something I want, rather than something I don’t want. Imagine yourself saying this “Stop committing broken, crappy code” . Now imagine a different approach like “Whenever you face a difficult merge just ask me and I’d love to try and help you” or “If you feel like storing the changes before you leave for the weekend, maybe creating a different branch and committing the code there is better?”

This is also a great time to explore other, better, options together as your request might not be the best solution and if you can find an alternative together that means:

1. You’ve understood each other
2. The new behavior contains a ‘mutual benefit’ aspect

With both one and two in place the change is almost always a breeze.

Read-Write-Delete

How I used to use the framework has changed from how I use the framework today. I have gone from a total feedback n00b towards deeper understanding and most of steps in the framework is now second nature. To self assess I usually look at myself and talk about my knowledge using a ‘Read-Write-Delete’ scale. At first I read the rules, after that I write my own rules and as I master something I start deleting rules.

In the beginning of my feedback journey I always tried to find an opening a had a prepared line, now I am more comfortable at improvising and don’t hesitate at giving feedback as soon as I am reminded about something. I however still assess whether or not it’s a good time for a feedback session.

More often than before I go into a feedback sessions without having a canned or prepared request and instead ask the person an honest question and say — I don’t know how we could improve, lets experiment. This would never have happened 4 years ago but it requires a close connection to the person I’m talking to and more trust. Removing steps from the framework in the beginning of your journey nothing I can recommend, but as you feel you’re getting better at this ‘feedback stuff’ — start to improvise.

I also remember having an extra rule at a time where I waited for at least one day before providing feedback in order to minimize passing judgement. I still use that rule, especially on the days when I’ve had a bad nights sleep.

If you find this useful or even better, if you have suggestions for improvement please contact me. The fastest way is twitter: @ellnestam another way is emailing me at ola at agical dot se.

It’s just a job

It’s just a job

It's Monday the 13th ... again.

Ever since I began to support myself, or as many put it ‘got myself a job’, I have wondered about the the Monday blues phenomenon. I understand the concept, can relate to the emotions but I still find it difficult to identify with the situation.

For me, what I love doing, which is getting computers to do what I and others want, has always provided me with enough money to make a living. It is probably the largest contributing factor to the lack of Monday blues in my life. Or the fact that I don’t feel a pressure to get the most out of every weekend, but I also understand that everyone isn’t as fortunate as me.

Burnout and depression

After seeing people both close and from a distance getting burnt out and depressed from activities they call their job, I am now even more convinced of the close relationship between what keeps you busy during the days and what brings home the bacon. Peoples largest source of income is rarely their hobby nor their favorite way of spending time.

Contrasts

This coin of life apparently has two sides and they look really different. On one side, my great satisfaction with my career choice and my results. The other side, depression because of lousy conditions at workplaces due to wacky colleagues, managers, idiotic routines, meaningless tasks, demanding customers, lack of recognition or a crazy mix of all the above.

It’s not ‘just a job’

The wide range in job satisfaction and the two sides of the life coin leads me to believe that it’s not just ‘a job’. Many identify themselves with their occupation, their results and above all, most of us spend close to a third of our awake time at our job, and doing things in order to make money.

Me, an employer

Since 2005 I have been an employer. Metaphorically it’s been a roller coaster ride with ups and downs. Partly loads of fun, excitement and challenges of course byt mostly it’s been very rewarding. A word a warning is in order: If you want a life without close interaction with your colleagues, it’s not something I can recommend. If you don’t truly care about others, being an employer merely becomes a charade-like game and you are easily interpreted as disrespectful as you profit on behalf of others.

Me, an employee

Before I became an employer I changed jobs several times. Whenever I told my boss I wanted to quit the inevitable question came up ‘Why are you quitting?’ often followe by a ‘Can we do something to change your mind …’. To me, these questions expresses a reality disconnect. Or were they just part of a the charade? It often felt as we had drifted apart, or maybe we didn’t understand each other anymore? The cliché, ‘It’s not you … it’s me …’ pops into mind.

Mutual benefit

I believe that the relation employer – employee is like any other relationship and when it’s not grounded in understanding and mutual benefit — it’s time for a change. Whenever the creepy feeling of not contributing or not getting enough out of your relationship with appears I suggest a change of organization. I think it’s up to each and everyone as an individual, whether you are an employer or employee, to be honest and tell what’s missing and then remedy that.

My wish for the future

I sincerely hope that there are more people like me who want a more personally engaging work. Or am I alone when I say we should be more honest and direct in the way we treat ourselves, our relations to colleagues and our workplace? I think that the the time we spend making money, this third of our awake time, is just as important as the rest of our life and we should give it the attention it deserves. At least if we want to do well and benefit from each other.

It is not just a job, it’s a big part of our adult life and it’s time to act.

What I’ve learned about self organization

Cross functional teams

I guess we can all agree that any task that needs to be carried out requires an adequate skill set in order to be completed. Should the task be more complex or less trivial, a broader set of skills or a more proficient person carrying it out is needed. When I look at software development I see a mix of non triviality and complexity, since it’s usually a long series of pretty difficult tasks. These characteristics and the creative aspect that comes from someone finding my work useful is what attracts me to the software business. In addition to that I find it rewarding and interesting to work with others. My guess is that this is what makes people group together and form teams when they develop large software systems and applications.

Becoming Agile

A couple of weeks ago I found a little note that I scribbled down a year ago. Instead of turning it into a blog which I intended in the first place I drew a little comic strip. Today I finally got my hands on a scanner and decided to share it with you.