On Passionate Discourse

Life is too short to pull our punches. This article by Ron Jeffries really resonates with me.

What are you doing?

You've no idea how often my apprentices saying: "but wouldn't it be more efficient to..."

Agile work focuses on effectiveness. I recently asked my coaching colleagues: what is the difference between efficiency and effectiveness?

Efficiency: saving time, money or effort.

Effectiveness: producing powerful effects.

and

Efficiency: doing things right

Effectiveness: doing the right things

No wonder it's such a challenge to bring about the Agile paradigm shift. Depending on what you value, efficiency or effectiveness, your objectives, means and measurements will differ.

Think about that for a sec :-)

Blink and BNET

In Blink, staff writer from The New Yorker Malcolm Gladwell reveals that great decision makers aren't those who process the most information or spend the most time deliberating, but those who have perfected the art of "thin-slicing" — filtering the very few factors that matter from an overwhelming number of variables.

Hmmm, sounds like a great skill for a ScrumMaster, doesn't it?

Note: BNET is a great aggregator of free information on leadership and organizational behaviour, much of which is compatible with Agile principles. I subscribe to their newsletters, so I don't have to read all the ads on their site :-) but the site is searchable, which is useful.

Toronto Agile Coaches - March meeting

Late this afternoon the TorontoAgileCoaches group met for the second time, out in Stouffville. The eight of us managed to fill 6 hours with non-stop talk (and finally remembered to do introductions around 9pm!)

We discussed (among other things) inviting Fernando Lopez, a "partnership coach" to teach us some coaching strategies, particularly for conflict resolution on teams. Fernando recently had an article in the Toronto Sun.

Nothing beats swapping stories, tips, philosophies and leads with people close to home. If you are responsible for shepherding an Agile team and are in Toronto some time, drop by and join us!

Scrum Cheatsheet

This useful diagram comes from Graeme in Australia: Scrum Cheatsheet

Appropriate Agile Metrics

Since my contract in Virginia, where the client had a heavy PMO process, I've been thinking about measuring Agile teams, and the effect this has on teamwork. Robin Dymond and I have written up a short paper on the subject: Appropriate Agile Metrics. We know it's only the tip of the iceberg, but one has to start somewhere! Your comments are welcome... if you indicate your interest here by commenting, we can keep you up to date on Metrics developments.

Now, for a different client, I'm thinking about measuring individuals on those teams. My client says: how will we help individuals improve their performance? The pat answer is "if the team is producing their deliverables faster, with better quality, you've done enough". But this answer is not satisfying, and feels like a step backward for organizations that value personal development and make room for it in their budgets. On what basis will individuals and their managers discuss performance under the new Agile paradigm? Mike Bowler and I hatched a scheme last night at the Scrum dinner before XPToronto, with the help of some ScrumMaster buddies. It takes the "360" model of evaluation and heartily twists it in some interesting, and (we think) Agile ways! I'll keep you posted.

learning involves risk: go ugly early

I enjoyed reading Kevin Rutherford's "go ugly early" on silkandspinach. He starts with:

"This concept involves releasing early iterations of your products so you can allow your customers to interact with them and provide feedback. I'm not talking about releasing unstable or buggy products - I'm talking about releasing stable products that have limited functionality, but which telegraph the shapes of things to come."
-- Dwayne Melancon

He ends with:

Waterfalling never gave us the chance to create this kind of relationship with our customers.

Have a look.

You have not, because you ask not

"By believing passionately in something that still does not exist, we create it. The nonexistent is whatever we have not sufficiently desired."
-- Nikos Kazantzakis

Frequent reflection by Agile work teams creates the regular opportunity to remark on what is missing, so that we may express our desire for it. Why then are we surprised when it emerges?! Agile work is not magic - it only seems like it, some days.

Carnival of the Agilists - March Edition

The carnival has come to town again. Have a look for interesting Agile links and resources.

Alignment as an Agile Way of Life

Reading Mishkin's "The Art of Obstacle Removal" I became aware of something I do at work, mostly without thinking about it.

I often do very physical things in the team space, things that need doing, but which have an additional intangible goal. I pick up garbage after the team lunch. I move an information radiator so all of the team can see it. I put a partition where it blocks noisy traffic outside the team room. I help team members move furniture for better collaboration. I order a whiteboard. I shop for more thumb tacks.

