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.
Friday, April 27, 2007
Optimization
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.
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.
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 (http://www.volvocars.se) 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.
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!
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.
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.
Subscribe to:
Posts (Atom)