Words, words, words
Agile FAQ and MTA
A fellow agile coach told me recently about his project to write the Ultimate Agile FAQ list - solutions to problems people recurrently have when installing agility somewhere. There were sparkles in his eyes. My reaction may have been harsh.
I've started wondering why we feel compelled to write FAQs about agility when the Most Typical Answers are always the same - "Yes, it's important," "It doesn't matter (as long as you do it one way or another)," "Trust your judgement" and "It depends."
"Yes, it's important."
Typical answer to questions like "do I really have to write tests before production code?" or "I don't like pair-programming, do I still have to do it?" Don't get fooled. These aren't real questions - someone is just asking for permission to do something the easy way without having to face consequences (remember - "Mommy, do I really have to wash my hands ?"). You may decide the person is wise enough to understand the "right" (?) answer - I'm not going to tell you which it is - but were the person wise enough, they wouldn't ask the question in the first place. They'd try and experiment not following a practice to see how it goes, and would accept to rock the boat on their behalf. So be patient, smile and remain firm. Yes, it's important to write tests before production code. Do it.
"It doesn't matter (as long as you do it one way or another)."
Typical answer to questions like "What tool should I use to track progress - Excel or Marker&Paper?" Yes, I know, you have your own preference and I have mine. Face it, though. It's not about how you (or I) would do it, but how they will. I find it's more efficient to leave to the doer the responsibility of chosing the tools work best for them. It engages them toward action instead of submission - or rebellion. More important than your relationship with them is their relationship with their work. So take a deep breath, stop (believing you have the power of) controlling others, trust them and nurture them. What's important is to track progress. The way the tracker prefers doing it is important too, and it's up to them to choose.
"Trust your judgement."
Typical answer to questions like "On what practice should I focus for now?" or "What techniques do I need most beside agility?" Typical answer could be "all of them" or "it doesn't matter" but that's not what the person's ready to hear, really. Again, it isn't so much a question than an attempt to delegate you the responsibility of a learning process. Unlike the "Do I really have to..." questions, "What do I need to do now?" questions bear some hope though, for they're open questions. The person is ready to try out something, and maybe the best thing they could try out is thinking for themselves.
"It depends."
Typical answer to questions like "How do I get my manager support our learning TDD?" or "My team and I want to go agile - where do we start?" I like questions that bring up "it depends" answers. It means they're context-sensitive and that you'll need to assess the situation in some way before being able to give some practical, useful answer. Since answers to such questions depend from context and every context is a bit different, giving more precise answers than "it depends" prior to knowing more of the context bears the risk of creating an illusion - that the person may follow blindly the answer you've given. Of course, you may have valuable, relevent answers to more specific questions, wrapped with a context. And here's the dilemma - the more precise the question, the less frequently it's going to be asked. The more your answer will be valuable, the less it'll have its place in a FAQ list.
So - where does that lead us?
Should one write FAQs? Well, it depends. The way I get it, being agile has more to do with experimenting different things at different times than with litterature knowledge. And yet, FAQs on other subjects aren't useful. And also, others may know better that I do.
How do we get new ideas about what to try when we're stuck? It doesn't matter - as long as you seek to try something different everytime something isn't working for you.
Is it actually important to find answers to our burning questions? Yes, it is important. Honestly.
... And how much can we trust you on this? The answer to this question is left as an exercise to the reader ;^)
I've started wondering why we feel compelled to write FAQs about agility when the Most Typical Answers are always the same - "Yes, it's important," "It doesn't matter (as long as you do it one way or another)," "Trust your judgement" and "It depends."
"Yes, it's important."
Typical answer to questions like "do I really have to write tests before production code?" or "I don't like pair-programming, do I still have to do it?" Don't get fooled. These aren't real questions - someone is just asking for permission to do something the easy way without having to face consequences (remember - "Mommy, do I really have to wash my hands ?"). You may decide the person is wise enough to understand the "right" (?) answer - I'm not going to tell you which it is - but were the person wise enough, they wouldn't ask the question in the first place. They'd try and experiment not following a practice to see how it goes, and would accept to rock the boat on their behalf. So be patient, smile and remain firm. Yes, it's important to write tests before production code. Do it.
"It doesn't matter (as long as you do it one way or another)."
Typical answer to questions like "What tool should I use to track progress - Excel or Marker&Paper?" Yes, I know, you have your own preference and I have mine. Face it, though. It's not about how you (or I) would do it, but how they will. I find it's more efficient to leave to the doer the responsibility of chosing the tools work best for them. It engages them toward action instead of submission - or rebellion. More important than your relationship with them is their relationship with their work. So take a deep breath, stop (believing you have the power of) controlling others, trust them and nurture them. What's important is to track progress. The way the tracker prefers doing it is important too, and it's up to them to choose.
"Trust your judgement."
Typical answer to questions like "On what practice should I focus for now?" or "What techniques do I need most beside agility?" Typical answer could be "all of them" or "it doesn't matter" but that's not what the person's ready to hear, really. Again, it isn't so much a question than an attempt to delegate you the responsibility of a learning process. Unlike the "Do I really have to..." questions, "What do I need to do now?" questions bear some hope though, for they're open questions. The person is ready to try out something, and maybe the best thing they could try out is thinking for themselves.
"It depends."
Typical answer to questions like "How do I get my manager support our learning TDD?" or "My team and I want to go agile - where do we start?" I like questions that bring up "it depends" answers. It means they're context-sensitive and that you'll need to assess the situation in some way before being able to give some practical, useful answer. Since answers to such questions depend from context and every context is a bit different, giving more precise answers than "it depends" prior to knowing more of the context bears the risk of creating an illusion - that the person may follow blindly the answer you've given. Of course, you may have valuable, relevent answers to more specific questions, wrapped with a context. And here's the dilemma - the more precise the question, the less frequently it's going to be asked. The more your answer will be valuable, the less it'll have its place in a FAQ list.
So - where does that lead us?
Should one write FAQs? Well, it depends. The way I get it, being agile has more to do with experimenting different things at different times than with litterature knowledge. And yet, FAQs on other subjects aren't useful. And also, others may know better that I do.
How do we get new ideas about what to try when we're stuck? It doesn't matter - as long as you seek to try something different everytime something isn't working for you.
Is it actually important to find answers to our burning questions? Yes, it is important. Honestly.
... And how much can we trust you on this? The answer to this question is left as an exercise to the reader ;^)
Categories: Facilitator blogs
Back To The University
Octo Technology is pulling together a kick-ass event on July 2 & 3 - l'Université du Système d'Information. It's a mix-conference targetting software makers and executive managers, designed to have them both share their respective experiences with IT systems. Two days packed with top-notch sessions, prestigious speakers and experts from various horizons. It's going to be fun, it's going to be French.
I'll be there, hosting a session "Percevoir plutôt qu'être perçu" (translation left as an exercise to the reader) with my famous fellow Bernard Notarianni and a Change Artistry Clinic with a gang of colleagues.
For you agilists - you'll recognize yourselves - my friend and colleague Christophe Thibaut organizes within the conference a special training track on Test-Driven Agile Development.
Working at Octo, it's a unique and exciting experience to see how the whole conference is shaping itself, from early concepts to final integration. The great contents set aside, I'm impressed with the level of integration of the different sessions into a cohesive whole - something that I'm not accustomed to, as a regular attendant of conferences mostly organized in a distributed, decentralized manner. As an insider, it's nice to see colleagues talking about and beta-testing others' sessions. It's equally nice and refreshing seeing everyone focusing on the product as a whole, and not merely on their own session.
Face it - if you still needed a reason to learn French, here it is.July 2-3, 2008, Paris, France - Be There or Be Square!
I'll be there, hosting a session "Percevoir plutôt qu'être perçu" (translation left as an exercise to the reader) with my famous fellow Bernard Notarianni and a Change Artistry Clinic with a gang of colleagues.
For you agilists - you'll recognize yourselves - my friend and colleague Christophe Thibaut organizes within the conference a special training track on Test-Driven Agile Development.
Working at Octo, it's a unique and exciting experience to see how the whole conference is shaping itself, from early concepts to final integration. The great contents set aside, I'm impressed with the level of integration of the different sessions into a cohesive whole - something that I'm not accustomed to, as a regular attendant of conferences mostly organized in a distributed, decentralized manner. As an insider, it's nice to see colleagues talking about and beta-testing others' sessions. It's equally nice and refreshing seeing everyone focusing on the product as a whole, and not merely on their own session.
Face it - if you still needed a reason to learn French, here it is.July 2-3, 2008, Paris, France - Be There or Be Square!
Categories: Facilitator blogs
Dissociative (Agile) Identity Disorder
People are always asking me if I know Tyler Durden.
No, they aren't really.
What they do ask me is, "what's the difference between Scrum and XP?"
What they do ask me is, "when should I do Scrum and when should I do XP?"
What they do ask me is, "what best practices of XP and Scrum should I combine?"
Strangely enough, very few ask me about DSDM or Crystal or Lean Software Development. That's too bad because I can't wait for the moment someone will ask me for differences between crystal meth(od) and LSD. DSDM doesn't bring the opportunity for interesting puns so I'm not in a hurry having to talk about it.
Seriously - I don't think there's much difference.
Yes, terminology differs. Yes, books don't have the same covers, and granted, Scrum has its own church. In essence however, the goal remains the same. Find a way to make great software now, tomorrow, everyday, that delivers the best business value given the current context. Various people have found various ways to tackle the question - or should I say, where to start.
I like to consider various agile methods as ways, as in martial arts. The Way of the Tiger. The Way of the Bare Hand. The Way of Clean Code. The Way of Team Alignement.
Starting tackling with the question of making great software with improving the estimations is as valid as starting with improving the test coverage or improving communication flow. We're talking here about complex, systemic dynamics. Problems are interrelated. So eventually, what will prevent you from improving your estimations will be communication flow. Or test coverage. Or: what will eventually prevent you from improving your test coverage will be communication flow. Or - you get the picture.
So eventually, by focusing on improving one bit and committing to it, you'll start improving the whole.
Wondering what's the difference between XP and Scrum is the same as wondering what's the difference between Aikido and Jiu-Jitsu. It does matter, to a certain level, and it really doesn't if you want to become a practitionner.
So here's my advice. Stop worrying if you've chosen the right method. Start with what you have. Or start with what looks the coolest to you. Or start with has best support community around you. Define what you're trying to improve and frequently check you're improving it. When improvement stops, ponder and wonder. And if you're out of ideas, get back to your favourite method books and see what they have to tell you on the subject.
And, oh, leave taxonomy to the dilettante and the scholar.
No, they aren't really.
What they do ask me is, "what's the difference between Scrum and XP?"
What they do ask me is, "when should I do Scrum and when should I do XP?"
What they do ask me is, "what best practices of XP and Scrum should I combine?"
Strangely enough, very few ask me about DSDM or Crystal or Lean Software Development. That's too bad because I can't wait for the moment someone will ask me for differences between crystal meth(od) and LSD. DSDM doesn't bring the opportunity for interesting puns so I'm not in a hurry having to talk about it.
Seriously - I don't think there's much difference.
Yes, terminology differs. Yes, books don't have the same covers, and granted, Scrum has its own church. In essence however, the goal remains the same. Find a way to make great software now, tomorrow, everyday, that delivers the best business value given the current context. Various people have found various ways to tackle the question - or should I say, where to start.
I like to consider various agile methods as ways, as in martial arts. The Way of the Tiger. The Way of the Bare Hand. The Way of Clean Code. The Way of Team Alignement.
Starting tackling with the question of making great software with improving the estimations is as valid as starting with improving the test coverage or improving communication flow. We're talking here about complex, systemic dynamics. Problems are interrelated. So eventually, what will prevent you from improving your estimations will be communication flow. Or test coverage. Or: what will eventually prevent you from improving your test coverage will be communication flow. Or - you get the picture.
So eventually, by focusing on improving one bit and committing to it, you'll start improving the whole.
Wondering what's the difference between XP and Scrum is the same as wondering what's the difference between Aikido and Jiu-Jitsu. It does matter, to a certain level, and it really doesn't if you want to become a practitionner.
So here's my advice. Stop worrying if you've chosen the right method. Start with what you have. Or start with what looks the coolest to you. Or start with has best support community around you. Define what you're trying to improve and frequently check you're improving it. When improvement stops, ponder and wonder. And if you're out of ideas, get back to your favourite method books and see what they have to tell you on the subject.
And, oh, leave taxonomy to the dilettante and the scholar.
Categories: Facilitator blogs
Dutch
French
German