28 August 2009

There Be Agile Dragons!

At recent conferences such as Agile 2009 and SQE's Agile Development Practices conferences in Vegas and Orlando, I've been running into more and more actual decision-makers. This is exciting, because it's one more indicator that Agile is "crossing the chasm" into regular, large-scale corporate use.

These decision-makers usually want to know, "Will this Agile stuff really help, or is it just another process fad?"

I always converse enthusiastically with people interested in "going Agile," but I no longer limit myself to "Agile" methods. Often, I'll avoid even using the term (though I have no plans to change the name of my company just yet...).

I tell them I'm interested in helping teams examine and alter their development processes by identifying bottlenecks, looking for root-causes, finding ways to ease those constraints, and delivering valuable software.

XP practices, Agile management, Lean leadership, and an overall "Theory of Constraints" approach; all these should be in the software-dependent organization's toolbox. What we call "Agile" is a subset that applies to a variety of constraints, but not always to the limiting constraint.

Dramatis Personae
Over the decades, I have picked up techniques to uncover people's key concerns. I can talk until I lose my voice; describe the latest findings, and pause to listen as they come to their own conclusions.

Decision-makers usually have a healthy dose of skepticism towards new (or seemingly new) techniques. They pick things up somewhere between the early adopters and the late adopters. It may even be a corporate survival trait. Skeptics are always fun to talk to.

But then there are the naysayers, who seem to believe their team cannot do anything right without constant oversight and carrot-and-stick incentives. Naysayers will listen, but then they simply reiterate their position, and will try to keep you in the conversation until you concede (whether or not you realized you were in a debate).

I think I know why: These are leaders burned by some past failure, and are avoiding failure by avoiding change. They will try to build a mental model of some new thing (Agile), and then run virtual scenarios in their minds, rather than committing themselves and others to real risk. Unfortunately for them, their mental model cannot be completed through mere conversation.

To them I now say: "Meet The Dragon."

The Boy and the Dragon

There's a story (very old, but I can't find a handy reference, so I'll bring it up-to-date) about a boy who loved dragons. He drew pictures of dragons, wrote poems and stories of dragons, and read books about dragons. He even dressed as a dragon for Hallowe'en, and his Twitter-name had "dragon" in it (there, now the story is updated).

One day a great, wise dragon heard about the boy, and thought that she would delight the boy by visiting him at his home. "Imagine," she thought, "how excited he will be to finally meet a real dragon!"

She appeared one night in his room and began to speak...

The boy saw the dragon in his room and was so terrified, he could neither move nor reply. His eyes were wide, his heart pounded, and he was in such a state of shock that he could not even scream. The terror was so great that he died of fright right there and then!

(Okay, okay, the dragon gives him CPR and he lives. In fact, the dragon, let's call her "Puff,"and the boy--I think his name was "Jackie Paper"--become fast friends. Better? Sheesh! Remember the good old days when children's stories used to be truly scary? ;-)

DM: Dear @AgileCoach, Do Dragons Really Exist?

Yep. There are many successful Agile teams around, actually doing Agile stuff because they want to; because they produce high-quality, high-value software quickly; because they enjoy working in an environment that encourages them to learn and to succeed; and because it seems the most professional way that we know of--so far--to build real software.

I have met many real Agile dragons of all shapes and sizes. I have assisted dozens (perhaps over 100) of transitions, and many of those have adopted Agile far enough to leap beyond mediocrity. I have been a contributing team member (long-term, full-time coach/TDD developer/project manager) on at least four exceptionally successful teams: Small teams, larger teams, applications handling millions of dollars, and one life-critical ("you break it, someone may die") application.

"I'm Not Your Life-Coach, But Since You Asked..."
Do you have a friend who wants to be a great actor, a supreme-court judge, an astronaut? (Not someone simply greedy for fame and fortune, but a sincere, interested, even talented individual.) How many of his friends are supportive, but secretly think he's foolish? Do they encourage him with vaguely positive platitudes, yet privately think he should take that accounting job at his father's firm?

I would tell this person (if asked): "The odds are against you, and you may have to 'settle' for less than a bullseye, but there are indeed famous actors, supreme-court judges, and astronauts in this world. Who is to say you won't be one of them? Seeing is believing, so [quit telling me about your fantasies and] go find one to talk to!"

But assembling an exceptional software team is so much easier. You're not competing for a finite number of roles/seats/launches. There are plenty of problems that software can solve, that it hasn't. You don't have to have only the best programmers. You don't have to have Steve Jobs as the Product Champion and Ken Schwaber as the coach.

I'll give the aspiring actor and the aspiring Agile team the same advice: Identify your weaknesses, work to reduce their impact. Identify your strengths, and leverage them. And don't be discouraged by an apparent lack of progress. You may never get to where you though you wanted to be, but you will be much happier with the results than if you just kept doing what you were doing. You'll "get what you need" (Mick Jagger, of course).

Visit the Dragon's Lair

