You was probably redirected here from the old www.notesfromatooluser.com address which we will no longer use.

Don’t worry, you all the content from the original site is here and you old links will keep working.

Thanks for your patience

Mark

Jonathan Rasmusson offers the Drucker Exercise a simple way to get a team to gel at the start of a project. I think I might use this with the next team I coach to help break down those initial barriers.

The Mostly Free Detroit Agile Conference a great little conference in Dearbon Michigan (a bit far from Ottawa). Which leads to Matt Heusser: Conferences on the cheap – Matt offers ways of doing conferences for much less than the expected rate.

I keep on hearing about Continuous Deployment and while I think that most teams are not ready for this by a long shot – its one hell of a goal. Eric Reis introduced me to a great case study from Ash Mauyra. The downside of being an outside coach is I rarely get to see clients make it to this level. Usually they let go of their outside consultants long before they get to this stage. Way to got Ash.

Over at Cutter Jim Highsmith has some good reminders around Self-discipline and Self-organization. Short, simple and sweet.

A very large list of on line collaboration tools. Might be useful assuming that you feel you really need distributed teams (see Self Inflicted Agile Injuries).

The statement is very simple:

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and
• thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

I would like to add to that an echo what Chris Matts and Olav Maassen have already said:

So what is the difference between Leaders and Leadership?

A leader feels like a commitment (something we only like if we have to):
“Do it this way if you want to be part of my club.”,
“My way or the highway”,
“You’re either with us or against us”

Leadership feels like an option (this is what we like as it allows freedom of choice):
“Here is a way you can do it, it worked for me in a certain context.”,
“You might want to check out X it seems related to what you’re doing.”

My goal is not to tell you who to develop software. My goal is to help you deliver great software and to challenge you to do more than you ever have before. Whether we use Scrum, XP, Lean, Kanban or some new technique doesn’t matter to me. What does matter is helping people achieve great things.

This week we open with a pair of posts around TDD. First up Scott Miller of Atomic Objects ran a simple experiment: Faster, better, cheaper! TDD wins in a simple experiment and then earlier this year Mike (GeePaw) Hill wrote: How TDD and Pairing Increase Production a good explanation as to why it works.

Xavier Quesada Allue aka Mr Visual offers: Build a taskboard in 10 steps.

Not a blog post but a useful tool: Sonar from Codehaus may give a way of measuring some (but not all) of your technical debt.

Dean Leffingwell uses Little’s Law, Queuing Theory and Starbucks to show us why large backlogs are not Agile: An Agile Illusion: How That Nice Backlog is Actually Decreasing Your Team’s Agility

Anyone who has taken Agile Training from has heard my remarks about team size. Johanna Rothman gives us: “Ideal” Team Size and Ratios – I’m with her more 9-10 people on a team and you will get separate sub teams forming. On the subject of how many testers/writers does a team need? I like to start with one of each and add developers until they’re at capacity.

Richard Lawrence is chugging away and creating new versions of Cuke4Nuke – a version of cucumber that allows you write your step definitions in .NET: Screencast: Testing Web Applications in .NET with Cuke4Nuke and WatiN

Michael Dubkaov shows us why its a good idea for developers to have some slack time: Kanban Psychology. Can You Say No?

Agile works on the basis of a few simple principles:

• Short Feedback loops – which leads to iterations, TDD, …
• Radical Transparency – which leads to daily standup, demo/review, …
• Face to Face Communications – which leads to high trust, group problem solving, …
• Value – which leads to eliminating waste
• Continuous Improvement – which leads to retrospective, adoption of engineering practices.

Thinking back on every project that I’ve ever worked on (Agile or not) the quality of communications was a good predictor of the success. So when we run distributed teams there has to be a focus on making the communications work.

At best the typical approach to this problem is to buy web cams, fancy video conferencing software and conduct our meetings sitting in front of them. But that misses the point – these devices improve the quality of communications but not enough. They don’t build trust. To really build trust you have to meet face to face for at least a week. Unfortunately trust is weakened through the course of the year, so it has to be renewed. At a minimum team members need to visit each other twice a year.

