The agile reboot is underway... the company says it is using "Agile" yet there is no methodology/process/framework that defines "Agile" is there. So it is not a very valid statement to say we do Agile. Agile is a philosophy - defined by 4 comparative value statements and 12 principles. So the top-dog rightly focuses the company on one well defined Agile process - Scrum. Great move for a change initiative. Focus is going to be important. Now we need to discriminate the change - what is it that we want to quit doing and what do we wish to start doing? We must label these things.
Typically it is easy - one applies the Waterfall label to the old and the Agile or Lean label or more specifically Scrum/XP or Kanban to the new. That has worked for me in the past very well. But what to do when it doesn't work? What to do, if the company has brainwashed itself into thinking it is practicing Agile.
I must resist the Stockholm syndrome. That culture of just get it done - is not a process - and by any definition of the word - it is not Agile.
But then perhaps in a moment of desperation they look around and ask - "what are the principles"? What is the foundational philosophy of this Scrum process? We want to know these so that we will know where we can customize this process. We want to know what we can bend, what we can circle around - how can we keep doing what our culture dictates and just install the scrum.
How many times does a process get broken before it is tried - before it is adopted - before any experience what-so-ever with the designed process, we say "we can't do that - we must change it" - not our selves - we change the process. We all know that it is easier to change something else than it is to change ourselves. So we search for the exceptions that will prove the case that process step 23-C will not work here - we have decided that we are so special that the Sun actually revolves around us.
Scrum designers have done a wonderful job of defining a very small list of things that must be done - if you do them - then you are doing Scrum. If you break the rules, bend the framework to suit you special case - well then do you think you will get the desired outcome?
So that first question of what are the principles may be more subversive than it appears. Because if you slip up and define a gap in the principle fabric then there will be a hole for the monsters to slip back through. Given that I'm not going to be able to articulate each principle and you will not quite understand my meaning just perfectly. Is this not a slippery slope.
So if you want to customize your process - one that has been built/designed/tested/refactored over years by experts - and you think you are qualified to state when we can just re-jigger this piece, skipping that piece, it is just a waste, never understood it anyway, so we'll just do it our way. Well I don't want any part of your bastardization.
If you want the principles - they were stated - as best we have found in the Manifesto. Don't re-invent the principles - just re-use them.
Exercise :: Mapping Engineering Principles to Agile Practices (PDF) by David Koontz
Another Exercise: The Definition of Done & Ready!
See Also:
Exercise:: Mapping Engineering Practices to Agile Principles article by David Koontz - includes PDF downloadable exercise.
 |
| Three of the 12 principles of Agile with engineering practices mapped to them (TDD, Pair Programming, etc). When we tried to map our existing practices - we found we didn't have very many disciplined practices, so this is a mapping of a desired future state. |
I must resist the Stockholm syndrome. That culture of just get it done - is not a process - and by any definition of the word - it is not Agile.
But then perhaps in a moment of desperation they look around and ask - "what are the principles"? What is the foundational philosophy of this Scrum process? We want to know these so that we will know where we can customize this process. We want to know what we can bend, what we can circle around - how can we keep doing what our culture dictates and just install the scrum.
Agile Culture Series Reading Guide Written by: Michael Sahota
How many times does a process get broken before it is tried - before it is adopted - before any experience what-so-ever with the designed process, we say "we can't do that - we must change it" - not our selves - we change the process. We all know that it is easier to change something else than it is to change ourselves. So we search for the exceptions that will prove the case that process step 23-C will not work here - we have decided that we are so special that the Sun actually revolves around us.
Scrum designers have done a wonderful job of defining a very small list of things that must be done - if you do them - then you are doing Scrum. If you break the rules, bend the framework to suit you special case - well then do you think you will get the desired outcome?
So that first question of what are the principles may be more subversive than it appears. Because if you slip up and define a gap in the principle fabric then there will be a hole for the monsters to slip back through. Given that I'm not going to be able to articulate each principle and you will not quite understand my meaning just perfectly. Is this not a slippery slope.
So if you want to customize your process - one that has been built/designed/tested/refactored over years by experts - and you think you are qualified to state when we can just re-jigger this piece, skipping that piece, it is just a waste, never understood it anyway, so we'll just do it our way. Well I don't want any part of your bastardization.
If you want the principles - they were stated - as best we have found in the Manifesto. Don't re-invent the principles - just re-use them.
Exercise :: Mapping Engineering Principles to Agile Practices (PDF) by David Koontz
 |
| Lovely space at Microsoft NERD center. Mapping Engineering Practices to Agile Principles at Agile Games 2011 in Cambridge. Note circular whiteboard - awesome! |
 |
| Trusted & Motivated People - a label for one of 12 Agile principles is well supported by 5 practices. |
 | |
| Jay summing up 'User Stories' supports 7 principles |
 |
| David Koontz Pointing at the root of our principles Agile Manifesto |
Another Exercise: The Definition of Done & Ready!
See Also:
Exercise:: Mapping Engineering Practices to Agile Principles article by David Koontz - includes PDF downloadable exercise.
The 12 Principles Ice Breaker by Gerard Chiva on Oikosofy
The Big List of Agile Practices - NOOP, Jurgen Appelo an alternative list of engineering practices to map to the Agile Principles
The Big List of Agile Practices - NOOP, Jurgen Appelo an alternative list of engineering practices to map to the Agile Principles
Comments