Skip to content

Demystifying Agile: Rants of a Madman on Getting Started

February 16, 2012

I love Agile.  I also hate Agile.  Last year Frank J. D’Andrea, a PDX-based Agile evangelist, stood up in front of a standing room only audience at an SAO TechIgnite event and asked how many people were doing Agile.  He then responded with a booming “YOU’RE DOING IT WRONG!!!!”  I about fell out of my chair I was laughing so hard.  It is so true.  No matter what a team is doing in terms of Agile another team or “expert” will scream at you that you are doing it wrong.  With that said I’m about to be one of those folks myself…

Agile is a great methodology, but like anything there are those out there who can really enjoy making others feel stupid or inept through intimidation.  It’s not necessarily intentional either.  It is bad enough that you may be trying to learn something new, but do you really need self-proclaimed ninjas spouting their Tower of Agile Babble at you?  My favorite of these are the outside consultants who have never shipped a successful commercial product in their life; their expertise is in simply being a professional “expert” and their “expertise” changes with the hype cycle.  My second favorite are those tool vendors who preach about Agile, but then you find out that their own development teams don’t even use their own tools for it because they “don’t meet their unique needs…yet…” (I’m sorry, but if you are not willing to eat your own dog food, then why should I?!?).

So, you want to get started in Agile, but don’t know where to start?  One avenue is to try to do the whole emersion thing.  Good luck with that.  I’ve never seen it work unless you have trained Agile ninjas on your team who have actually been at bat on 2-3 successful efforts.  Another avenue is to start very simple and try to ratchet things up over time.

Here is what I’ve seen actually work.  I’ll share over another series of blog posts vs. trying to boil the ocean all at once.

Step 1:  Break your schedules in to a repeatable cadence; every band needs a drummer…

We’ve all used MS Project or similar at some point in our lives: great drawing tool; always out of date.  That said high level milestones are not a bad thing as they drive people to a common purpose and goal.  I use to love when somebody from outside of my organization would reach out to me and say “Lawler, there is a demo in a month. Can we show XYZ by then?”  or “We are now signed up to go to tradeshow ABC in two weeks–what can your team stand up?”  Milestone events, whether planned in advance or unplanned, are great rallying points.  They allow you to focus the team and charge towards an attainable goal without distractions.  They give people a mission and a reason to do what they do while working to a common cause.  Unfortunately, when these are random events, they make your team run and feel like a stuttering and sputtering engine as the cylinders just don’t fire all the time.  On top of that it also feels like the driver randomly alternates between standing on the gas pedal and taking their foot completely off; those in the vehicle are repeatedly rocked forward and backward in their seats.  Getting car sick yet?  Perhaps your teams are…

Now imagine a world where your team has decided to seed these milestones across your schedule at a regular cadence vs. at what appears to be random or unpredictable intervals.  Imagine a world where every three weeks, like clockwork, there is an event to rally around.  That at the beginning of each cycle the team agrees on the goals, divides the work, charges forward, and helps their teammates cross a common finish line.  At the end the team celebrates what it has accomplished.

Like a drummer in a band, you get a repeatable rhythm going. It is the heartbeat of the team.  With that rhythm comes the ability of the team to function as one; as a highly evolved organism vs. a blob of random cells.  The cadence becomes a habit and it evolves in to a reflex action; it just happens without thought or effort.

What is the “right” rhythm?  I happen to like three weeks.  Whereas a shorter cycle works for some teams, I’ve seen many more who have tried this thrash and burn out.  I also know that there are “official” Agile methodologies in all capital letters which dictate that the cycle be once a month.  I have also seen this work, but I’ve more often seen teams who have tried this not be able to predict or execute on their goals as four weeks is just beyond what they can get their heads around.  At the end of the day, I’m like Goldilocks:  Three weeks, although not intuitive, feels as “just right” after trying the other two.

What is one of the biggest sins that can be committed?  Breaking the rhythm.  Once you stop the cadence, anarchy kicks in.  You then have to spend a lot of time and energy retrenching, restarting, and getting a head of steam built up again.  You end up spending several turns of the crank getting the rhythm to feel natural again.  During one of these cycles, do you hit the stop button or change the goals?  I say absolutely not.  Finish it and let those changes be part of that next cycle.  Worst case you’ll lose a couple of weeks of work finishing a cycle.  If you stop the rhythm you’ll lose months of productivity as you work to get the cadence going and feeling natural again.

So, for those of you who are new to Agile I’ve just spent most of this blog entry describing what it means to do what Agilists call an “iteration” or a “sprint”.  Every methodology needs a common language behind it such that folks talking with each other can communicate efficiently.  In this case when you hear the terms “iteration” or “sprint” you are hearing about the labels applied to the time between these regularly spaced milestones that help set your cadence.

I would contend that if you are going to start with your adoption of Agile, I’d start with this repeatable cadence.  Start off by adopting the concept of having fixed duration iterations where the end of each is driving to a goal or a set of goals.  From this simple start great things will follow…  As Joe Isuzu use to say “Just trust me!”


From → Agile, Software

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: