I’d like to share with you an interview conducted by Bill Fox for his 5 Minutes to Process Improvement Success project. My interview, “Measure Progress in a Way that’s Visible and Reliable,” is found on page 69 of the PDF.  You’ll also find interesting interviews with Karen Base, Kevin Schaaff, Hillel Glazer, Scott Ambler, Neil Potter, Bob Payne, Mike Bonamassa, Mario Hyland, Jeff Dalton, Paul E. McMahon, Karl Wiegers, Mary Lynn Penn, Ally Gill, Alan Shalloway, and Tom Cagley. And there are more to come in the future.

• Novice: Tarzan at the party.  Memorized phrases that can communicate simple needs in the moment.  “Beer good.”  “Where is the bathroom?”
• Intermediate: Going to the party–directions, time.  Interactive, task-oriented or social situations.  “May I go with you to the party?” “What time should we meet?” “How will we get there?”
• Advanced: Discussion about the party.  Can handle a broad range of concrete topics.  Think of the level of a Larry King interview.  “Who was at the party?” “What was the most interesting thing?” “Why did they say that?”
• Superior: Philosophizing about parties.  Able to converse about abstract topics. Think of the level of a Charlie Rose interview. “Why do we find parties fun?” “What purpose do parties serve in the survival of the species?”

Fluency, on the other hand, is a different dimension.  Fluency describes how facile we are at speaking or understanding. We might be fluent at the intermediate level, but not very fluent at the advanced level.

A recent discussion about the Agile Skills Project gave me the impetus to try to apply these concepts in terms of Agile software development.  Here’s the proficiency levels of self-organization that I proposed:

• Novice or Beginner:
  • Can find meaningful work to do without being directed.
• Intermediate:
  • Can find collaborative work to do without being directed.
  • Can pull information needed to identify work, or to enable collaboration.
  • Can identify impediments to own work.
• Advanced:
  • Can find ways to remove impediments to own work.
  • Can identify impediments to the team’s work.
  • Can find ways to remove impediments to the team’s work.
• Superior or Master:
  • Can find ways to advance the team’s ability to self-organize.

And the fluency levels:

• Successful occasionally
• Generally successful with patterns previously experienced
• Occasionally able to generate new successful patterns
• Generally able to generate new successful patterns

In accordance with the separation between these two dimension, one could be generally able to generate new ways to remove impediments in one’s own work (highly fluent at the Intermediate level), yet only generally successful with familiar patterns of removing impediments in the team’s work (modestly fluent at the Advanced level).

Many thanks to Willem for giving me this new (to me) way to look at learning.  I’d love some feedback on my application of these language learning concepts to the field of teamwork.

I had a fabulous time.  Through conferences such as this one, I now have dozens of friends from around the world that I rarely get to see.  I really enjoy getting together face to face.  Missa vitussa se poro on. (I hope I’ve spelled that correctly.)  And I spent time with friends that I previously only knew from Twitter and email.  And I met new friends that I’d not known before.  All of that was thrilling.  (I also didn’t get a chance to talk with some friends whom I know attended. Life is like that.)

I attended some great sessions.  I attended some sessions that were less great, but very interesting to me.  I attended some sessions that were great, but less interesting to me.  I didn’t attend any that were terrible.  I suppose there might have been some bad ones.  I heard rumors of such, but I’m not sure whether that’s an indication of the session or the expectations of the person reporting it.  I also didn’t attend sessions.  I didn’t attend some sessions because

• there was another session I attended instead,
• the session was full,
• I thought that I’d done something similar in the past,
• it was a “talking head” presentation (which I have a prejudice against),
• I wanted to give some energy to the Live Aid project to support Agile Philanthropy,
• I wanted to chill out in Open Jam and relax with casual conversation, or
• I forgot until it was too late.

I didn’t maximize my time.  There is no optimization for life.  Instead, whether doing something that seemed important or something that seemed trivial, I merely tried to be in the present time, in the present location.  “Be here, now.”  Or, as Lyssa Adkins said in Build Your Team’s Collaboration Muscle, “be in present time.”  I left Slack for myself, rather than fill every moment with The Most Important Thing.  I highly recommend this technique.

I could talk about specific sessions and events I found enjoyable or helpful.  I could talk about things that I found annoying.  Certainly not everything was perfect.  It’s a human endeavor, after all.  Instead, I’d like to talk about what can be done to make Agile 2010 even better.

Jim Newkirk, the Conference Chair for Agile 2010, invited me to the conference retrospective.  This was mostly populated with stage producers and stage assistants. I had been merely a stage reviewer, and was initially hesitant.  I was happy to find that I could add a little value to this retrospective, and I found that there was a topic about which I was passionate that was important to many.

There were many concerns about the session selection process for this year’s conference.  I had concerns both from the vantage point of a reviewer on the inside of the process, and from the vantage point as a session author on the outside.  Finding that others had similar concerns, and different concerns about the same process, I volunteered to collect some of those concerns, organize them and summarize them, and report them to Jim for use in planning Agile 2010.  I also want to collect suggestions for improving the session selection process.  Please send your concerns and suggestions to agile2010 -at- gdinwiddie.com or you may leave a comment on this blog posting.

Thanks for your help.

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

Frankly, it puzzles me that these conferences aren’t more highly attended. Despite my suggestions to Naresh, he insists that there be no admission charge. The only cost is a weekend of your time and your travel expenses. Oh… and a desire to learn and share.

