Having just spent most of part of the last couple days at the 2010 Agile Open Northwest Conference in Seattle, I can say for sure that (a) our team does Agile in a very mature way and (b) there are some smart, smart motherfuckers out there.  Yes, I dropped the F-bomb in polite conversation, but whenever I go to a tech conference or any sort of event where bright people can shine, I’m constantly pleasantly surprised at how brilliant some people are.

When I was young, I thought I was the smartest.  And, in the little pond I swam in, I probably had a good shot at the title.  When I went to college, that attitude got dented, but not discarded; when I went to Microsoft, it got dented a little more; but it hasn’t been until I’ve gotten into my 30’s that I think I can accurately rank my intelligence in relation to others.  And the data is trending downward.    I think part of it is that I don’t really care that much anymore.  Also, I now define myself a lot of different ways; there’s a lot more diversity in the components of my self-perception.

I’d name names and tell you who I thought fit in that brilliant category at #AONW but if you’re at all an observer of the Agile community you probably already know who they are.

So, you’re thinking, how was the conference?  I was only able to attend half the sessions, due to work scheduling commitments, but the sessions I attended – save for one – were enlightening and contained nuggets of wisdom and/or practice that I can take with me to my projects.  I personally presented two sessions, one last night and one this morning, and although the attendance was underwhelming, the discussions were really informative and thought-provoking.

The organization at this year’s #AONW seemed to be a little more on the ball than last year’s event held in Portland.  Not sure if that’s due to the local organizers, the maturing of the conference, or what.

The Seattle Center was a good choice for a venue; it’s centrally located, and the Northwest Rooms are all easy to find and self-contained enough that we didn’t have to wander around too much.

I’ve already put notes up from my sessions and tomorrow I’ll put up notes from the sessions that I attended but did not personally host.

n.b. I’m sort of amazed I didn’t blog about my experience last year at the 2009 AONW in Portland.  It was in many was one of the seminal events of 2009 for me, for a lot of reasons.

A new meetup has come sauntering into town, and you can catch it every Wednesday at 8:30 AM at the Uptown Espresso on the corner of Westlake & Republican.  It’s called “Seattle Lean Coffee” and is the brainchild of Jeremy Lightsmith and Jim Benson.

From the press release:

Lean & Agile approaches have become hugely popular in Startups trying to get an edge on slow moving large companies.  We’re putting this group together to further build the our Lean community here in Seattle.

Visit the Seattle Lean Coffee website for more info.

BTW, I don’t know which I get more excited about: “limiting WIP” or just “limiting W”. lol.

[8:25] I’m sitting in a conference room in Bellevue at the Net Objectives corporate office, waiting for Day 2 of an Agile symposium – “Team and Technical Agility” to begin.  Registration began at 8:30, which involved checking your name off of a list and filling out a name tag.

[8:32] I got WiFi access!  there are helpful instructions on the wall next to me.

[8:37] Other teammates start showing up.  Mary, Michelle, and Sumair are all here; rumor has it that Nate will show up.

[8:44] Reviewing the brochure-ware.  Everything says “Lean-Agile,” instead of just “Agile”, which tells me (a) how far the term “Lean” has come, and (b) how relatively deprecated the term “Agile” is as a standalone term.

[8:47] Glad I brought healthy food on the advice of a coworker who attended Day 1 of the symposium yesterday.  These doughnuts do not look like toga-enhancing foodstuffs.  I brought a banana and a fruit and cheese plate from Starbucks, which should last me.

[8:55] Random phone call from home  Gah.  People are still filing in and getting acquainted.

[9:00] Getting started.  The presenter, Net Objectives CEO Alan Shalloway, tells us that there will be a little overlap with previous sessions.  Several people are here for the 2nd or 3rd day in a row.

[9:02] Alan tells us that the course materials will be up on the web in a day or two.  I’ll link to them when they’re available.

[9:03] Alan has written a lot of books.

[9:04] Whiteboard cleaner smell is making me woozy.  I’m seeing double.  Where am I again?

Continue Reading »

