Another opportunity to tighten it up, thanks to Robbie Mac Iver and Houston APLN.
Archive for the ‘Facilitation’ Category
I’ve put these together – XP2010 and Better Software – because they occur one after the other. So I may be insane for considering this, but I’m just so psyched that these conferences are embracing my work on Facilitation Patterns and Antipatterns.
Now to work on the second deck of cards for March (SDC2010) – I want to have two variants of the deck ready to go for all three conferences.
Related posts
I love talking about this stuff, and David Giard gave me the opportunity at the CodeMash 2010 conference.
http://technologyandfriends.com/archive/2010/02/01/tf0067.aspx
Related posts
This one has me psyched – my first time presenting at a European conference, and more validation through interest in my work facilitation patterns and antipatterns.
Related posts
I get to facilitate an Open Space in my own home town! Woohoo!
Related posts
It was sad for me – I couldn’t do it last year because I was already booked for another Open Space. I’m delighted that they’ve invited me again this year, and that I’m available. This is my people!
Related posts
In developing and delivering training on Agile Software Development, I frequently talk about the group ownership and individual commitment. I also talk quite a bit about the formation of the team, the group responsibility, and the mutual respect.
This is very cool stuff.
When I get to the Agile Manifesto, I dig into what the four main concepts mean to us as we embrace Agile.
Right now, what’s on my mind is the third value: customer collaboration over contract negotiation.
Here are some of the key points that I find in this statement:
- Contracts are only put in place so that we can enforce them when we believe that the other party has not met their obligations under the contract.
- Contracts imply a lack of trust.
- If you’re actually talking to your customer on an ongoing basis, then contracts generally become superfluous.
- Requirements specs and design specs are software contracts.
- See point #3.
As I’ve been doing coaching and training, I’ve had the opportunity to see a variety of different organizations and situations. What has become clear to me is this:
Some organizations that embrace Agile have a culture of openness, safety, respect, and friendliness, where the people who work there are happy to go to work each day. Those employees have a feeling of pleasure and pride in what they do and the people they get to do it with.
Then there are organizations that are built upon a Culture of Blame. Contracts are about blame. Specifications are – at least to an extent – about blame. Project plans, which on the surface are about predictability and budgeting and resource allocation, are also about blame. What I’ve seen happen in these organizations, more than once, is that Agile adoptions fail in the worst case, and struggle in the best case.
The problem is that their “leadership” (quotes intentional) are mired in Waterfall practices. The irony of this is that – while management is operating under the fallacious assumption that these practices work – these practices have been demonstrated repeatedly and measurably to fail.
“The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term “waterfall” in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970).” (from Wikipedia)
What seems to go hand in glove with this Waterfall mindset is the contract. These managers need to have specs and project plans so that they can figure out who is at fault when the project is late, over budget, or of low quality. Sadly, those of us who have embraced Agile – and many who still live in the Waterfall world – would tell you that at least one of those three – lateness, over budget, or low quality – is pretty well guaranteed.
Someone asked me recently whether it was possible to succeed in adopting Agile without there being a cultural change.
My answer is a resounding “no!” Without the move to a culture of trust and respect, without the true support – not just lip service or permission – of representatives of “leadership” at all levels*, Agile adoption is very unlikely to succeed.
A Culture of Blame is not always obvious – although frequently it is obvious. But there will generally be smells that a reasonably discerning individual can detect that make it clear that the Culture of Blame is present.
* I refer to this as Vertical Commitment or Vertical Buy-In. As a coach and facilitator, I believe that without ensuring that management shares the same language about Agile principles and practices, and without ensuring that they are committed to the success of Agile adoption, the culture clash is unendurable.
Related posts
Motto: That’s wrong.
Belief: It’s my responsibility to point out what’s wrong with other people’s ideas. I live in my black hat*.
Behavior: Points out the flaws and faults in everyone else’s approach. Does so without offering any balancing positives or alternatives.
Characteristics: Negative, sometimes superior, destructive, achieving satisfaction by negating others’ ideas.
The Negator sees their lot in life as poking holes in everyone else’s ideas and plans. While this is not, in and of itself, a bad thing, when exercised without the balance of alternatives or one’s own ideas it becomes a negative of its own.
The Negator may seem to be contributory and helpful at times, as their suggestions come across as helping you to see risks and dangers*. However, this behavior pattern, when exercised to the exclusion of balance, can become seen as the person’s identity, rather than one pattern of behavior among many.
* See Edward De Bono’s “Six Thinking Hats”
Related posts
Yes, this is just a brag post. 
At 2pm Central time today, I’ll be doing the first full delivery of the Facilitation Patterns & Antipatterns workshop at the Agile2009 conference.
Yes, I’m excited.
I’ve gotten great response from the folks I’ve told about it. Hopefully some of them will turn up.
Related posts
In planning for my workshop at the Agile2009 conference, I had my artist – Mike Ferrin – create the characters you’ve seen me add to my posts here. I’ve taken those characters to create playing cards, which will be used in the workshop.
(While I’m thinking of it, take a look at the sessions being offered by my fellow ThoughtWorkers at Agile2009 – some very cool stuff there!)
I thought you might like to see a sample of the cards. This is the back of the cards…
And here’s Superhero…
I hope I’ll see you at the workshop on Tuesday afternoon. I’m planning on it being fun!
