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.

AccuRev is going to Agile 2011! Stop by the AccuRev booth to say hello, enter to win our great give-away, or see the new AccuRev version 5.2 demoed.

Session hopping? Make sure you attend Damon Poole’s session, Scrum and Kanban, Like Chocolate and Peanut Butter on Wednesday, August 10th, at 3:30 PM in Imperial Ballroom A. You may wonder how Kanban can help with your real-world process problems. Damon will discuss Kanban from a Scrum perspective, show how the Lean practice of “One Piece Flow” is the key to both, and look at how to mix and match Scrum and Kanban to fine tune a process that fits your circumstances.  

I remember the first time I heard the term scrum development.  A manager at a previous job told me “We’re doing Scrum now, read this.” Then he handed me bunch of photocopied book pages.

After a comprehensive review of the pages, all I figured out was that Scrum had something to do with fast meetings every morning. And that was my first introduction to Scrum.

At a later job, I found myself in a meeting, brainstorming the best way to make Scrum work internally, and arguing over what Scrum was supposed to look like. Both situations, a minimally explained stack of photocopies, and arguments over the physicality of Scrum, resulted in negativity- people around me decided that “Scrum doesn’t work.”

How Scrum Works

In my situations, trying to make Scrum work took precedence over the team, and whether or not it could really take advantage of Scrum practices. Taking advantage of Scrum practices is what makes a Scrum team succeed. After all, the development term “Scrum” was derived from rugby for a reason.

The name Scrum was chosen to represent specific software development practices because like Scrum team in rugby, one team needs to cover a variety of responsibilities. This team works towards a common goal, continuously, in parallel, and under circumstances that could, and do, change rapidly. In rugby, the Scrum team needs to cover ground together. The clock never stops, teams never switch sides, and the ball can only be thrown backwards or sideways, forcing the team to move together in a line across the field. Similarly to Scrum in development, all team members need to know their teammates status, so they become aware of new gaps in the field position that need to be covered. In this aspect, the team needs to be self-managing, while it pushes the ball forward in sprints. This can’t wait for outside direction.

If your team is new to scrum, or struggling with it, the tendency to blame Scrum practices instead of a team’s unity often highlights deeper problems. If a member of a rugby team isn’t keeping up and leaves a gap in the line, no one would say ‘rugby doesn’t work’. The word ‘team’ gets thrown around business a lot when ‘group’ would be a better description. A team communicates with each other, strategizes, and members know how to truly work together- not just in parallel.

Functioning as a Scrum Team

In the film Invictus, Nelson Mandella tells the captain of the South African national rugby team that he needs them to win the world cup to gain the support of the nation. Players complain that their schedules are already full, and extra work like running rugby clinics for children isn’t worth their time. But after working together on these clinics, the team became much more focused and productive when it came to new responsibilities. As the captain said “We’re more than a rugby team now, we need to get used to it”.

The expectation to function as a team is built into scrum. If a group has seen previous success without having to self manage, or without leaving their keyboards for things like planning meetings, there will naturally be complaints that scrum isn’t working. In some cases teams may need to tweak Scrum in order to fit a specific organization, but before making changes it’s worth looking to see if your team is functioning like a team, or like a group.

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?

Who? Damon Poole, AccuRev Founder and CTO, Agile expert and popular speaker.

What? Presenting “True Agility Requires Us to Re-examine Our Beliefs” for Nashua Scrum Club.

Where?  45 High Street, Nashua, NH 03060

When? Thursday, September 9, 2010

Why should you attend? Damon says “Too many projects that “go Agile” are actually far from true Agility. They end up reverting to old habits or just change the labels on the activities that they are doing without changing what they actually do on a day to day basis. As a result, many so-called “Agile” projects get few if any of the benefits of Agile and some are even worse off than before! Why does this happen?”

This session will give you an opportunity to uncover and re-examine your mental model of software development by taking a look at the top ten Agile blind spots. This will allow you to discover the blind spots you or your organization may have so that you can work towards removing them and start experiencing the full benefits that true Agility offers.

Visit Nashua Scrum Club to register!

As you have been seeing in the blog and on AccuRev’s Twitter feed, I spent last week at Agile 2010.  I thought it was a great show- I met a lot of interesting people, led three big Agile sessions, and even got to ride Epcot’s Test Track.  It was definitely a fun and eventful week in Orlando!

To thank you for your support this year, I promised to post my presentations in the AccuRev blog. The presentation from my first Agile 2010 session, Scrum and Kanban-Like Chocolate and Peanut Butter, has already been posted in case you missed it or were turned away.  (Agile 2010 volunteers ended up brining extra chairs into the event room but lots of people were turned away due to fire code restrictions.)

Here are the other two presentations I gave later on during the conference week, enjoy!

_____________________________________________________________________________________________________________

Damon’s Agile 2010 Retrospective

In an effort to drum up ideas for next year’s Agile conference, I started asking some of the people I met with, “Why do you come to conferences like this?” I received a variety of answers and created a little retrospective video, all with my iPhone 4 and iMovie.

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!

Agile 2010 is fast approaching, and AccuRev is excited to sponsor and support the Agile community involved with this conference.  However, our excitement is partly due to the fact that Damon Poole, AccuRev’s CTO, was chosen as a featured speaker for not one, not two, but three sessions during the conference week.  I sat down with Damon to chat about his Agile 2010 plans, the ideas behind his session topics, and ultimately, the unrelated topic of my recent exposure to Star Wars.

