Okay... I don't know if you noticed... but it is really really hard to really curate an agile in a nutshell post that is quick to read, grasp and move forward. This is partly why I avoided much agile postings over the past decade - it's a very very long piece of string (or rope to hang oneself with)!
:)
The previous 2 attempts at this (Agile In A Nutshell and Agile In A Nutshell Part 2) I like and I teach fluidly. But I also add the following nugget when I am teaching.
Where did these agile manifesto, the 12 agile principles, and especially those 10,000 odd agile practices (half of them technical/technology focused like pair programming; and half of them people/organisation/management/process focused like standup meetings) come from?
Well it's clear where the agile manifesto was written and by whom in 2001 - 17 world-recognised software engineering consultants, coaches, managers and all importantly - practitioners.
And it's clear as well where the agile principles were written and by whom in 2004 - the same experts that formulated the agile manifesto.
But what about those 10,000 agile practices?
This means that we're still discovering practices all over the shop/place that help organisations become quicker and nimbler.
In my opinion, the smartest organisations are recognising their own unique practices that are giving them competitive advantages, and keeping them secret. The even smarter organisations are making their unique practices transparent and world-wide accessible because they realise others may contribute small tweaks that give even better performance - ala open source.
They also recognise that thinking is really hard to replicate and their organisation as a whole organism is thinking differently and hence behaving differently. Behaviours are easy to observe and replicate, but does not mean you will get the benefit.
Countless stories abound how GM documented all the things Toyota was doing in their factory in Japan and tried to replicate in the US - but failed. And we see that quite a lot industries - competitors hire people from the other organisation (or the same consultancy!) and then try to copy what worked elsewhere - and it usually fails expensively, spectacularly, and hurts a lot of employees, shareholders and stakeholders.
The simplest way to deeply understand this is a story about a piano made by a world famous piano maker. A wood furniture carpentry company decided to move into the piano manufacturing business as they had the same required tools, they could buy the same materials, and they thought they had the same skills required. So they bought a piano and dismantled it, making notes and designs about how to assemble. Then they assembled it back. But once it was back in "1 piece" there was a problem. It did not sound like it had. So they tried to manufacture a new one from their instructions. And they succeeded in making a pretty good replica of a real piano, but once again there was the problem - it did not sound right. So they got out of the piano making business (wisely). They lacked the "secret sauce" of being musically minded and aware how all the complexity of sound generation, amplification, transmission integrated with the different moving complicated parts of a piano.
And that's also what agile is - the practices help - in the same way that knowing what the keys of a piano are what notes. But playing a piece of beautiful music on a piano is differently from knowing things about music and piano operations. Yes the analogy does stretch to "practice is required, and feedback" to get them right.
But more importantly it is the secret sauce - it is the agile mindset that causes these agile practices to evolve into something unique for the organisation and its context. Some practices are individual targeted (like disciplined arrive on time to meetings), some are pair targeted (like pair programming to create, quality assure, reflect, learn, and make better realtime), some are team targeted (like whole team planning game), some are larger organisation targeted (like town hall meetings), some are senior management targeted (like go-and-see/use-your-legs reporting walks). And on and on :)
It is much more important to be agile than to do agile!
For more and deeper thoughts about agile check What Is Agile For You What Is Agile For Us. Thankyou!
:)
The previous 2 attempts at this (Agile In A Nutshell and Agile In A Nutshell Part 2) I like and I teach fluidly. But I also add the following nugget when I am teaching.
Where did these agile manifesto, the 12 agile principles, and especially those 10,000 odd agile practices (half of them technical/technology focused like pair programming; and half of them people/organisation/management/process focused like standup meetings) come from?
Well it's clear where the agile manifesto was written and by whom in 2001 - 17 world-recognised software engineering consultants, coaches, managers and all importantly - practitioners.
And it's clear as well where the agile principles were written and by whom in 2004 - the same experts that formulated the agile manifesto.
But what about those 10,000 agile practices?
The agile practices have been observed by team members, team managers, coaches, consultants, and other observant people ... of high performance teams. These observers have then documented them online, or in books, and have presented them at conferences as well as internally.
This means that we're still discovering practices all over the shop/place that help organisations become quicker and nimbler.
In my opinion, the smartest organisations are recognising their own unique practices that are giving them competitive advantages, and keeping them secret. The even smarter organisations are making their unique practices transparent and world-wide accessible because they realise others may contribute small tweaks that give even better performance - ala open source.
They also recognise that thinking is really hard to replicate and their organisation as a whole organism is thinking differently and hence behaving differently. Behaviours are easy to observe and replicate, but does not mean you will get the benefit.
Countless stories abound how GM documented all the things Toyota was doing in their factory in Japan and tried to replicate in the US - but failed. And we see that quite a lot industries - competitors hire people from the other organisation (or the same consultancy!) and then try to copy what worked elsewhere - and it usually fails expensively, spectacularly, and hurts a lot of employees, shareholders and stakeholders.
The simplest way to deeply understand this is a story about a piano made by a world famous piano maker. A wood furniture carpentry company decided to move into the piano manufacturing business as they had the same required tools, they could buy the same materials, and they thought they had the same skills required. So they bought a piano and dismantled it, making notes and designs about how to assemble. Then they assembled it back. But once it was back in "1 piece" there was a problem. It did not sound like it had. So they tried to manufacture a new one from their instructions. And they succeeded in making a pretty good replica of a real piano, but once again there was the problem - it did not sound right. So they got out of the piano making business (wisely). They lacked the "secret sauce" of being musically minded and aware how all the complexity of sound generation, amplification, transmission integrated with the different moving complicated parts of a piano.
And that's also what agile is - the practices help - in the same way that knowing what the keys of a piano are what notes. But playing a piece of beautiful music on a piano is differently from knowing things about music and piano operations. Yes the analogy does stretch to "practice is required, and feedback" to get them right.
But more importantly it is the secret sauce - it is the agile mindset that causes these agile practices to evolve into something unique for the organisation and its context. Some practices are individual targeted (like disciplined arrive on time to meetings), some are pair targeted (like pair programming to create, quality assure, reflect, learn, and make better realtime), some are team targeted (like whole team planning game), some are larger organisation targeted (like town hall meetings), some are senior management targeted (like go-and-see/use-your-legs reporting walks). And on and on :)
It is much more important to be agile than to do agile!
For more and deeper thoughts about agile check What Is Agile For You What Is Agile For Us. Thankyou!
No comments:
Post a Comment