Category: Individuals and Interactions

Defect Prevention

Jim Shore posted a nice Introduction to Agile for QA People on his blog.   I thought it was great as far as it went, but it didn’t explicitly mention some of the things that I have found to be extremely important, at least, in the corporate IT environment.  I tried to leave a comment there, but I was too long-winded for his comment system.  (If you’ve not read his post, please do so now.  I’ll wait.)  Here’s the full text of my comment:

Jim, I think you’ve left out, or under-emphasized, an aspect here.  It’s perhaps not explicitly called out in the XP literature, and isn’t mentioned by Scrum (neither of which mention the QA department as an entity), but it’s an important aspect in successful Agile adoptions in corporate IT environments, in my experience.  That aspect is Defect Prevention. Read More

DIY Project/Process Evaluation Kit

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.DIY Project/Process Evaluation Kit

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: Read More

A corporate benefit to self-managed teams

Thanks to Esther Derby’s amplification on Lining Up Priorities, I came across Tony Tjan’s blog posting, Four Simple Ways to Make Your Employees Happier.  Tony says,

There is a very simple secret to long-term employee loyalty and retention and it is not money, perks, or stock options. It’s giving them meaningful roles.

This is not an idealistic motherhood-and-apple pie dream, but rather a basic condition of human behavior and psychology that many businesses and leaders often forget: people are driven as much or more by intrinsic meaning as they are by extrinsic rewards.

This is, I think, a little-discussed benefit of the self-management that’s found on successful Agile teams–the employees are motivated by creating value rather than just by pay and perks.  People want to do well for you.  Give them an opportunity and an environment where they can do so.

The role of architect

Thanks to a pointer from Kent Beck, I’ve just read Alan Keefer’s post, Taking Responsibility.  This is probably the best description I’ve ever read of the role that a software or system architect should take.

And it’s very different from the role I’ve normally seen them take.  Most software architects got the title because they were very good software developers.  I’ve seen far to many who assume that they should now do the “highest level” of the work they’ve been doing, that of the system level design, and leave the more mundane work to those who are still software developers.  In other words, they’re considering their promotion from the point of responsibilities they’re shedding rather than those that they’re taking on. Read More

Enterprise Agile

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.

They could not be helped.

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? Read More