This week I lead off with Ilja Preuss’s “The Aha-Experience Exercise” – this an exercise helps attendees highlight continuously review their training and share with each other what is working. The best part I saw Ilja mention this on twitter. I asked for details and week later I have this blog post. Ilja thanks.

Being late to the party I missed Dale Emery’s “Writing Maintainable Automated Acceptance Tests” last year when it first came out (examples in Robot Framework). Uncle Bob replied with a version for FitNesse.

Finally George Dinwiddie reminds us that you really can’t get “100% utilization” (or even close) out of your software developers.

Next week I intend to write a short piece on acceptance testing.

Virtual Team Member Dolly – from Lisa Crispin. Lisa talks about giving a remote Developer based in India a presence on her team. This is cool. Now if only we could erase the time difference

Testing Small Stories – another from Lisa Crispin. I so often hear from clients that it will impossible to slice their stories any smaller than 6-8 weeks for two developers. Its always possible and Lisa provides another tool to help.

You’re Just Going to Fail, So Don’t Bother – from Scott Downey. Ignore the awful myspace ads and read the content. He nails the difficultly of really doing Scrum/Agile – you will have to change your organization.

Simon Baker takes an interesting crack at measuring Effectiveness: “is used as a measure of the product stream’s ability to improve throughput and minimize failure demand, which allows capacity to focus on meeting value demand. It was inspired by the First-Time-Through (FTT) measurement used in Lean manufacturing to measure the effectiveness of a cell’s standardized work as a percentage of product made without any need for rework or scrap.”

Bob Hartman writes: “New to agile? Keep it very simple”

In the next few weeks I look forward to having some time to breathe and do some more writing.

There are no best practices – only good practices in your current context. The whole idea of Best Practices implies that you can learn them once and apply them in any context. I prefer the notion that there are some ideas. Sometimes they work well, sometimes they don’t. Try lots of small experiments and learn. Also the idea ‘Best’ implies there is never any room for improvement – ‘Good’ is a better word because it holds open the promise that tomorrow might be better.

So please no more best practices – only “Good Practices in the Current Context”.

You have been hand-picked by your company to join an exciting new division.  You have over-heard that this new group will be ‘Agile’ but what does that mean?  Is this the career opportunity you’ve been waiting for?  Is this a chance to make your mark and be part of something big? Did someone just say “making games”?

On March 9, Bryan Beecham will bring us through an Agile workshop to help sharpen our team skills.  We will simulate the experience of a company that has just decided to become Agile. Regardless of your experience in Agile there’s a spot for you on one of our teams.  To understand Agile you can’t just read about it, you need to experience it.  Come and join us for an exciting evening of learning and discovery as we tackle some interesting problems by applying Agile principles.

Location: 343 Preston Street, Ottawa, ON (Detailed directions)

When: Tuesday March 9th, 2010

Time: Networking from 6:00-6:30; meetup from 6:30-8:00

Shamelessly copied from the Agile Ottawa blog

Shu-Ha-Ri comes from the Japanese Martial Art of Akido. Roughly speaking it equates to:

1. Shu – learning the basics, repeating movements and following commands without questioning.
2. Ha – breaking with tradition, finding exceptions, asking questions.
3. Ri – transcendence – there are no longer individual techniques or practices, instead everything can flow.

This progression has often been used in the Agile Community to remind people not to question or alter the basic practices when they’re still learning to become Agile. (Thanks to Alistair Cockburn for introducing us to the idea in his book: Agile Software Development: The Cooperative Game). Rachel Davies has recently come across some harmful uses of the idea and talks about them in: Shu-Ha-Ri Considered Harmful? I don’t entirely agree with Rachel but that will be the subject another blog post.

Mishkin Bertieg, Agile Trainer, has been creating OpenAgile a new Agile Methodology: Comparison of OpenAgile with Scrum.

Chris Matts and Olav Maassen (the Real Options guys), use a comic to explain how Real Options work with Blacl Sholes (hint they don’t). BTW to make sense of this comic you need to have a good understanding of Real Options.

En Francias: AGILE n’est pas un DOGME! – apparently there are still some trainers/coaches out there who think Agile is a religion.  Sad.

Cory Foy writes two thought provoking pieces about the state of the Scrum Alliance: They Could Have Been Contenders and ..but if the Scrum Alliance Can’t Do It, Who Will?. I don’t know enough about the politics of the Scrum Alliance to comment on the first piece although I did write about this last year: “Opinion: Will the Scrum Alliance Change its Stripes?”. Frankly the first step will be more openness and transparency.