Well, let’s see: an enjoyable day.  It started off with a 3.5-mile run on the treadmill at the gym.  I’m telling you, this intense morning exercise thing is the way to go – I felt energetic and metabolitic (is that a word?) all day.  Then on to work, which lately has had both the possibility for both soothing- and anxiety-inducing circumstances.  Today my team got hit with a major hotfix request stemming from some system problems downstream from a release we did a few weeks ago.  Fire drill; chaos; chickens flapping and clucking, all warily circling around in a Mexican standoff – who will accept blame first? you know the deal.  Luckily my team stepped up, kept our heads about us, isolated the issues (there were five separate issues), got an estimate in, and got consensus on starting in on the fix.

My team have good heads on their shoulders.  I’m thankful for that.

I’ll be out tomorrow so will get to miss most of the fix part, but my team is totally capable – in fact, they’ll probably do a better job with me out of the way   I’ll be attending an Agile seminar in Bellevue put on by Net Objectives.  A coworker attended the first day of the seminar and I heard through the grapevine that they’ve done pretty well the first day, so I’m looking forward to going tomorrow.  Sometimes these free seminars are too heavily focused on vendor marketing; this one sounds like it’s got more meat on the bone.  I also got an insider tip about bringing my own healthy food/snacks, which I really appreciate, given my fitness and diet goals for the next forty days.

I actually had an enjoyable appointment with the doctor this afternoon.  It turns out they don’t have to transplant my brain after all.  Shocked?  So was I.

My mega-short-term project that was due last night by 11:59 PM went off really well and I finished with time to spare.  I love that feeling of super-productivity that I occasionally get.  It’s like I can do anything; I’m transported; I’m in the flow; I can do no wrong.

Here’s a great TED talk about flow, given by the guru of flow, Mihaly Csikszentmihalyi:

So what’s not so good?  It IS Monday, after all – it can’t all be peaches and cream, no matter how rosy the color of my lenses.  I’m still trying hard to forget the anti-flow I experienced this past Friday.  Comedy equals Tragedy plus Time, so when I start laughing about what happened, you’ll know I’m past it.  Can I get a little chuckle right now? (tries chuckling) Not yet.  Maybe tomorrow   I’m sure if I was capable of sharing that you’d think it was hilarious.  Maybe I can write it out in Morse Code or hexadecimal Unicode or something so only my most dedicated readers would be willing to take the time to figure out what I’m talking about.

F347A32DE746B1CC984AF398324…

Ha ha!  That was gibberish.  Hope you didn’t try to translate that.  No, what happened is between me and my journal, and you get to live with uncertainty.    Don’t you just hate that?

Finally, on pins and needles regarding an investor meeting that took place today that involved some work I’ve been doing with a business acquaintance.  Won’t know until tomorrow what the outcome is, but there may be some good stuff on the horizon, career-wise.  I’ll be sure to let you know.

Have a great Monday night.  A happy “Ciao!” to my regular readers and I hope you have a great Tuesday.

Over the last eight years, a lot of us have gotten leery about those who, for whatever reason, are prone to mispronunciation. In fact your experience might lead you to believe that it’s a general rule that those who mispronounce words are also sort of lacking in education or intelligence.

Don’t believe it for a second.

I just finished the two-day Construx seminar Being Agile Without Being Extreme, and the instructor, Jerry Deville, is as sharp a tack as I’ve seen in a long time. He also has the advantage of bringing an authentic Louisiana accent into the classroom, and I am now and forever cured of the notion that the occasional mispronunciation has anything to do with capability.

Jerry comes from a background with the U.S. Air Force and Boeing, among others, which wouldn’t immediately remind you of “Agile software development organizations”, but he’s been doing real-world consulting for however long and believe me, he knows his stuff.

So – about the seminar.

It was targeted at the technical program manager crowd, and in Day 1 covered the questions What is Agile?, “Why Agile?” and “How Agile Should We Be?”.

