I hope I don’t end up with a seized engine on the side of the road, but if I do, I’ll know I should have had that oil change. I hope I don’t end up on the Worst Dressed List, but if I do, at least I’ll know I should have given away those old shirts.  I feel sorry for those on the “Worst Agile Implementation” list who don’t even know they’re there.

In the past few months I’ve had the privilege of talking to approximately fifty organizations about their Agile implementation.  Most of them are doing well, and many of them have great insights about how they customized Agile to fit their process requirements.  But some of them really Say the Darndest Things.

“We do Scrum, it’s just the rest of the company doesn’t.”

“So first we break the requirements specification into pieces and call each of the pieces a story.  Then we do our iterations and pass them off to the release team.  We’d sure like to get Product Management, QA, and the customer involved, but they don’t want to.”

There are a lot of places an Agile approach can add value, and I’d hate to adopt a “waterfall approach to going Agile”, but you’re really not doing Scrum.  The biggest chunks of value, the incremental use of customer feedback, and going from “completed state” to “completed state” in each iteration are lost if you can’t get more support.

“We’re Agile until the development is done.”

More than once I’ve been speaking with an earnest development leader who’s describing the Scrum process.  They’ll launch in, with obvious pride, and tell me how they’ve gone to two week iterations, do standup meetings, and work from a backlog.  “Terrific!  And how do you do QA?”

Oh, yes, of course they do QA, silly!  In fact, they demo the completed development to the QA team every sprint review and send it off to get tested.  Sometimes, unfortunately, QA actually finds some bugs that need fixing.  So that’s why they put the sprint on hold for a while to fix the bugs and loop them back into QA “’cause we don’t want to wait an entire sprint before they can restart the testing.”

The other side of this one is the guys that take the old “Release Tail” loophole for all it’s worth.  “Yes, Lorne, we’ve been agile for three years now.  We do Scrum, unit testing, standups, and play in the World Series of ‘Planning Poker’.  We do that for about six weeks, or until the release.  Then we have a three month release testing tail, which follows a ‘modified Scrum process’ … the project leader estimates the amount of work on each bug QA finds, and assigns it to a developer.  Sure, sometimes we have to work on new functionality during the “release testing tail” … you can’t expect the customer to stop needing improvements for three months!”

Folks, I don’t think I’m sharing any great trade secret when I tell you the QA process needs to be completed before the story is considered “done.”  I don’t want to be Klaus Fuchs of Scrum, but here’s the secret: you’re going to have to invest more in testing up front.

“We do continuous integration every night.”

I blame the education system: how’s an engineer supposed to know what “Continuous” means when we have “social promotion!”  Now some people understand the idea of continuous integration, and made a conscious effort to make it more “Discrete”.  Some companies I talked to had broken builds that lasted for a week.  You’d rather have a child repeating “Mummy” every 30^th of a second before you’d like to get an email every five minutes saying the “Build Failed.”  I get it.  And if the email was going to your boss too, well, you don’t have to be Dogbert to know that’s a bad idea.

Builds are going to fail.  Get used to it.  The problem is not that the build failed, but that you couldn’t fix it.  Good practices are to have the team drop what they’re doing when the build fails and hop on fixing it.  If they can’t fix it, it needs to get escalated *pronto*.  Better is to have the team do local builds and unit testing before they check in.  Best Practices are to divide up the build process by team and stage of development, so your team only pollutes itself, not the rest of the development org.

“We don’t need training since we can use the internet.”

Uh huh. So I guess the schools will be shutting down any day now.  Not that the Internet might not turn out to be a useful aid someday, but the software development process is a hands-on activity.  And similar to other hands on activities, like dancing or carpentry, you can’t learn to do it by reading a book.  You’re going to need to get some experience with the process before you understand how to run a sprint review or a stand up, how to estimate stories, and how to work with your QA partner.

Now if you’re a hobbyist and working for free, your time is cheap, and there’s no reason not to use trial and error as a learning method.  But if you’re getting paid, and your work is important, you really don’t want to waste four sprints figuring out what someone can help you get right in sprint two.

I’m hoping my surgeon, pilot, and barber got a few lessons before it was my turn.

Finally…

No one has to pass a test to call themselves “Agile,” nor should they. Agilistas don’t have a monopoly on the right way to develop software.  But when people believe they’ve made it to Agile without using critical Agile concepts like time boxing development or getting to “done”, they’re missing the real value.

A New Language

