Software Anti-craftsmanship

Today was the February installment of the Salt Lake Agile Roundtable (#slagile). Originally founded by Alistair Cockburn way back in the mists of time, it persist to this day as a place for some of the best conversations surrounding Agile that you can find anywhere.

If you've never been I'd highly recommend taking in at least one of the meetings. In past meetings there has been all sorts of interesting shenanigans, everything from the obliteration of hopeful doctoral dissertations to actual coloring sessions with crayons and everything (no, I'm not making that last one up - you had to be there)

One of the key elements of the meeting structure is that everyone is asked to bring a topic for discussion. Ideally it will be related to a challenge you are facing but with some of us old timers who've heard just about every kind of problem with software teams you can come up with we have a tendency to introduce topics that will provoke (hopefully) interesting discussions.

Or at least interesting arguments.

My topic today was inspired by a comment someone had made in a previous topic. What they said was "Well, yes, but a craftsman (software) would never do that". Waving an absolute like that in front of us has roughly the same effect that catnip does on cats, so of course I had to find out from the group exactly what they thought software craftsman ship was.

Thus I asked the question: "Exactly what does it mean to be a software craftsman? How can you detect the spoor of such an elusive beast?"

 OK. Maybe I didn't use the term "spoor", but I should have. Would have given me a good excuse to break out a pith helmet in the middle of the meeting.

Of course it wouldn't be the Salt Lake Agile Roundtable if there wasn't a twist to the conversation. The twist of the day was provided by David Adsit (@davidadsit) of Pluralsight. David decided to take the contrarian view and present his list of really annoying things that those craftsmanship jerks do.

Without further ado, I give you David's list of "Software Anti-craftsmanship" qualities:

1. Wastes far too much time navel gazing
2. Pointlessly delays the deliver of "good enough" code

3. Constanty renaming everything! Always with the renaming!

4. Fritters away valuable time changing existing code rather than working on new code

5. Treats the rest of us like second-class programmers

6. Constantly taking off for yet more useless training. Don't even get me started about all of these "Retreats"!

7. Imposes their philosophy about why the way they work is better without ever offering any actual evidence.

You know, I think we might have the beginnings of a manifesto on our hands here...

An agile legacy. Or should that be "An Agile legacy"?

A couple of years ago at Agile Roots I was part of a panel discussion titled "There Is Only Us". The gist of the conversation is whether agile had reached the point where it was considered a best practice for the software industry.

As best I could tell, our consensus answer to that question was "Purple".

There's no question that awareness of this thing called "agile" has permeated the software industry. But the principles behind it? The point of it all? I'm not so sure.

According to a highly scientific survey of a few web sites I decided to google based on my own biases I can prove conclusively that the most common conversation about agile is "Why it didn't work for us".

But this entry is not about agile teen angst. It's about legacy - what we influence, what we pass on.

For many years I taught martial arts as a personal passion. Even tried to make it my career a couple of times. If you're wondering how successful I was just note the fact that I blog about the software industry and not the martial arts industry.

But the one thing I did do well was teach. And the interesting thing I learned about teaching is that sometimes you influence people's lives for the better. Seeing those changes in the lives of my students fed my soul enough to motivate me to keep teaching for over 20 years.

Sorry, was waxing nostalgic for a moment there. No, that's not the legacy I'm writing about.

Last night I was chatting with Daniel Spangler - a long-time friend and co-worker. Daniel is the kind of rock star developer that you build development teams around. I know this because I've done just that multiple times.

Unfortunately our last project terminated rather abruptly, so Daniel moved on to a new position that included...

(insert screeching horror sound track here)

Management responsibilities! 

O, the horror of it all!

As luck would have it, the company he joined was just in the initial stages of rolling out Scrum through their development teams. Daniel, still reeling from the shock of becoming management, decided that I'd be a good person to talk to about this whole agile thing. Of course him coming to me for advice was all the evidence I needed that he was still in shock.

Daniel: "So we're doing Scrum, and I don't know anything about it".

Me: (insert spit-take here) "Daniel, you've been practicing agile for years! What do you mean?!?"

Daniel: "Yeah, I know we've been doing it, but I don't know what all this stuff is called."

What's tragic about this is that there's a large contingent of the "Agile" (yes, I used the big "A" intentionally) community that would agree with Daniel's sentiment that he doesn't know "Agile", let alone Scrum. Daniel isn't the only one. I've visited many teams in the guise of an agile mentor. Invariably they would disclaim that they didn't know (or care about the names) of whatever flavor of agile you'd care to name but were shining examples of how agile teams really work.

Once I had wiped the water off of my keyboard Daniel and I got to work translating Scrum terminology into practices we'd been using for years. Then we stepped back and reviewed the principles behind those practices so he'd have a good basis of why Scrum does what it does, and why we diverged in various situations in the past.

The payoff came in the form of a short conversation we had last night:

Daniel: "So I agree that focus is a key element of agile" (referring to our discussion that iterations provide a framework for the team to limit their focus to the work at hand)

Me: "Tell me more"

Daniel: "After drilling the team hard on better story definition at the beginning of the iteration we are seeing better velocity across multiple projects. Team members aren't wallowing around as much on what they should be working on" (their team works on multiple projects simultaneously)

Me: "So is this a focus success story or iteration definition success story?"

Daniel: "Both, but ultimately it is about better focus. More concise stories translates into less interruptions during the iteration. Less interruptions equals more work being done. We're catching up on several chronically late projects"

Me: "Woohoo!"

Of course this conversation begs the question of "Why don't we see this sort of success happening more often when teams shift to various agile methodologies?"

Wait, I know the answer to this! 

Experience. 

Daniel, who has at least 10 years of experience working with teams practicing different flavors of agile (Scrum, Crystal, XP) can tell immediately when something isn't right, even if he isn't always using using the right names for the dogma.

Contrast that with how agile adoptions typically work - companies hire external experts to provide training and mentoring, but don't invest in installing persistent expertise at the team level where the rubber hits the road. Is it any wonder why we see "We tried Agile but it didn't work for us" so often?

My hat is off to Daniel. Thanks to him, I have a new element of professional legacy that I can point to and admire. 

Oh, and I guess I'll have to claim one less "Agile didn't work for us" story too.

Startup Weekend Anthropology 101

Let's kick things off with a quote:

"I chose cultural anthropology, since it offered the greatest opportunity to write high-minded balderdash" - Kurt Vonnegut

Last month I attended an event up in Ogden called "Startup Weekend". I had heard various things about Startup Weekend through word-of-mouth channels but until this event I had not directly participated in one of these events. Thanks to one of my Agile colleagues Maile Keone and local event organizer Alex Lawrence not only did I have a ticket to the event, but also very nice accommodations next to where the event was hosted.

I didn't walk into the event planning on becoming a Startup Weekend anthropologist, but I certainly walked out as one. Over the next few blog entries I'll be rambling on about what I learned over the course of one weekend in Ogden.

Being a Startup Weekend virgin, I wanted to preserve my opportunity to learn about the event organically so I made the decision to minimize my event pre-res... *snort*

Sorry, couldn't get through that sentence with a straight face. Let's try this instead:

Being a Startup Weekend virgin I did the absolute minimum amount of work necessary to not look like a completely clueless buffoon when I showed up. Or at least I thought I did.

When you look at the outward packaging of Startup Weekend you see the following:

Startup Weekends are weekend-long, hands-on experiences where entrepreneurs and aspiring entrepreneurs can find out if startup ideas are viable.

Reading the above I made two assumptions. One was that a significant number of attendees brought in their business ideas and that there was a significant percentage of startups that launched as a result of Startup Weekend events.

It's a good thing I do clueless buffoon well. I was wrong on both assumptions.

But I'm getting ahead of myself. One of my goals for the event was to engage not as a technical resource but as a business resource - I'd bring in an idea, I'd pitch it, hopefully gather a team and see what happened. I also decided I was going to hack the idea pitch at the beginning of the event by not promoting how cool the business concept was but instead to promote how the team engaged with me would get a better event experience by delivering not one MVP by the end of the weekend - we'd deliver at least 4 or 5.

This great idea of mine lasted maybe 15 minutes into the introductory presentation. What killed it was the admonishment of the event coordinator that you should not pitch your pre-conceived business ideas but instead pitch the problems you are interested in solving that others would also be interested in solving.

It seems I wasn't alone in my mistaken assumptions. There were a number of other first-time attendees I talked to that had made the same assumption. It was interesting to see how many persisted in pitching their concept even after the suggestion to focus on an interesting problem. For the record, I trashed by carefully crafted pitch (after hours of rehearsals and timing practices) and pitched the underlying problem to see what sort of interest it would generate.

None, as it turns out.

But the story doesn't end there. As a matter of fact, that's where the real story begins.

After having my grandiose idea completely ignored I started looking at other ideas that I could jump into and work on. One in particular caught my eye. The idea centered around building some sort of a mobile device multi-player game. This idea was pitched by a 17 year old that had attended 3 prior Startup Weekend events. It wasn't the idea that I found interesting - it was who was pitching it. Honestly - how many 17 year olds do you know that show up at an event like this?

So I wandered over and introduced myself, intending to provide expertise as a business and process expert. I didn't even get to the part where I explained what I was good at before he had handed me an assignment.

It wasn't the assignment that made me walk away from this project. From his perspective I am sure he thought it was the right thing to be doing. But it was clear from that one interaction that I'd have to do a lot more work from a "managing" perspective to get things moving toward a successful presentation at the end of the weekend. And that realization made me question whether it was a good idea for me to be walking into any team there and imposing my experience on them.

I know, the hubris is just dripping from that last paragraph, isn't it? Let's set aside for the moment any discussion of the "value" of my skill set and just focus on personality. My personality is such that I gravitate towards leadership of any group I'm involved in. For better or worse it is how I operate. But I realized in that moment that managing a team to deliver isn't something I really needed or wanted to experience at this event. What I really wanted to experience was how these ad-hoc teams fared over the course of the weekend.

And was I ever glad I did. In that moment I became the Startup Weekend incarnation of Margaret Mead.

Stay tuned for Startup Weekend Anthropology 102: The highest of highs, the lowest of lows