• Jerry was persistent in explaining that it wasn’t a question of Agile or Not Agile, but rather that there is a continuum of SDLC practices, with Pure Agile on one end and Pure Waterfall on the other, and most organizations will fall somewhere in between those two, depending on your particular situation.
• There was a nice discussion of the distinction between agile methodologies (think Scrum) and agile practices (think pair programming, or continuous integration). Even if your organization doesn’t let you do a big-A Agile methodologies, you can still incorporate the practices and get some benefit.
• One of the things I liked was the continuous cross-referencing and repetition of certain key concepts, such as short cycles, feedback loops, and what commitment means. Jerry’s a gifted instructor.
• I had a little disagreement with Jerry’s definition of quality – he says that the product should be at “Near Release Quality” (NRQ) all the time, and he defines NRQ as “able to launch within one more sprint”. That may be true for commercial shrinkwrap software, but anything web or internal should be much closer to release quality than that, in my opinion.
• Great discussion of value – he broadened the definition of value to include things like regulatory compliance, documentation, technical debt, etc.
• Lots of good discussion about the role of requirements in the Agile process. Jerry makes the claim that Agile has only recently begun to be able to tackle super complex or mission-critical applications because of the relative lack of focus on requirements gathering in most Agile methodologies. He makes a good case.
• Good treatment of common agile themes such as barely sufficient, last responsible moment, progressive elaboration, and “emergent design“.
• I loved how Jerry focused on the need to ALWAYS deliver value in every sprint.
• Nice treatment of various ways to break up work, with a hands-on lab to demonstrate the concepts.
• Good discussion on release planning and sprint planning, and what your goals are at each level.  It was in this section that I experienced a sour note – I come from a background in XP, one value of which is honesty.  If your organization is such that you’re required to pad sprints with important-sounding items that are ultimately just backstops for problems with your business, your organization has a problem that Agile can’t fix.
• I was blown away by the discussion of formal user stories, not having used them myself in the past. Ironically, my boss just gave me a book to borrow called “User Stories Applied” so I’m really eager to dive into that book.

Day 2 started off with a continuation of the previous day’s discussion on quality, and got deeper in the details of common Agile practices, like pair programming, refactoring, coding standards, etc.

• Good discussion of estimating techniques and goals, including a hands-on Party Poker lab.
• Jerry’s a big proponent of fixed iteration sizes – for ease of subsequent math. It seems to me that this has it backwards – you should find the optimal point at which the benefit/cost ratio is the highest, for your organization.  I know I’m omitting some of his argument, but we didn’t get into the weeds of “What is the optimal iteration size”.  The net of it was: experiment.   Pick a size, see if it worked, wash, rinse, repeat.
• Lots of discussion about the soft aspects of the SDLC in general – the peopleware part. Jerry has got tons of good experience-based advice and guidelines here.
• Good discussion about how to handle interruptions, distractions, patches, etc. that your team will inevitably be subjected to.
• Good introduction to the Scrum Burndown worksheet. Looking back, I wish that we’d gone into more detail with that section, but Agile project tracking could be a seminar all to itself.
• Excellent advice about how to set up and run a project retrospective. I’ll be putting that advice to use right away.

Jerry’s a great teacher. He’s as widely read in the field as anyone I’ve ever personally met, and has the real-world experience to tell you what works, what doesn’t, and why. The other students in the class were engaged, thoughtful, and eager to bring up questions that allowed us all to see how the information on the slide could be applied in our own domains.

Even though about 90% of this information was familiar to me, I still picked up more than enough to make this time well spent. I’m doubly motivated to go make this stuff work in practice (even more than currently, and the team I’m on is doing pretty well right now).

I’m very impressed with Construx and with Jerry Deville in particular and recommend that you take a look if you’re considering starting or expanding into Agile at your company.

My one regret? I tried to get a picture with me and Steve McConnell, whose book Code Complete was the first great software book I ever read, but my iPhone camera didn’t record the photo. Bummer.

What if you had a building construction process which resulted in something like 50% of the skyscrapers falling down at the end of the project?

What if you had a boat-building process that resulted in 50% of the boats sinking in the harbor on their maiden voyage?

What both of these examples have in common are:

a) a preference for low risk

b) an inability to change the specifications in midstream.