I think Pivotal Labs in San Francisco will give you a brief tour, and will describe what they're doing. I know that Menlo Innovations in Ann Arbor will give a two-hour tour, and in fact their tours are so popular that they've published a book and posted video on the web for those who cannot make it out to Ann Arbor. Another in the Bay Area, I'm told, is Sarah Allen's Blazing Cloud.

A few Wise Dragons to choose from. At each of these places, you can watch real software being made using Agile management and development techniques.

And rather than falling for the cynical belief that it can never work at your shop, let me bring in my executive coaches, Lean/Theory-of-Constraints experts, and Agile Mentors (me and others), and we'll help you reveal the Wise Dragon lurking within your teams.

You don't have to believe, you just have to get over the shock.

08 August 2009

Charging Fees for Tardy Meeting Participants is Avoiding the Root Cause

In order to deter people from showing up late to their daily "Scrum" or "stand-up" meeting, some teams charge the culprit(s) a fine, or make them do some embarrassing activity (such as singing) for the team. Some teams use the money to buy lunch for the team once a month or so. (If that's you: Please stop it! You're rewarding the wrong behavior.)

It may be effective, at first, but if there's a habitual lateness by an individual, or usually someone is late (though not always the same someone), then there's a deeper problem: The meeting is not considered valuable to the team.

I was just asked about this, and it showed up as a LinkedIn discussion, so here's what I wrote:

First, let's make a distinction between being late for work, and being late for a stand-up meeting. I think they need to be addressed separately. I only want to address the latter for now, because it's primarily Agile-specific. Stand-up meetings (they last at most 15 minutes, and everyone stands), are a core practice for Scrum and Extreme Programming (XP) teams.

Stand-up meetings that are scheduled first thing in the morning tend to be detrimental to the team: both to the latecomers and to those who usually show up 1/2 hour before the meeting. For those who usually get to work just a little before the meeting, you will find that you really cannot get enough accomplished in that 1/2 hour. Sure, you could just boot your machine and get some coffee; and morning rituals like this are entirely manageable in that amount of time. But expecting to make significant progress on a project task in that time, though, is a lot to ask of yourself. You're guaranteed to be interrupted, and you're going to be anticipating the interruption.

Also, what I worked on yesterday is a fading memory (assuming I went home, and slept well). If I wrote myself some notes, then I have to find those before the meeting.

These fees and amusing punishments are often (appropriately) recorded in the team's working agreement (aka "Rules of Engagement"). This avoids punishments that are randomly delivered and arbitrarily chosen. But note that people can agree to do things that are still rather obnoxious for the individual or team. Someday, no matter who you are, you will be late for a meeting. Fees, singing, etc. may work if you have an entirely socially comfortable team, but let's face it, we're still publicly punishing the latecomer, possibly punishing the team (they have to listen to someone sing?), and probably wasting more of the team's time. Isn't there an old adage about avoiding forms of amusement that requires the discomfort of another? (If not, there should be.)

Instead, motivate the team or individual by finding out why the stand-up seems less valuable than a few more minutes of sleep (or twitter-time, or whatever). Fix the root cause, not the symptoms.

Getting Specific

I encourage teams to have the stand-up before lunch. 11:45am comes with it's own natural motivation for keeping the meeting short (Everyone's hungry!). Mid-afternoon may also work well. Around 2pm or 3pm, perhaps. 4:30pm is getting a little late for those who arrived at 7am, or who have to pick up kids at daycare.

Start the stand-ups on-time. Don't wait, even if the CEO said she'd stop by today with your VC Angel and President Obama in tow. It's not their meeting.

If you're late, don't ask to start over, even if you're the Scrum Master/Project Manager (it's not your meeting, either) or PO/Customer (ditto). If you're really late--or the team feels that lateness is simply too disruptive--then skip it entirely. You know, there will be another tomorrow.

Find an Impartial Observer

The daily stand-up reveals much more than project progress; it exposes the attitude of the whole team and the pathologies of the whole process. If your stand-ups are dull, too long, frustrating, mechanical, or contentious, then hire an external Agile coach (preferrably moi) to observe them for a few days. You likely have deeper problems than a few tardy developers and no funding for pizza day.

03 August 2009

Innovation isn't Dead, but Remember to Feed It

Aside: If you're wondering why I'm not posting Part II of the series, worry not, it's coming. I just had to say this first...

In mid-July, I attended a 20-year college reunion of close friends who graduated mostly from Northern Arizona University's Computer Science/Engineering college. We call these, affectionately, "Geek Reunions." We get together about every five years in Flagstaff to reminisce, eat at our favorite college restaurants (Alpine Pizza and Macy's Coffee House, both still open after decades of abuse), and to marvel at the wonders of computer science.

Except that, in twenty years, what do we have? Some cool web-apps (the Internet already existed) like amazon.com and Google Maps. We have the iPhone, and we have [insert your favorite high-tech whatzit here rather than flaming me for forgetting it]. And that's about it. (Okay, to be fair, here are others that I can't imagine living without, though we did alright without them in the 80's: Microwave ovens, cell phones, GPS devices, hybrid engines, LED flashlights, organic produce, PDF documents and ubiquitous e-mail [together negating FAX machines, which were always an insult to human intelligence], flat-screen TVs, sticky-notes, much-improved solar cells...)

