The joy of conferencing – Agile2011

Agile & Lean, Events | Posted by Doc
Aug 05 2011

It’s coming up – the biggest in the community each year: Agile2011.

This year, I’m the producer of the Open Jam, with my assistant producer being Rachel Davies. I’ll get back to this in a minute.

There are several reasons to attend a conference like this:

  1. Learning
  2. (shmoozing)
  3. Selling and marketing
  4. Teaching and sharing
  5. Volunteering or otherwise working at the conference

The first question I ask myself before I go is “What is my purpose here? Do I have multiple purposes? Is there one thing, or some small set of things, that I’d like to accomplish? When I get back home, what will make me feel that the time was well spent or wasted?”

If you know me, you know I spend a bunch of time in #2 (shmoozing) and, if given the opportunity, a bunch of time in #4 (teaching and sharing). It’s not unlikely that I will be doing #5 (volunteering) and #1 (learning). Up until Tuesday of this week, I was expecting to do a bit of #3 (selling/marketing) on behalf of . Clearly, I’ll have that time free. ;)

Are you going? If so, what’s your purpose? If your employer/organization is sending you, how will you justify their investment? Will you be better at your ? Be sure that you have some way to identify the benefits you receive, and that your employer/organization therefore receives, based on the events you attend and connections you make.

Now, that said, on to the Open Jam…

In order to make the whole richer, the organizers of Agile2011 have, for the past few years held an “Open Jam”. It partakes of concepts like birds-of-a-feather (BOF), Open Space Technology/Unconferences, and lounge. Depending on where it has been, who has been responsible, and what’s going on in the conference, it has presented a different face each year. This year, with Rachel and myself producing it, we’ve decided to introduce a couple of extras as part of the Open Jam.

  1. PechaKucha (pronounced, if you care, as p’cha-k’cha, not peh-cha-koo-cha): each day, after the programmed sessions have ended, the stage is yours. Come present 20 slides at 20 seconds each for a total of six minutes and forty seconds (6:40). Talk about anything you like: hobbies, technology, passions, sports, design, whatever you like. It should be fun and exciting!
  2. Coaches Corner: thanks to the leadership of Mark Levison, there will be an area with experienced Agile coaches who will maintain “office hours” so others can come talk with them. Got challenges? Problems? Curiosity? Just learning? Come and talk to them during their office hours. Various organizations and independents will be represented. You can’t lose!
  3. The Fringe: there were many excellent proposals submitted to the conference earlier this year. Having been one of the reviewers, I can tell you that it is never easy to eliminate some. It’s like American Idol or So You Think You Can Dance – it doesn’t matter how good you are, not everyone can win. So we (okay, Rachel) thought it might be nice to have a non-stage on which some of these folks can deliver the goods. We went through the non-accepted proposals (they weren’t rejected, y’know), and have picked an interesting sample (including yours truly, btw) for you.
  4. Park Bench: this will be a place where, among other things, the original authors of A Manifesto for Agile Software Development (“the Agile manifesto”) will be dropping by from time to time.
I won’t tell you what it is, but there’s one more cool surprise in store for folks in the Open Jam.  Seriously.  It’ll be awesome.

I’ll be there from Sunday afternoon through Friday evening.  Not necessarily in the Open Jam the whole time, but the odds are good that you’ll see me there a time or two if you look for me.

The Beauty of the Seattle Waterfront

Photography, Travel | Posted by Doc
Aug 04 2011

While I don’t often post about my here, last week was noteworthy and deserving of a tiny bit of space here.

is renowned for being one of the grayest, drizzliest, dampest places in the country. And it’s probably deserved.

It’s also renowned for being one of the most beautiful, amazing places in the country.  Definitely deserved.

I spend some time along the Seattle Waterfront (Pier 70, Waterfront Seafood Grill, Olympic Sculpture Park) while having dinner and walking and talking with my friend Rebecca Parsons (CTO of ). Having Rebecca as a friend is one of the best things that happened to me at .

The weather was perfect, as we strolled along the pathway along the waterfront. Temperature was in the low- to mid-seventies, the sky was beautiful, the sun was lowering, and the water was filled with sailboats. I’d argue that you don’t need to be an exceptional photographer to get great shots in a situation like that.

I put a number of pictures on Flickr from that place and time. I’m proud of them and wanted to share.

Here’s an example. Go to Flickr to see more.

Seattle Sunset (sigh)

Where is the greatest friction?

Agile & Lean, Musings | Posted by Doc
Aug 03 2011

Between coaching and training, I’ve dealt with a number of organizations that are trying – in one way or another – to adopt principles, practices, and methodologies.

I’m frequently asked “What is the hardest part? Is it the engineering practices? The predictability (or lack thereof)? Staffing?”

None of the above (you probably guessed that).

Boundary friction. Yup, that’s it. Boundary friction.

Train TracksImagine two trains. They’re running on tracks that sometimes run parallel, and sometimes diverge and come back together. When they get close enough, they actually touch.

Got it? Got the image of two trains racing or plodding along, coming closer and moving farther away, and sometimes coming into contact? Can you hear the train whistles and the sound of the wind and the wheels?  Feel the vibration?

If they’re both moving at the same speed, what happens when they come together?

Nothing. Smooth, easy, no friction.

What if they’re moving at different speeds? Faster versus slower is not better or worse, just different. So what happens?

Friction. Things heat up, maybe metal gets bent or crunched or marred. It is not smooth and easy, is it?

