Friday, November 2, 2007

The power of a pen and a notepad

During the last couple of weeks I have spent tuesday evenings drinkning coffee and discussing software development and change processes with a colleague. For our first meeting I brought a notepad and a pen for me to write down anything interesting that we would discuss. We sat down on opposite sides of the table and I subconsciously opened the notepad and placed it and the pen on the table between us. It didn't take long until my colleague started to draw images on the notepad explaining his thoughts and I did the same thing. Every week I bring my notepad and the same thing happens. Last week when we discussed learning we confirmed what we probably already knew, that we both have a strong visual learning preference.

My learning style

Continuing my trend on exploring NLP I came across learning styles and modalities. I decided to try an online questionnaire to determine my learning preference.

When filling out the VARK Questionnaire version 7.0 I was diagnosed with having a multimodal learning preference, my exact scores was:
Visual: 10
Aural: 5
Read/Write: 7
Kinesthetic: 13

The score is very interesting to me, my own opinion previous to taking the test was that I actually had a more dominant visual learning preference complemented with a Read/Write learning preference and that I would score lower on Aural and Kinesthetic learning preference.

This is something I will need to follow up on. By learning about the different learning preferences and what it means to be multimodal I can improve my learning process.

This I have to follow up!

(me to myself: - damn, my backlog is growing too large, time to focus and prioritize, I am all over the place right now!)

Thursday, November 1, 2007

The Satir Change Model

A couple of weeks ago I participated in a workshop with Dan North where he talked about the Satir Change Model, created by Virginia M. Satir. Virgina has worked with family change process and from those experiences she developed the model. The model seems to be applicable in many different change processes and Dan North suggested that it could be used e.g. when introducing change in the software industry.
The Satir Change Model seems to addcress the behavior I have seen when introducing changes and also when undergoing changes myself.

After discovering this model I have talked intensely about it with my colleagues, who also works with introducing change in software development companies. From my limited knowledge of the model so far, it seems to offer the ubiquitous language that we have been lacking when talking about introducing change.

This model hs been added to my backlog of things I would like to be proficient in!

The magic of Daily Scrums

Teams who introduce Daily Scrum as a part of their Scrum implementation, have a gut feel, or evidence that suggest, that by introducing these kind of meetings we improve our efficiency. We feel this because traditional status meetings have e.g. a tendency to stretch in time and lack focus but Daily Scrums e.g. are kept short and concisely.

What is a Daily Scrum?

In a Daily Scrum, the team and potential observers gathers, and while standing up, each team member answers three questions:

  • What did you do yesterday?

  • What will you do today?

  • What impediments are in your way?

During the Daily Scrum no observer are allowed to talk and the meeting should last a maximum of 15 minutes. The Daily Scrum is moderated by the Scrum master.

The magic of Daily Scrums

So by just standing-up we suddenly become more effcient! This must be magic!

The truth revealed

Some argue that the reason why Daily Scrums are more efficient is because people are forced to stand-up and want to get to the point and finish earlier. The routine of standing-up also reminds us about the timebox of the meeting.

In my last assignment as a Project Manager I replaced the daily standard status meeting, where all participants would sit down, chat, drink coffe etc. with a daily stand-up meeting. The stand-up meeting was almost like a Daily Scrum. I quickly got feedback that proved that we became more efficient in this way.

Some of the participants argued that my success with the daily stand-up meetings came from the fact that everybody was forced to stand up and this was more uncomfortable than sitting down and that's why we finished earlier.

Although, there might be some truth in that, the main reasons for the experienced improved result probably comes from other parameters that we got for free when we introduced the daily stand-up meetings. These parameters comes from what we associate with good meeting discipline, as put forward by Steven M Smith in is article Rethinking Stand-Up Meetings, Part 2, namely knowing the agenda, timeboxing the meeting, minimize number of participants. Steven M Smith also addresses other aspects and possible improvements of the stand-up meeting but I will not address these here and now.

In addition to the above discussed parameters the Daily Scum and my succesful implementation of the stand-up meeting also had a good moderator who always makes sure that the meeting sticks to the agenda and the rules. A good moderator is also a key to good meeting discipline.

So there is actually nothing magic about the Daily Scrum, only discipline, and discipline runs all through Scrum.