Star Wars aside, Damon has some great talks about Agile development and components planned for Agile 2010.

Damon’s Discussions on Agile Development and its Various Components

Damon’s first Agile 2010 session will take place on Tuesday, August 10^th at 1:30 PM and is titled “Scrum and Kanban- Like Chocolate and Peanut Butter.”  Here Damon proves Scrum and Kanban are not in fact mutually exclusive, but play well together, much like chocolate and peanut butter.

KE: “So Damon, how did you come up with the chocolate and peanut butter concept?”

DAMON: “I have witnessed infighting within the Agile community, between Scrum advocates and Kanban advocates.  Agile is a way of thinking, and the community wins when there is a synergy between camps.  I want people to recognize that not only can Kanban and Scrum co-exist, they can actually be a very beneficial combination to development teams.”

KE: “Who might this session be best suited for?”

DAMON: “I would say this session is for folks that are already doing Scrum and are curious about Kanban.  I will address Kanban basics, how Kanban can help with real-world process problems, how to apply one-piece-flow to Scrum, and the value of work-in-progress limits applied to Scrum.”

KE: “Since it’s about chocolate and peanut butter, will there be Reese’s?”

DAMON: “You bet.”

__________________________________________________________________________________________________________

The following afternoon, Wednesday, August 11^th at 1:30 PM Damon will present “Getting Managers and Agile Teams Out of Each Other’s Hair.”

KE: “This sounds like an interesting Agile pain point that lots of us can relate to.  How do you approach this topic?”

DAMON: “Well, one of the most talked about, but least understood components of Agile is the ‘self- organizing team.’ There is little research published on this concept and I spent a lot of time looking outside of software development for information and advice on self-managing teams.  I came up with new perspective on this concept by examining external roots of the practice.  What it is, what the benefits are, how it works.  I will share my advice on manager roles and responsibilities, aspects of self-organization enabled by multiple Agile development components, and challenges that teams face.  It should be a good session, I have given it before and it’s always well-received.”

_______________________________________________________________________________________________________________________________________________________________________________________________________

The third day with Damon is on Thursday, August 12^th at 9:00 AM. He will present “Managing Growth Pains on the Way to 40 Scrum Teams”

KE: “Forty Scrum teams is getting up there.  How would you recommend managing such large amounts of teams?”

DAMON: “You’re right, 40 Scrum teams is the sign of a large organization.  I have interacted with lots of large Agile shops that operate with many more than 40 Scrum teams, and noticed issues with Agile weren’t all that different from shops with smaller teams.  By recognizing trends and patterns sooner than later as the organization becomes deeper involved with Agile, teams can start following certain practices to eliminate issues.  When it comes to addressing issues, the sooner the better.

KE: “What best practices have you recommended to larger-sized Scrum teams in the past?”

DAMON: “Multi-stage Continuous Integration, small story size, collocation, cross-functional teams… a few more.  This is a good session even if your organization doesn’t have 40-something Scrum teams today.  It teaches you about growing pains and prepares you for future growth.

Well, Damon sure sounds like he has a busy week lined up at Agile 2010.  Make sure to check out his sessions- they are featured on the Agile 2010 schedule and under the “What’s Hot” tab in the Agile 2010 app for iphone and Droid, so don’t forget to add Damon’s sessions to your schedule via these apps!

Follow AccuRev on Twitter @accurev for Damon’s latest updates from Agile 2010!

When talking about Agile development, people often ask me, “but why would I want to change to a new methodology when traditional development has made so much money and created so much value for so many people for such a long time? Why mess with success?” That’s a great question!

After hearing that question for the umpteenth time I finally realized something.  It isn’t traditional software development that has provided so much value! It is the software itself. Imagine calling a travel service prior to the advent of software. You call them up and say “I’d like 100 or so options for travelling from Boston to San Jose. I’ll also need a bunch of 3 or 4 star hotels in San Jose and mid-sized rental cars to choose from.  Could I get that in 5 seconds please?”

In today’s world, of course you just go to a site like Orbitz.  It isn’t traditional software that provides that value, it is the software itself.  It almost doesn’t matter what process you use to produce that software, the value is so high. When you are only competing against somebody that doesn’t have software, that’s one thing. When you are competing against other organizations that are also using software, then the exact process you use can make a big difference from a competitive standpoint.

What do we mean by “traditional development?” After having been involved in the process of literally thousands of software development organizations, I can safely say that there isn’t really any such thing as “traditional development” or even “waterfall.”  That is, if you look at any two organizations developing software, there is no standard for what comprises traditional development.

In the end, organizations adopt individual practices that make sense for their circumstances. This same approach can be used when adopting “Agile.” There really isn’t any such thing as “Agile.” It is a combination of values and practices which can be adopted by any organization and does not require wholesale adoption in order to provide value. Yes, there are packaged solutions out there such as Scrum, XP, Kanban and others, and they do provide value.  But so do the individual practices.  So, instead of thinking about “how do I switch to this new thing,” consider Agile as a new set of tools that you can add to your existing process on a case by case basis. Worry about “being Agile” after you’ve gotten some experience under your belt with some of the practices.