As teams adopt Agile development methods, often a new sort of vernacular emerges. To those unfamiliar with Agile, it can sound quite foreign when these groups start rattling on about this or that. I thought it might be fun to list some of the phrases or activities that may have had an entirely different meaning before I went Agile.

Agile Terms Before We Were Agile

• XP was just the operating system running on my parents’ computer that I was constantly fixing.
• Scrum was something done on a muddy field by people much tougher than me.
• The term waterfall evoked beautiful memories of hikes in Hawaii instead of painful ones of past death marches.
• The idea of pairing with another co-worker was strictly forbidden by HR policies.
• Similarly, playing  poker in the conference room was generally frowned upon.
• The notion of sprinting for a week or more was insane.
• An epic story was something like Beowulf or the Iliad.
• Lean was my signature club dance move.
• The words burn and chart were never used in a positive sense.
• I wouldn’t have imagined sitting in a meeting with chickens and pigs.
• The word agile was the last word used to describe a group of software developers.

How about you?

For more information on Agile terms, visit the Agile glossary.

My job here at AccuRev involves working as an “Agile Evangelist,” and along with the other Evangelists on my team, we have appropriately named ourselves “Team AgileCycle.”  Prior to our AgileCycle product launch, AccuRev took a company initiative to bring Agile into every part of the business.  The idea was to bring an educational awareness of Agile process to all of our teams by implementing basic Agile practices.  ”Team AgileCycle” was responsible for bringing Agile to the sales team, so our salespeople could have a taste of what Agile development was really all about.

(I should point out that we do realize sales organizations and development organizations are vastly different, and certain Agile practices can’t be applied to a sales cycle. But we did see great opportunities to pick up Scrum methodologies and usefully apply them to help within our sales organization.  Some of the changes we made do not qualify as not “pure” Agile, or even best practices, but the point of this exercise was to expose our team to some of the things software developers are doing in the real world.)

Implementing Agile Step 1: Sales Scrum Training

At AccuRev, we subjected our sales organization to Certified Scrum Training. In this training we walked our team through the different phases of Scrum: planning sessions, standups, and retrospectives.  We even exposed the sales team to planning poker when walking them through typical development cycle.

Implementing Agile Step 2: Implement Sales Standups

The next step was to take what we learned, and actually implement it.  At AccuRev, we now have multiple standups with our sales team, in order to obtain feedback quickly and learn what our customers are saying in the field about AgileCycle.

Implementing Agile Step 3: Mark Out Sprint and Retrospectives.

In the sales team, this is simple. Our iteration is once a quarter.  I would never suggest a development team implement this long of a sprint, but for sales it works. At the end of the sprint we got together and performed a retrospective, which discussed results for each territory, reviews of our processes, and brainstorming for the next quarter.

Implementing Agile Step 4: The Task Board

In the “Team AgileCycle headquarters,” we maintain a task board. Here we take all of our goals and tasks for the quarter, and mark them out as “backlog,” “in progress,” and “complete.”  (We’re still working on how to measure our story points, but the basic process is that we plan our backlog with our quarterly goals. When something else comes up, we fill the backlog with those tasks.)

And even though this task board seams simple, it actually wields a lot of power and has become a great tool in organizing our work.

What has surprised me the most during the whole implementation process is just how well the sales cycle seems to match specific Agile methodologies already. Think about this:

We already built in an iteration time: 1 quarter

We had planned velocity already: Sales to make this quarter

We inspected and adapted: If the numbers were not met we wanted to understand why. If we weren’t on velocity we changed course.

We had Scrum meetings before it was called “Scrum”: Weekly status and impediment meetings.

Burnup chart: Heck, the sales meter in Salesforce could even be compared to a burn up.

So after all of this, my question is:  Are sales teams “naturally” Agile because of their business? How similar is a highly functioning sales organization to a highly functioning Agile Development Organization? What do you think?

AccuRev has been down in Orlando at Agile 2010 for almost a full week now, and if you haven’t stopped by the booth to say hello to us yet, I encourage you to do so!

Damon Poole, AccuRev CTO, wrapped up a series of three Agile sessions today, and was pleased with the outcome.

“I think the sessions went really well, people were excited for them, I was excited for them, but ultimately I hope everybody learned something valuable” said Damon.

His presentations were titled “Scrum and Kanban- Like Chocolate and Peanut Butter,” “Getting Managers and Agile Teams Out of Each Others Hair,” and “Managing Growth Pains on the Way to 40 Scrum Teams.” (See “Three Days with Damon Poole on Agile Development and its Components” for more info).