What am I really doing? I am modeling alignment by making our reality match with the values we teach: picking up garbage says "we are all peers", making the big-visible-charts visible to all says "every person on the team counts", helping the team make the space work for them says "you are free to self-organize", physically blocking traffic and noise models the ScrumMaster's "sheepdog" role in protecting the team from distraction. I tend to enlist the help of at least one team member in these events, to amplify learning.

Agile work is not about practices, it's about culture, and cultural change happens deep inside people. But we can use actions and artifacts to model the interior changes we espouse and desire in others. I think that one key benefit of Agile work is the correction, the re-alignment it makes between what we know to be right, and what we do. Business people own requirements. Developers own estimates. Physical infrastructure need to foster collaboration. Compensation schemes must not pit people against one another. Teamwork requires respect. Managers must serve their teams.

I do believe that people absorb all this, whether they realize it or not. There is a reason that retention on Agile teams is higher than the average. I believe it is because, over time, people learn to treat each other honestly and respectfully.

The human mind is a marvelous thing, and in the background we are constantly synthesizing what we hear and see at work. And so, I pick up the garbage after my team's celebration lunch.

Emergent Documentation

It seems I may have coined a phrase on the ScrumDevelopment list with my post "Emergent Documentation". I had been hearing echos from the technical writing world that sounded to me like object-oriented writing (actually called "single sourcing")... and I mused aloud.

After posting to numerous tech writer lists, I then came up with an expert in my own home town, Montreal. France Baril of IXIASOFT is one of the people driving out DITA, an OASIS xml standard for documentation, and she's pretty excited about what it could do for the field of tech writing. Now, she's a crossover from the world of programming, and when I spoke to her about Agile she was on board right away! We're hoping to collaborate in the coming year, to advance this cross-pollination, and hopefully bring tech writers inside our iterative processes, where they belong, just like testers. (Read more about DITA for software documentation).

France spotted this related post on Agile book publishing - ah, we are not the only ones thinking about this! Wonderful. Please, do leave me a comment if you have any further input on this subject! And Tobias just told me about this one from an Agile book publisher! Hurray!

(Note: France will be at the Information Highways conference in Toronto later this month. I adore the title of the talk she's participating in... "I can eat glass, it cannot hurt me: choosing a CMS system with a minimum of chaos" )

Hardwired for Command-and-Control?

Something I recently saw made me wonder: is the drive to control built-in? Why do so many of us revert to this style under pressure, even while we believe collaboration gives better results?

Agile Work and Agile Software Development value collaboration so highly, it's built into the very methods we teach. Some of the Agile practices can be used without collaboration - but with the loss of real-time communication comes extra documentation, loss of quality and failure to meet plans. The success of Agile methods is predicated on an entire team being responsible to make and meet committments. This group accountability drives different behaviours: of necessity, collaboration displaces competition.

The shift to Agile values and practices is difficult - for many, it's a significant culture change. And with change comes stress, and with stress... fear and the urge to control. (I think this is the best argument for engaging an outside coach for the early stages of Agile rollout - an impartial third-party who can afford to challenge old habits that inevitably creep in. Well, if an organization is serious about Agile, that is - it's not always the case).

Agility comes only when the team is in control of the work. Whoa! What about the manager?! Managers (and leaders within the team, too) will need to understand their new roles, and work at behaving in new ways, in order to really support the team. The good news is: the whole team can help!

Giving up individual control for shared accountability is one of the harder shifts we need to make to get the benefits of working Agile. So, if you're feeling uncomfortable - rest assured, you're not the first. It's probably just growing pains.

Read about culture change at First American Real Estate as they have rolled out the Scrum methodology over the past year.

TradeStorm 2006

Now, more than ever, governmental and non-profit organizations need to shed heavy, lengthy and mis-conceived processes and find more effective ways to get important things done.

TradeStorm 2006: "Strategies and Tactics for Sustainability of Non-Profit Organizations" took place last week, organized by NewPath Network and hosted by Rotman Nexus. It brought together NGOs, not-for-profits and charities with professionals servicing that sector, to discuss such concepts as: social enterprise, business intelligence, social capital funding and SROI (Social Return on Investment). These are clearly burning issues, in these days of fickle and dwindling government funding: the conference unexpectedly reached capacity several days in advance. Busy people took time out from their tireless work to spend an afternoon and evening together: thinking new thoughts, stretching the boundaries of how things "should be done", and making important new connections.

Proceedings from the conference have not been posted yet, but they're coming, so check the website in the next week or two to see what you missed.

Who knows what will come of the seeds sown here? Check in again this time next year - but do it early, so you can get a seat!