Finally David Bland has another piece on the misuse of Velocity in Scrum/Agile: Sizing Up the Enterprise.

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

Like clockwork every month, someone on one of the Agile Mailing lists asks a question about “comparing velocity between teams” or “benchmarking data on velocity.” Before we examine the problem, let’s recheck what velocity is—the amount of work completed by the team/time taken to complete it. The amount of work is usually measured in Story Points (a relative measure of size). So velocity is just the number of points the team completes in the average iteration/sprint.

The underlying point is that Agile/Scrum teams use relative estimation (i.e., is this story/feature bigger or smaller than our standard story?) vs. the traditional approach of absolute estimation. The problem with comparisons, benchmarking, or any other attempts to compare velocity is that my story points ≠ your story points, because different projects use different standard stories. They work in different problem domains, and they have different people.

If we could compare velocities across a team, what would happen? Estimation of inflation. Team Better hears that Team Good has just finished their release planning meeting and estimated that they will achieve 200 points before the next release in 6 iterations/sprints. Immediately, Team Better knows it needs to produce more points and so estimates 300 points. Now along comes Team Best. . . .

To my mind, the real value of Velocity and Release planningis giving the Product Owner a good idea of what can be achieved before the next release. For one client, our release planning told us that the list of required features was roughly double the amount of time in the project budget. For first three iterations, the Product Owner denied reality but eventually the team’s actual velocity made it clear that trade-offs were required.

What matters far more than comparing velocity is whether each of the teams arrived at a common understanding of their work. After each iteration, has the team delivered value? Does the Product Owner always have a good idea of how much value has already been delivered and how much they can expect to be delivered?

Anytime you’re about to spend time and money on something, ask if the customer would be prepared to pay for that.

BTW I smell an Agile FAQ coming out of this and other questions.

Hopefully, it’s obvious to all and sundry that this blog has been transformed. As you can see, I’m in the middle of launching a new business site: Agile Pain Relief Consulting. The blog will always be called “Notes From A Tool User,” and notesfromatooluser.com will always work, but from now on it will be a 301 redirect to this site. The upshot—please do not adjust your set. It is functioning as intended.

The transformation is far from complete—some structural work and a lot of writing are left to do. Please excuse the mess. In the meantime, I’m going to get this blog back on track.

This week’s Quick Links:

We’re hearing a lot about Toyota’s woes in the news. Hal Macomber thinks the common claim that Toyota lost its focus in attempting to become the world’s largest car manufacturer is wrong—read: What Is Going on with Toyota and Toyota’s Lesson for Project Managers for more.

Dave Nicolete (riffing on some comments by Dave Rooney) suggests a simple way for estimating a team’s initial velocity for its first few iterations. This is the problem that teams new to Agile have. Management wants an initial estimate of how much work will get done before the product is released and the team doesn’t have enough experience to give it.

Sandy Walsh (a former colleague from Andyne Computing) is writing an interesting series on the importance of readable code: A Tale of Two Code Bases and Your Code is the Other Team Member .…

In Goal-Oriented Daily Stand-Ups, Joakim Karlsson offers the idea of setting a daily team goal, which helps to ensure that the individual tasks toward the team’s goals.

In the early ’80s, the department of Computing Science at Queen’s University got its first Vax 11/780. At the time, my father complained that professors no longer talked but just emailed each other even though their offices were only 10 feet apart. Phil Jeffs notices the problem continues: Don’t email me. I’m sat right next to you.

Sorry for missing a week. I’ve got serious business site renovations going on. Stay tuned for an announcement in the next week or two (note that this is an estimate and not a commitment).

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 is a great little conference in Dearborn, 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—it’s 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 that I rarely get to see clients make it to this level. They usually 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).

In December, Liz Keogh, Eric Willeke, and Jean Tabaka got together at the Rally offices in Boulder. In only a day, they drafted a statement of beliefs and respect. If we all agree to follow them and respect each other, many of the rifts that have appeared in the Agile community in the past year will start to heal (see the comments under Jean’s post “Escalation” for examples of those rifts. Also see the Cutter 2010 predictions).

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 on the subject:

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 how 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.

I’m back in the saddle after having taking a couple of weeks off the Internet.

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 be 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 me has heard my remarks about team size. Johanna Rothman gives us “Ideal” Team Size and Ratios—I’m with her. If you have more than 9–10 people on a team, you will get separate subteams 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 it’s a good idea for developers to have some slack time: Kanban Psychology. Can You Say No?