Wednesday, October 31, 2007

Meetings without agendas

Following my new found interest in Neuro Linguistic Programming (NLP) I read an article on frames. In NLP frames is used to provide a context, focus or guidance for thoughts and actions. One type of frames is the outcome frame. An outcome frame provides focus on what you want to achieve, the achieved affects and the resources needed to achieve it. This line of thinking can be applied to the subject of meetings without agendas.

In some of the companies I have worked in or work with, people are meeting happy (compare with trigger happy). Not a day pass by without me being called into several meetings. People say we need to have a meeting about this or that. The meetings lacks an outcome and are rarely timeboxed and when the people exits the meetings, they are often confused as to what was decided and what is expected from them. I do find that people still often feel satisfied, while I always feel frustrated.

The reason for this, is that the outcome was to have a meeting, which was achieved. However, with a clear goal, a good agenda and a timebox you set the wanted outcome and this gives you a context for making decisions and assesing your behaviour.

So make it a rule for you to say no to meetings without a defined outcome. There is no rule without exceptions, but remember the downside of having meetings without a defined outcome.

Tuesday, October 30, 2007

Learn to learn before you teach

In Learn to forget I mentioned The Dreyfus Model of Skills Acquisition. In this blog-post I will elaborate on my thoughts on this model.


The Dreyfus Model of Skills Acquisition is divided into five skill levels:

  • Novice - No previous experience

  • Advanced Beginner - Step by step

  • Competent - Goal oriented

  • Proficient - Conceptual models / metaphors

  • Expert - Work from intuition

The model dictates that at any given time with any given skill you are belonging to a certain skill level. Depending on what skill level you belong to your behavior will be different. It will be different in the way you act and also how you learn and progress.

As a novice piano player I will not be able to play a song that I hear on the radio by ear, instead I need to know how to play the scale first to understand what sound comes from pressing a key, as a advanced beginner I can play by numbers, when I am competent I can follow musical notes, when I am proficient I can play from a never before seen musical notes and when I am an expert I make my own arrangements to a known song by heart or play by ear etc.


By understanding how learning works you can yourself become a better student and able to coach your teachers so that they can help you progress. On my current consultancy assignment I am in many aspects a novice, but by understanding how I learn, I can progress faster.


By understanding how learning works your teaching skills will dramatically improve. If you can identify what skill level a perticular student resides at you can adjust your teaching so that it fits. An advanced beginner system administrator may need a step by step guide on trouble shooting desribing how to start an application etc. while an expert system administrator may only need pointer to what area the problem could be in.

one size fits all

Often software documentation is written as "one size fits all" and this is most definitely not true. This results in that either it is too abstract or to detailed for a certain user. If you teach a small group you can adjust your learning to the particpating individuals, but what if you teach a big group?

An example of this can be seen in martial arts. Karate is often thought in a classic step-by-step manor, since you have large classes where it is impossible to adjust to fit all students, you try too find a medium level that everybody has to follow, this will often attract novice to competent students but will push-away proficient and expert students since they feel that they don't develop. In Filipino martial arts you have smaller classes where the teacher can coach/mentor individual students based on their present skill level, this will make it possible for everybody to develop faster and also retain the proficient students.


I have found the model useful at several times when acting as a technical project manager and interacting with the product owners and business representatives. Instead of speaking in the language of a technical proficient person I speak in the language of a technical novice and a advanced beginner business person and guide my counterpart to speak in advanced beginner business language so that we will understand eachother. This one of the basic reasons to why business and technical representatives normally don't understand each other, they don't speak the same language. This is also one of the reasons why software development methodologies who focus on customer collaboration and delivering business values works so well , let business prioritize business values of features and let technical estimate and implement it and offer a common language for understanding eachother.


The way I was presented with the model at a seminar lately it was stated that the progression from novice to competent is rather linear and straight forward and that you can progress almost automatically but that the step to proficient and then to expert is non-linear and also requires a decsion and proactive behavior. You must decide for yourself that you want to progress. Maybe this can be connected to Rober Dilts Neuro-Logical Levels that I wrote about in Sustainable change. The higher your skill level are the more you must internalize it in your upper-levels, to become proficient or an expert you must make it a part of your values and beliefs or identity. A proficient person can explain and discuss his area of skills using metaphors and this requires a higher degree of internalization compared to behavior which is "just" something you do but cannot always explain.