Damon’s first session at Agile 2010, “Scrum and Kanban- Like Chocolate and Peanut Butter,” attracted a large crowd, and unfortunately several people were turned away.  But as he promised, we are posting all of his presentations in the AccuRev blog.  You can download Damon’s presentation of  “Scrum and KanBan- Like Chocolate and Peanut Butter” here.  Enjoy!

Here is one more AccuRev vs. ClearCase video to share.  And this one is a crowd favorite.

AccuRev vs. ClearCase in ClearCase Multisite Unsynced

Sure, we all know geographically distributed development teams face lots of challenges.  But ClearCase doesn’t provide a simple solution to this problem.  In fact, with ClearCase Multisite Unsynced, teams have trouble syncing up and don’t allow developers to work the the same branches at the same time.

With AccuReplica from AccuRev, all remote teams can work together and on the same code, like one co-located development organization.

Due to positive feedback from our first blog promoting AccuRev vs. ClearCase parody videos (see the post Issues with ClearCase?), and seeing as ClearCase has not addressed the needs of modern software developers in years, it seems only fitting to share a few more.

Rationally Wrapped

While ClearCase users deal with complicated wrappers and scripts during upgrades, AccuRev is easy to use right out of the box, and doesn’t need any wrappers or scripts.

Developers Revolt

Locked out of ClearCase again?

AccuRev will never lock developers out.

Do these issues resonate with you and your development team?  Read more about how AccuRev auto-synchronizes with ClearCase, providing developers the ability to get up and running with AccuRev at no risk!

While the AccuRev blog rarely digresses from its serious and technical nature, an opportunity to inject light and humorous content has arisen.

About 3 years ago, AccuRev released a series of short parody videos based on customer feedback that compared AccuRev and ClearCase, and even today, the amount of views continue to grow.

While one might think the videos are now outdated, being 3 years old, they are still very much applicable today because, well, the same ClearCase issues exist…

Example 1: ClearCase Installation.

Installing Rationally

Of the many differences between AccuRev and Clearcase, the first can be seen during installation. How long does it take ClearCase admins to install ClearCase? Hours? Days?  AccuRev’s smaller server eliminates the issue of multi-day-long installations.

Is this rational?

I love the concept of self-managing teams.  Everyone figures out what needs to be done, and does their best to make the greater organization successful.  Beautiful.  Reminds me of the Shaker Village, the Russian Artel, or the Israeli Kibbutz.  All of which are (largely) extinct today.

There are three structural problems that, like termites behind the wallpaper in a French Quarter house, cause these “worker’s paradises” to fail.  Our job, as managers of the Innovation Engine, are to sniff ‘em out, expose them, and exterminate them.

Problem #3: The Buck Starts Here.

For all the happy talk about mission, values, and meaningful work, the ultimate metrics for business are financial.  Our inability to grow, make profits, secure new investors, etc., will ultimately end our ability to accomplish our missions, support our values, or provide work to our employees and worse yet, ours bosses. That’s the bad news.

The good news is that we managers can use money (or their engineering equivalents, people) to accomplish great things.  Which things we choose to accomplish is largely up to us.

No, that doesn’t mean we want to create our own user stories, and reprioritize the backlog to meet the requirements communicated to us in our sleep by our deceased pet snake.  That’s the product owner’s job.

The Scrum process, like its Lean predecessors, is based on incremental improvement.  That’s great for two reasons: first the changes are small enough that we can get them done and see the results before the environment has changed, and second because they are small enough in scope that the individuals in development or product management can understand and control them.

We managers have to see the bigger picture, and that generally means determining the funding level for each of the initiatives we have.  Adding people to a team will eventually, not withstanding our bad management, increase its velocity.  Pulling people off will generally do the opposite (although not as quickly as you might think …….).

The optimization problem for the overall success of the organization involves lots of variables, but that’s really why they pay us the big bucks.  Is this group servicing a stable and productive customer, while this other group is struggling to overcome a mountain of technical debt?  Are competitors starting to emerge for what has been a stable area? Has this project achieved most of its goals? Is it time to determine what should be the next big initiative?

The purely business and marketing side of the equation is usually an area of influence, not control, for the development manager.  But the assignment of resources to projects is the execution of that strategy, and requires management comprehension and “buy-in.” For those of you uncertain, the term “buy-in” refers to agreeing to do something you’d really rather not do at the risk of losing your job.  It’s been around a long time, but has flourished in the recession.