I haven't read the book Where's My Jetpack? yet, because I think it could trigger a panic attack. But I heard the author on NPR describe various inventions and leaps of human progress (both far-out and practical) that were predicted to exist, but still don't. Some that I lament: Bullet-trains crisscrossing the nation, Moon Base Alpha, fusion power, a Martian colony, a world-wide food program, world peace, the elimination of cash (or at least those darn noisy/heavy/barbaric coins), ubiquitous personal digital signature authentication (eliminating check-writing, contract-signing, and--sadly--the USPS), solar-power collection farms dotting the nation...

Among the participants at this reunion were at least four previous NAU Association of Computing Machinery student-chapter presidents, including myself. The current NAU ACM President, Leah Shanker (her blog), offered to give us our usual nostalgic tour of the newly remodeled Engineering building on South Campus. We noted, too, that the Business building had undergone remodeling, and was now much taller...blocking the view of the San Francisco Peaks from every vantage point in the EGR building and on the popular grassy "quad" below it.

There has always been a friendly rivalry between the Computer Science/Engineering program and the Business College's Computer Information Systems program. But this was an affront to nature! We immediately discussed ways to regain a view of the Peaks: From mirrors to wormholes to particle accelerators to bulldozers...

Where Have All The Nerds Gone?

Apparently the NAU student chapter of the ACM had fallen into obscurity after our network of friends had left. In fact, the whole computer science program had suffered an extreme drop in enrollment.

When I graduated, the artificial bubble known as "Star Wars" or SDI (Strategic Defense Initiative) was just collapsing. Some of us had moved to various cities and signed one-year leases, only to get laid off the next week. (I can't complain. Had I taken a job with Lockheed-Martin or McDonnell-Douglas or Skynet [makers of the T-100], I would likely not be an agile coach now. For me, it was a lesson in turning a bad situation into an opportunity. Of course, it took ten years and 20/20 hindsight...)

For a while (and possibly throughout the dot-COM era?) a CSE degree was not seen as quite as valuable, or as interesting, as a MBA. And, even today, the NAU CSE fourth-year class has only two women enrolled. That's about 1 percent, and far lower than when I was there. Leah is one of the two.

Return of the Nerdi

But there was a very bright side to the visit. Leah and her cadre of mischievous engineers were doing all the things we had done: Going to programming contests, returning with trophies, spending free time in the computer labs, socializing in the labs, working in the labs, falling in love in the labs, hacking campus computers (Leah did it as part of a report on computer security, and the dean had to intervene to keep her out of trouble!), trying to interface computer software with robots, and writing computer games. They were exploring their medium.

I had to ask "so, you're not trying to invent the next killer web app?!" Leah cocked her head skeptically, frowned, and pointed out the window...at the Business building.

"Rob, Aren't You an Agile Business Coach?!"

Of course, business thrives on both technical and business innovation. I see amazon.com as originating from business innovation. Put the whole bookstore (and quite a few other stores) right in front of people, give them a way to rate products for each other (and appeal to their ego at the same time), and tell them about products that they may be interested in (with an all-too-easy one-click purchase option).

It's like a mall crossed with Consumer Reports crossed with a Personal Shopper. Amazon.com takes far too much of my money from me each year, but I get these little packages of joy delivered to my door, even when it's not Christmastime! It's brilliant.

Now amazon.com has made much of its sales engine available to developers via their web-services API. They're using a technical innovation, and that's paying well, too.

If we consider the original web search algorithm, Google was a technical (mathematical, algorithmic, scientific) innovation. I recall wondering how they were going to turn that into a business success...until they came out with those short, text-only, search-related advertisements. That was a clever business innovation, later measured as the most effective use of advertising dollars on the internet.

I knew that Leah's reference to the Business building was her way of doing her part to keep the CSE vs. CIS rivalry alive, and I was encouraged by that. We need both forms of innovation, and keeping them somewhat separated is probably beneficial.

Imagine if the Google founders had waited until they had all the infrastructure ready to make money before enabling search on the Web. Imagine if amazon.com had waited until the advent of standardized web services before launching their site.

I wonder how many companies have failed because they refused to launch until they had the market all tied up in a neat little ball? (Remind me to tell you the sad story of Cymerc.com. They relied on Cysive to build the product, and Cysive was not agile. And now they're both dead.)

Some companies (particularly start-ups) rely mostly on one or the other form of innovation, but most midsized or larger companies these days need to consider how to stimulate both.

Seeds of Innovation

The unbounded, un-purposed exploration that's again happening in my alma mater is a key ingredient to innovation. Whether or not some great invention will appear from the halls of our Universities; this is not my concern. But software development teams need an environment that is similarly conducive to exploration, and perhaps tolerant of a touch of mischief. The mindset of exploration is the driver of innovation, and cannot be forced or coerced, even with bags of money.

I dearly miss Flagstaff, the NAU campus, daily interaction with those friends, and that feeling of exploration. Yet I left the reunion with a happy heart: Software innovation is not dead!