I can really recommend you too explore The Dreyfus Model of Skills Acquisition, it has many answers to your everyday problems!

Sustainable change

Lately I have been thinking a lot about change management and how to achieve sustainable change. When change is introduced and headed by an external player and that player leaves the scene I have a feeling that many persons regress to the old behavior they had before the change was introduced. On my search for an answer I stumbled across Rober Dilts exploratory model of Neuro-Logical Levels. The model can be depicted as a pyramid, as a travel from a outer abstract level to a inner personal level.

A change at a lower level may, but not necessarily, affect an upper level. But, a change at an upper level will have impact on the levels below it. So for a change at the behavior level to be sustainable it has to be aligned with the upper levels or the change must take place on the upper level.

This suggest e.g. that, if it is not previously aligned with the upper levels, merely changing the physical location of people (environment) doesn't make people perform better (behavior). Telling people to negotiate better (behavior) won't have any affect unless you offer training on negotiation( capabilities). Teaching developers to do testing (capabilities) and demanding unit testing (behavior) won't be succesful when they actually think (values and beliefs) that a developer should develop and a tester should test.

Let's look at an example, management at FactoryY won't accept that the developers do pairprogramming since they argue that they only get half the bang for their bucks. They beileve that development is a mechanic task and that the value produced is restricted by how fast you can type on a keyboard and two developers sharing a keyboard can obviously type less than if each had their own keyboard. Here we must change on the level of values and beliefs and guide management to the understanding that develoment is a creative process not bound by how fast you can type on a keyboard.

And another example, at FactoryZ all the development is done component by component in different organizational units. When you get the assignment of leading a change initiative you quickly realize that the developers at the different units all believe and value cooperation and by grouping them togehter i.e. changing the environment, you can meet the goal of lower time to market by reducing the number of handoffs. The change in productivity will be sustainable since the change in enviroment is aligned with the upper level of values and beliefs. Note that the upper levels were already aligned but it was blocked by the lower level.

Robert Dilts exploratory model of Neuro-Logical Levels seems very powerful and is applicable in many areas e.g. self development, training, teaching, learning, leading change etc. I think I will study this closer.

Friday, April 27, 2007

Internalization of knowledge

At the schoolyard.

Adam: I train Karate.
Belle: I am good at throwing.
Joe: I practice Kung-Fu
Ali: I am a boxer!

Internalization of knowledge, taken to its limit - is not about what style you do (BTW will get back to discussions about styles vs. systems later on this blog )- its about being a implementatition of a system. I am the functional and operational system. This makes a world of difference.


If you rememeber my last blogentry Speed is bullshit, timing is everything! I discussed the relationship of speed and timing and that you could by developing good timing first and then adding speed become very good at what you do.

Well, as you might have guessed, this is not really the thruth. You can't develop the skill of timing alone, in isolation, and then based on that develop speed. What I do say is that it is more necessary to have timing in place, or at least be aware of it, first before you develop speed and timing together.

Well let's continue, you need to develop and optimize your skills together because "suboptimization is the root of all evil".

Let's picture a boxer, what makes him good? Is a good boxer a guy who stands still but hits like a horse kicks, or is a good boxer a guy who runs around but has no good hits? Neither, right? A good boxer is like Muhammed Ali, who according to himself, back in the days, would "float like a butterfly and sting like a bee,". This boxer has trained hitting and he has has trained footwork and has trained them toghether, he is a complete system which is optimized to work together, any other way runs the risk of suboptimization.

So this is our first observation on our way to systems thinking, failure to identify and understand the system may lead to suboptimization e.g. like the guns of Navarone, tremendous fire power but no movement. And we all know that fire and movement is a unbeatable couple, a well functioning system.

So how did the boxer learn all his moves - well first he learnt all the blow, jab, cross, hooks and uppercuts, the he learnt all the foowtwork and bodymovement, and the when he mastered all those movements individually then he spent several years integrating the skills and became the well oiled machinery he is today! Well, not quite.

On his first practice as a young boy he probably learnt a jab, some footwork (mastering each component) and then spent the rest of the training hitting what ever he could find, the pads, the heavy bag while moving and then finally by sparring (integration). So when learning the art of boxing he continuously integrated his new aquired skills on each pratice event, and the cost of integrating it with his existing knowledge became almost not noteable and he ran no risk of suboptimization - and it don't stop there, if he spars with the correct partners he also get immediately feedback if he is doing the right thing and if he is doing it right. With this information he is always on top of things.

For all of you who talks about the concept of nested synchronisation - well it is right here - If each training is your daily acceptance test, the brawl in the pub on saturday your weekly integration test and the club championship your release.

This is how a good boxer trains and always has trained. He is a well integrated, functioning and operational system. A young boy without any education who is performing the core principles of agile software development methodologies like Test Driven Development and Continous Integration.

Thursday, April 26, 2007

Speed is bullshit, timing is everything!

This controversial statement has been heard by anyone who has attended a seminar hosted by a teacher well known in the martial arts community.

Does he mean that speed has no impact on the outcome of a fight? No, he doesn't. He means that speed alone will not judge the outcome of a fight, in order to suceed you will need to have the right timing i.e. connect with your right hook at the right moment - you can be slow but still manage to knock out your opponent if you hit at the right moment. You can be ten times as fast as your opponent, if you can't hit him at the right time, or at all, it doesn't matter.

But then on the contrary, if you have the timing and then the speed you will be very succesful.

In software development companies, agile software development teams seems to be picking up speed, but not all businesses is getting the business result out of it that they hoped for (or was promised by some consultant), how can this be? I believe this has something to do with timing.

So you have the agile software development teams spinning at speed w but sales, operations and support at speed x. They are simply not ready for change, they are still stuck in their own tracks, so the timing is comletely off. When the development teams hand off a release it still takes operations 4 weeks to learn about the new release before being able to deploy it and support will start learning after operations has deployed and handed-off. So although the development department has improved, the chain is not stronger than its weakest links.

So how do we achieve the timing necessary for success. One idea we could address is the concept of crossfunctional teams. I believe that teams in these companies are not truly crossfunctional, they may have developers, tester but do they include sales, operations, support etc. Often they do not. So by allowing e.g. operations to participate in the teams they will have input on the product under development and also good knowledge of it once it is ready for deployment. Of course, not the whole operations department can or needs to be fully integrated with the development teams but one or two persons per team, always up to date with the latest is a step in the right direction. The same goes for sales and support etc. So by crossfunctional teams we could achieve better timing and reduce the pain of handoffs and relearning.

So speed is bullshit and timing is everything.

Introducing new software methodologies

When browsing the site of the new Volvo C30 ( I visited the site's "workshop", where Edward de Bono talks about creativity and thinking outside the box.

In one video Mr. de Bono says: " One of the very important things about creativity is that the new idea, the creative idea, must have value. Far too many people who believe they are creative, think that just being different for the sake of being different is creative, it is not. And that is what gives creativity a bad name."

This is true also when introducing new software methodologies. Always remeber the mantra of Lean: "maximize value and minimize waste". Make sure that the changes you introduce are actually creating value and not introduced only for the sake of being new and different, because then they are waste.

Thursday, February 22, 2007

Learning organisation

More and more software development departments are converting to agile methodologies - since agile is the key thing to be right now. As long as you're agile everything is super! Or is it?

This means that many software development departments adapts agile methodologies without really understanding the basic principles of which the frameworks are built upon. When you don't understand why you are doing something a certain way then you don't understand why you just can't do it in another way or don't do it at all.

I know e.g. of a development department that after using SCRUM for 6 months don't do retrospectives, since they don't really see the use of it. What is SCRUM without retrospective, how can you learn and improve without the basic mechanism in place.

In order to be able to learn and improve - do your retrospectives!

Wednesday, February 21, 2007

Learn to forget

Learn to forget. The first time you hear this sentence you are knocked off your feet, but when presented with the concept of learning to forget you can start to appreciate it.

First you learn, then you understand, then you understand why you understand, then you forget - so learn to forget.

This is the Asian logic as it was presented to me.

In west it has recently been in the spotlight, thanks to the promotion by the pragmatic programmers, and is known as The Dreyfus Model of Skills Acquisition.

Tomato or Tomato. It is worth checking out.