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.
Subscribe to:
Posts (Atom)