Right now I’m at the Agile Coach Conference in Ann Arbor, MI.  The regular sessions will start tomorrow.  For Friday evening, we had some delightful lightning talks.

As a manager, what would you like the software developers under your management to learn? This might be knowledge of some specific technology, some software engineering skill, some other skill or knowledge, or what?

Your answer doesn’t have to apply to all of your developers. Pick something that will make a noticeable difference in your organization’s effectiveness. And please be as specific as possible.

Of course, some of the answers were general advice rather than specific things at the answerer’s organization. But where the answers were specific, I typically followed up with two more questions.

What steps are you currently taking to help developers learn this?

What steps do you think you should take, but aren’t yet, for some reason?

I’d like to hear your answers, either as comments to this blog or privately in email.

I found it amusing that the first response to the Carnival of the Agilists post was one complaining that the drinking water wasn’t obvious enough, being provided in coolers instead of bottles.  All I can say is that if this is the biggest complaint, the conference was a great success!

During this time, Brian Marick has been stirring things up at the Agile Alliance. I’ve joined in the discussion of his observations and proposals only a little. Brian’s turned over a lot of stones at once, and it takes me awhile to examine all the things that have been living under them. Being a Myers-Briggs introvert, I tend to discuss these things in my own head before displaying them to the world. Here, though, I’m just thinking out loud and I haven’t come to any conclusion.

Snipping a bit from Brian’s proposal:

It should explicitly focus on helping members of Agile teams succeed, leaving concern with the larger organization to others.

• “Members of the Agile team” is defined to be everyone who’d be expected to attend a team standup meeting: programmers, testers, user experience designers, Scrum product owners or XP Customers, technical writers, and so on.
• “Succeed” means that (a) team members love their work, (b) the business both considers its money well spent and also sees the current version of the software as a readily-tapped reservoir of potential value, and (c) the software is so good that team members bore people at parties describing how easy it is to change, to push builds to production, to debug, and so on.

My first inclination to this is to say no, because I don’t think you can successfully do Agile development at the low level without affecting (or being affected by) the way things are done in the rest of the company. In my experience, implementing Agile at the developer level can be incredibly difficult when the surface level expectations of the next couple layers of management are using a different terminology and different way of slicing the work.

On the other hand, the Agile Project Leadership Network is clearly focused at the management levels, and Lean Software Development, as described by people like Tom and Mary Poppendieck, is focused more toward the executive office suite. So, maybe it’s OK that the Agile Alliance focus on the nuts and bolts at the lower levels. The other levels are not ignored, even if they’re not the focus of the Agile Alliance. It will, however, be important to improve communications between people and organizations focused at these different levels to avoid local optimization.

Brian also says,

Whereas many team members are weak in the basic skills and need to learn them, many others are fluent at the state of the practice and want to improve it…

I think he’s intending to differentiate between developers who want to make Agile more than it is today, and those who sometimes struggle with getting the code to work at all, and would do well to accomplish the basic developer skills of Agile. I can certainly understand and empathize with this distinction. It’s really hard to discuss refactoring with a developer who can’t articulate the concepts of software cohesion and coupling. There is a lot of bad code being written, in spite of the success of the design patterns movement. I’ve interviewed a lot of developers who mention “design patterns” on their resume but, when asked to name some they’ve found particularly useful, can only come up with the Singleton pattern. Contrast that with developers who are discussing the merits of particular techniques of TDD (or BDD) or whether state-based or interaction-based testing works the best.

There’s another area where “many team members lack the basic skills,” however, and that’s in the “Individuals and Interactions” arena. These skills are completely orthogonal to those needed to create “Working Software” and the set of people sorely lacking these skills are likewise distinct, yet overlapping. Yet these skills are incredibly important in team software development–just as much as technical skills. Perhaps even more importantly, these skills are incredibly important to creating a successful Agile environment within the larger organization–especially one that doesn’t yet understand what Agile is and how it can benefit the organization.

Should the Agile Alliance focus on these skills, also? If not focusing, as an association, on introducing the larger organization to Agile, should it be paying attention to ways that the “front line” can successfully introduce Agile? If not, can there be much spread in the successful implementation of Agile Development?

I understand that Brian is trying to draw a line in the sand and say “We’re doing well in this area, so let’s concentrate on it.” I’m grateful that he’s trying to bring a clear focus. I’m just having a hard time seeing a hard line between the front line of developers and their immediate customers, on the one hand, and the larger organization in which they work, on the other.

]]> http://blog.gdinwiddie.com/2007/06/03/time-flies-like-an-arrow/feed/ 3 http://blog.gdinwiddie.com/2007/04/12/amplifying-your-effectiveness/ http://blog.gdinwiddie.com/2007/04/12/amplifying-your-effectiveness/#comments Thu, 12 Apr 2007 21:31:52 +0000 George Dinwiddie http://blog.gdinwiddie.com/2007/04/12/amplifying-your-effectiveness/ Johanna Rothman’s recent post on the AYE Conference prompted this unsolicited testimonial.

If you’re a techie working with people, you can learn loads about being more effective by attending this conference.  This is no sit-in-a-room-and-listen sort of thing.  You’ll get involved and learn lessons you’ll never forget.

I’m an independent consultant and pay for my own training.  This conference is one I won’t skip.  It’s well worth the cost.

]]> http://blog.gdinwiddie.com/2007/04/12/amplifying-your-effectiveness/feed/ 0