So if you really want to get a high performing team – don’t underestimate the real costs, budget for travel – a minimum of twice a year to build and maintain trust. Don’t short change your distributed teams.

Matt Heusser takes on one of my favorite recent peeves with: The Fishing Maturity Model.

Gojko Adzic writes about a recent XPDay 09 session: Shock therapy agile adoption at 7Digital. The good news with this shock therapy is that no humans appear to have been harmed in the process.

High Performance teams (see: "The Wisdom of Teams" by Jon Katzenbach and Douglas Smith) is important background for Agile teams. In “What makes a true team” The Financial Post has effectively done a good job of summarizing Katzenbach and Smith.

Looking for good Lean games, I was reminded of the Theory of Constraints dice game: What is the Dice Game or Match-Bowl Experiment? (quick description) and The Dice Game(s) – better explanation and a chance to fire people if the dice don’t their way

Like clock work every 2-3 months someone on the Scrum Development mailing lists asks: “Can the Product Owner and the Scrum Master the same Person?”. Thanks to Boris Gloger we now have 10 reasons to say no.

We’ve all seen the results of individual rewards – pay someone to fix bugs – you will breed bug writers. Reward Firefighters (on a team) and you will get firefighters. Laszlo Szalvay wrote: Personal Heroics vs. Team Success.

Today my system is a little closer to a hybrid of Mark Forester’s AutoFocus and Francesco Cirillo’s Pomodoro Technique. I still use MLO as my task manager but on a more granular level than I used to. Instead of slaving over MLO constantly now I use to help generate my list for the day. I use MLO to keep track of a large list of tasks. Mostly I just use the outline to remind of thinks I want to tackle. Daily I glance at the TODO view to make sure that there isn’t anything that is date sensitive that I’ve lost track of. Once it comes to committing to tasks for a day I often use Index cards using MLO, email and anything else as inputs. At the end of a day (sometimes two) I take anything that remains in the card and put into MLO. Then I tear up the card that’s probably the most fun part.

Other habits

• I sweep my tabs in firefox every few days and move stuff to reading lists in MLO.
• Once/Twice a week I go offline and go through my email.
• Once a week I take some time to reflect – what is going well; needs improvement; what need do I have the energy to improve; what one thing can I do next week to improve it. Aka a retrospective. This is the hardest one to maintain – because you’re tempted to skip it and get more "work" done. Yet its the most important because it drives real improvement.

I use the Pomodoro Technique for:

• a reminder to stay on task
• a way of doing rough estimation every morning

Also on a two monitor setup under Win7 I dock MLO on the far left and leave it in outline mode where I can always see other things I want to do.

Other tools I use: ClipMate Clipboard Extender – because it allows me handle more than one item in the clipboard and to clean (i.e. remove html etc).

Preparing for TEDxOttawa this past I saw a couple of great talks: Dan Pink on the Surprising Science of Motivation (hint individual rewards don’t work) and Dan Gilbert on Our Mistaken Expectations (he demonstrates that we’re really bad judges of value).

Henrik Mintzberg revisits Dan’s point to say: No More Executive Bonuses!

I love seeing Agile applied in interesting places and seeing how it adapts – so I offer you the Agile Lawyers Association – it seems like a great idea but the website needs a bit of work.

Michael Sahota visits one of favorite topics – Joseph Pelrine and “Coaching Self-Organizing Teams”. I wrote about this last year: Coaching Self Organizing Teams and Part II.

Finally Ilja Preuss gives a some great tips on keeping time in a meeting (Agile or otherwise).

Joe Little shares his: Agile Principles – examples: all WIP is bad, bad news doesn’t get better with age, You learn the fastest by small mistakes.

Ilja Preuss says something that’s been on my mind for a while: Index Cards are Tools, too!

Johanna Rothmann tells “How Not to Win Friends and Influence People” – I’m only disappointed that she didn’t name names.

Finally Abby Fichtner reminds us: Agile Leadership: Methodology Ain't Enough

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.