c) a set of success metrics that are unusually coincident with tradtional waterfall software project management methodologies.

The classic joke about the difference between software people and construction people is a client coming in halfway through the completion of their new building and saying “hey, I wanted three more floors — what will it take to do that?

In software, the specification-heavy projects keep failing at a huge rate, and yet very few people as of yet seem to get that the process itself might be to blame, in the meta sense. The idea that you can specify everything about a software project assumes three things:

a) you have near-unlimited time to produce a spec that covers EVERYTHING. Pixels, messages, timing, performance characteristics, how you handle international phone numbers, Canadian postal codes, and hyphenated names that occur when customer A, who used to be known as Shari Bixby, married and is now named Shari Bixby-Van Der Werff.

b) equally important, the client agrees to everything in the spec

c) most importantly, the client agrees to NOT CHANGE anything in the spec.

How do you add three more floors to a skyscraper that’s already 30 floors tall? You don’t. You scrap it and start over. However, the “add three floors” question comes up all the time in software development. Change this, do this, don’t do that, make that button red, that one green, and add a site map in seventeen languages. Oh, and don’t change the release date because our annual stockholder meeting is the day after we’re scheduled to go live.

It’s just crazy!

Worse, let’s say you did get a client that had (a) unlimited budget, (b) read the spec, and (c) agreed not to change the spec. Woo hoo! But then this client gets a really really really great business opportunity that could only be grabbed if they change the spec. Well, you say, that’s what Change Management is for. Negotiate the changes with the client, tell them the added cost and time, and have them sign a little form that says “I agree”. In theory this is great. It’s better than great – it’s positively libertarian. In practice it’s a nightmare. The client typically has one of the following reactions:

1) It’s easy; why should it take any longer to do “X” instead of “Y”? You’re nickel-and-diming me for simple changes.

2) I still need to make my date. Get it done anyway.

3) (worst) I still need to make my date, and even though I signed this stupid piece of paper, I’m thinking you’ll still make my date.

You have a recipe for ill-will. I would love to see a comment from someone who, when they gave their client a change order, actually had the client say “You know what, this is actually LESS COST and LESS SCHEDULE SLIP than I was willing to tolerate!” Doesn’t happen very often.

Further, a great many clients don’t even begin to assess what they can or want to do with their software until they see it in some partial state of completion. In Founders at Work, there’s an interview with Dan Bricklin, one of the creators of VisiCalc, and he said that most people couldn’t even fathom what spreadsheets were good for, until they saw it demoed, solving problems that they would like to solve.

The fastest-moving and most energetic work in project management today is done in the Agile realm, simply because — it works. Not necessarily all the practices, which vary from camp to camp, but the principles work. Assume that things will change. Prepare for it, plan for it, and adjust your daily, weekly, monthly and quarterly processes to explicitly address that concern, because it will bite you.

Another cluetrain passes Joel Spolsky right on by as he talks in one post about how terrible it is when clients want all sorts of changes right at the end of the project, because they really didn’t read/understand/interpret the spec correctly. He uses himself as the anecodotal customer who got what he wanted — only it turns out, it wasn’t what he wanted. And everybody knows that Joel’s specs are exhaustive, so what’s the problem?

Two or three posts down, he is all agog over Evidence-Based Scheduling — another micrometer wrench in his Gadgetron 3000 toolbox, which is supposed to Solve The Scheduling Dilemma Once and For All. All sorts of Joel’s friends agree! EBS is REALLY REALLY GREAT!

So — which is it? Are schedules and estimates good, nay, even indispensable? Will EBS solve the Terrible Client Dilemma, or will customers continue to come in at the last minute and say “Change these twenty things, because I really didn’t understand how it would all look/work/perform before I saw it.”

For myself, once I accepted the that (a) customers don’t fully understand all of their own requirements early on in the project lifecycle and (b) they appreciate a vendor who can provide the flexibility to accommodate their changes, I became convinced of Agile’s strengths. Joel may not like it, but the Evidence-Based World (EBW) suggests that clients like him are the norm, not the exception.