George Dinwiddie's blog

Maybe you’re starting your first Agile project.  You’ve read books and blogs.  You’ve had training.  You think you’re ready, but it’s still a daunting prospect.  There’s just so much to remember—so many details.

Here’s a little cheat sheet.  Forget all the details and the various ways you can implement Agile for the moment.  Let’s simplify the picture.  There are just three essential legs that your Agile project needs to stand.  Get those in place, and you’ll do OK.  Keep improving all three, and you’ll do fantastically! (Continued)

My good friend, Steven M Smith, tweeted

AGILE methods emphasize realizing short-term OBJECTIVES rather than creating long-term objectives and trying to satisfy them.

I completely disagree with this statement.  I don’t agree that short terms objectives are the emphasis in Agile methods and I don’t agree that short term objectives are preferred over long-term objectives.  I think that Steve’s misunderstanding is rooted in the fact that he has only read about Agile methods, and not practiced them.  I think that it is impossible to get a deep understanding of Agile methods by reading without experiencing.  Therefore, I’d like to encourage Steve and others talking about Agile methods to try to get some experience before making such statements.  I’d also like to offer an explanation that attempts to clear up this particular misunderstanding. (Continued)

From time to time, a discussion rattles around the internet about “how can you tell how Agile you are?”  Over and over, I see people tout some variant of the Nokia Test as a way to tell if you’re Agile enough.  For the most part, I think this is hogwash.

Don’t get me wrong.  I’m all in favor of an Agile Team using something like the Nokia Test (or, better, Nationwide’s “Agile Tea Leaves”) as part of a self-examination and retrospection.  But any sort of discussion of conformance to practices is way too low-level for the executive team, or even middle management, of an organization.  Agile is the tool, not the goal.  The goal is to accomplish the things the organization wants to do.  Agile is a tool to allow the organization to accomplish its goals more reliably and in a more timely fashion.

With this in mind, I thought about what a high-level manager wants from the organization’s projects and the process used to develop them.  How can this manager tell if the development staff is doing a good job, or could be doing better?  I came up with this Do-It-Yourself Project and Process Evaluation Kit that such a manager can use, no matter what process the organization uses for development.  I think it will also be useful for Project Managers who need to report upwards.  Report in these terms, not in the details of the development process.

And here it is: (Continued)

Smaller organizations have an easier time adopting Agile development practices than do larger ones.  Once you get beyond a handful of teams, things start to get much more complicated.  Not only that, but no “cookie-cutter” approach seems to work very well.  Context always matters, and even more so in the large.

Bob Payne and I recently had a conversation with Sanjiv Augustine about the issues, and some ways of dealing with them.

I just got around to watching Josh Kerievsky’s talk, 10 Tips for Successful Agile Transitions.  He starts this talk with the tip, “You’ve got to do a readiness assessment,” and I think that’s incredibly good advice. He also says,

They should never, in a million years, have been doing Agile.  They were not ready for it…  They could not be helped.

Ouch! Are there really organizations that must be written off as hopeless? (Continued)

Bob Payne has posted a new podcast, Tips and Advice – Manifesto for Agile Software Development, where we talk about the principles and values of the Agile Manifesto.  I’m still a bit unused to hearing myself talk, and I’ve got a ways to go at getting the “um” monster under control.

If you’ve got the time, give it a listen and give us some comments.

I recently wrote about Agile Usability.  Now I find an article on StickyMinds, “Getting Agile With User-Centered Design,” by Jon Dickinson and Darius Kumana.  They talk about a number of issues that can come up.  My favorite bit is this:

We must actively challenge the mindset of divided responsibility–” You spec and design it; we’ll build what you spec.” Everyone should work toward the shared vision of a successful experience.

That says so elegantly what I tried to say in my article.

If I had time, I would re-read Tom DeMarco’s book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, because I have precious little slack in my own life, these days.  So it is that I just now got around to reading Jakob Nielsen’s article, Agile Development Projects and Usability, which William Pietri noted on the Agile Usability list on November 17.

The statement

“For a project to take interaction design and usability seriously, it must assign them ‘story points’ (i.e., resources) on an equal footing with the coding”

jumped out at me.  Alistair Cockburn wrote a thoughtful reply where he noted the same statement.  I agree with Alistair’s comments, but I’d like to comment on this statement from a slightly different perspective. (Continued)

Esther Schindler quoted me in her article, Getting Clueful: 7 Things CIOs Should Know About Agile Development, on CIO.com. Unfortunately, my advice got altered a little in the editing process. She says,

Consultant George Dinwiddie from iDIA Computing suggests using a burn-down chart to track project progress.

I actually recommend a burn-up chart to track project progress, and a burn-down chart to track iteration progress.  There are specific reasons that I think a burn-up chart is superior to a burn-down for tracking over the course of a project or release. I’ve been meaning to write a long post about this, but haven’t found the time. I just wanted to correct the record, in the mean time.

The full comments of my note to Esther: (Continued)

There’s a thread on the Extremeprogramming yahoogroup attempting to define Agile. John Roth started this thread with a trial balloon of ways to recognize an Agile project from easily observed practices. I have a bit of difficulty with this definition; I think that it’s too prescriptive and, while it could be a useful heuristic, would miss the mark in numerous cases. To my mind, it doesn’t zero in on the heart of Agile practice.

So what is the heart of Agile practice? In the ensuing discussion, Dale Emery posts a message the turns attention to feedback.

The whole team focuses intensely on producing accurate, relevant, timely feedback about product, project, and process.

I’ve written about the importance of feedback, before. Using feedback is not the defining aspect of Agile, of course. Using feedback is the basic mechanism for any control system. (Continued)