When organizations are implementing agile (or any systemic , really), without considering the whole organization, friction is inevitable. Let’s say that Business Operations is used to doing things one way, and isn’t ready to change (yet). Along comes this project team that’s doing Agile. Again, I’m not arguing that “agile is faster/better”, I’m just saying that it’s like they’re moving at different speeds. Where they come together, there will be more or less friction depending on how close to parallel and how close to the same speed they are.

In this case, it means that if both organizations are not embracing the change in similar ways, there will be more friction.

You can’t impose a change on part of the organization without affecting the rest of the organization. That’s ostrich .

The trick, the secret (it’s actually neither a trick nor a secret, though) is to figure out how to get them to truly come together.

That doesn’t mean telling Business Operations (or Sales or Product Management or…) “For this to , you have to adopt Agile principles and practices and methodologies. Now. Today.”

No, it means figuring out how to evolve together, taking smaller or larger steps when they’re appropriate. Like embracing the Last Responsible Moment principle. Like the Simple Design principle.

Implement as much change as you can readily absorb, in order to get you a bit further along. Then inspect and adapt. Don’t rush.

Organizations are organisms, and the organs and skeletal structure are all part of the same organism.

Or trains. Yeah, they’re trains. ;)

No longer a ThoughtWorker

Uncategorized | Posted by Doc
Aug 03 2011

I’ll keep this short.

As of yesterday, Tuesday, 2 August, Studios decided they no longer needed my services. “Your position is no longer being funded” is the terminology they used. Yeah.

Needless to say, I’m looking forward. A single tweet produced some fantastic results, and I’m overwhelmed by the nature and volume of the responses I’ve received.

More to come as I discover it.

Dilbert and Testing

Agile & Lean | Posted by Doc
May 15 2011

Dilbert.com

This is such a good object lesson about , it’s almost not funny.

Once again: Busting the Mehrabian Myth

Musings | Posted by Doc
May 05 2011

You’ve probably heard, and repeated, that “93% of all is non-verbal”. Of course, this isn’t true. Rather it’s a misuse and misunderstanding of the of Professor Albert Mehrabian.

Here’s an excellent video that explains it clearly.

Change is hard, still

Agile & Lean | Posted by Doc
Apr 17 2011

I had a chat with a new friend yesterday. We walked down the road from the hotel into Wolvercote, and chatted about life and .

This fellow manages a development team. He’s concerned that they’re not as effective as he thinks they could be, that they have a low “bus factor” (my term), and that in particular is not what it could be. They have legacy code, and it sounded like they have quite a bit of specialization, in spite of having only four developers.

I latched onto that last point first. “Have you tried pairing?” I asked.

“No, I hadn’t really thought of it yet.”

Lots of intermediate discussion…

“What do you do when you have an odd number of people?”

I knew he was listening carefully, and yet I was getting a feeling of resistance. I tried to offer ways in which he could get buy in from the team, make some changes that would encourage them to think and examine the way they’ve been working, and make it a team thing, not something imposed from above.

“Well, I’m really concerned about the testers.”

I suggested co-location, or some version of it. He explained that they have separate two-person offices, and he can’t that.

All of this got me to wondering whether he really wants to facilitate change, or he just wants to talk about it. He said some of the right things, but when it got down to actually doing it, he repeatedly explained to me how hard it would be, and what the obstacles are.

Change is hard. Embrace change only if you really believe that it has the potential to deliver benefit. And then embrace it wholeheartedly.

Clever recruiting stratagem

Musings | Posted by Doc
Apr 16 2011

I was chatting with my new acquaintance, Thomas Witt, at the ACCU2011 conference. As we were talking about my lightning keynote on Mastery Quest, we got off on a variety of topics around how to identify people who really know what they’re doing and how to weed out the fakes and system gamers.

He said a colleague of his started including something special in their postings:

Include this word (<word>) in your cover note.

Of course, those who read the posting carefully see that and include the <word> in their cover note.  Many do not, according to Thomas.

He says that as they’ve tracked the correlation between those who do and do not include the <word>, and those who do well in interviewing and on the job, the correlation is high. Those who notice the requirement to include the <word> are more successful.

Intriguing.

Separate blog: Mastery Quest

Musings | Posted by Doc
Apr 14 2011

I’ve decided to separate my on play/games/learning/ (“Mastery Quest”) onto a separate blog, so that I can have co-bloggers.

If you’re interested in following this thing as it evolves, it’s at mastery-quest.blogspot.com

The Hidden Project Plan

Agile & Lean | Posted by Doc
Apr 13 2011

As I’ve been doing training on Fundamentals over the past 18 months, I’ve found myself talking about this consistently: The Hidden Project Plan.

Here’s how the story goes: you build a project plan, and do your best to manage to the project plan. Things drop out, like and documentation and training, as you run short on time and/or money, or your resources are committed elsewhere. Ultimately, with a system with multiple components/subsystems/systems, you get to the point of integration. Your project plan allows for some time to do the integration, including fixing the bugs uncovered during integration.

The problem I’ve seen over and over is that there are more bugs than anticipated, the team has been split up to on other projects, there’s neither time nor money left for this project, and the developers and testers are multitasking from their new assignments to get these things fixed. Oh, and they’ve forgotten everything they knew about the code and tests that they wrote a year ago.

The time and effort and cost that are not part of the original project plan? That’s what I call “the hidden project plan”.

The short answer? Continuous integration / deployment / delivery, combined with effective TDD and automated functional testing. These things, along with a number of other agile practices, can reduce or eliminate the hidden project plan such that when a team says “it’s done” it’s really done.