On the technical side, there are important funding issues to consider.  One of the biggest is the effect of architecture on the overall success of projects.  Studies have demonstrated that one of the biggest factors in ROI for IT initiatives is the quality of the underlying architecture.  Should you add features to your Windows XP app, re-write it to run on an i-Phone, or re-write it to run within your CRM system?  Big questions with lots of impact both in the short term or long term.

Conclusions

Senior engineering management is a tough job with many tasks and responsibilities, too numerous to list here, but including team dynamics, people management, strategic funding decisions, and golf at expensive resorts.  Middle management has similar responsibilities, without the golf.

Great organizations are rarely the product of good luck.  Great leadership recruits the right people, puts them in the right roles, identifies problems and fixes them, and looks ahead at trends to make sure resources are assigned to the right places.

In Scrum, this doesn’t require a lot of managers, but does require of lot from managers.  Empowering managers to act, and ensuring that they do, is critical to the long-term success of your Agile organization.

I love the concept of self-managing teams.  Everyone figures out what needs to be done, and does their best to make the greater organization successful.  Beautiful.  Reminds me of the Shaker Village, the Russian Artel, or the Israeli Kibbutz.  All of which are (largely) extinct today.

There are three structural problems that, like termites behind the wallpaper in a French Quarter house, cause these “worker’s paradises” to fail.  Our job, as managers of the Innovation Engine, are to sniff ‘em out, expose them, and exterminate them.

Problem #2: PURE – Previously Undiagnosed Recruiting Errors

My old boss used to tell me there were three kinds of programmers.  Those smart enough to do the job, those too stupid to do the job, and those that could do the job but don’t care to.  Well, that’s not exactly the words he used, but this is a family blog.

None of us is the perfect recruiter, and every once in a while people get through the screening process that we’d rather have work for Al Qaida.

The incompetent developer (which we managers code name “moron”) is not always the one who takes the longest to do a story.  If some developers generally take longer than average to complete a story, they may be “slow” (as my grandmother would have put it) or the estimates may be dominated by optimists.  Until you’re measuring the amount of rework created by bugs found in QA (and the field), you really won’t know.

That doesn’t mean you don’t have to take action: managers have been acting on intuition since the Donner party decided to try the Sierra Nevadas in the winter of 1846.  Sometimes it’s better to eat the mule than have the whole group starve.

As engineers we tend to focus on technical proficiency, but there are some things which are hard to judge in an interview.  Like whether a developer has good judgment of when to refactor and when to patch.  Or whether a developer can embrace process changes or will struggle for weeks with the changes.  Or whether a developer has that certain combination of personality traits that make their coworkers doodle pictures of poisons, weapons and torture devices.

Now finding the sociopath may be more difficult than you think, because they’ve cleverly chosen to hide out amongst programmers, most of whom act as though still carrying scars from middle-school.  Like a submerged rock in the river, sometimes they can best be detected by the havoc they leave in their wake.

Developers generally treat managers using the same rules the Mafia use with the DA: no matter how much we loath our co-workers, we’re not going to rat them out.  One-on-one meetings with group members can give some indication of problems.  A few tactful questions at retrospectives may give some clues to underlying issues that aren’t being discussed.

Try inviting the group to try a little pair-programming and see what pairs get put together, and who threatens to quit.

Finally, the toughest people management issues are when good performers drop off.  Often this is a temporary fluctuation which just requires some coaching: do they need some customer visits to increase motivation, maybe a chance to learn some new technology they can apply, or sometimes there is a transient personal problem that just needs a little extra time.

Often, establishing expectations with people of what needs to be improved and then giving them a little time to do so is just the right prescription.  They may need mid-course correction and coaching to improve.  They might just need a supportive shoulder, or a swift kick in the pants, but the combination of communicating the issue, establishing higher expectations, and providing support is a good combination for improving performance.

Unfortunately, persistent decreases in performance are usually like that oil leak under your car every morning: they indicate there’s more going wrong than you thought, they’re probably going to get worse, and if untreated the future isn’t going to be pretty.

The most common mistake I see in my conversations with engineering management is the “conflict avoider.”  We’ve all made excuses about how long we need to wait to see if the situation can improve, how hard it is to find new talent, how much training time and ramp-up it is going to take to get a replacement up and productive.  And don’t forget the ‘ole disempowering “I can’t make a change in the middle of the project!”

These are just excuses. We owe it to both the team and the company to accept our mistakes, make the changes, and get on with building a better future.  That’s what we get paid to do.