Friday, November 2, 2007
The power of a pen and a notepad
My learning style
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
The magic of Daily Scrums
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
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
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.
learning
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.
teaching
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.
communication
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.
Progression
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
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.
Optimization
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!
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
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
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
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.