Agile Open Space: On Certifications

The AgileAustin Open Space has kicked off. I found the opening session positive, engaging, really fun to be there. I'm chuffed because I felt confident enough to suggest (convene) a few sessions. One responsibility of a convener is to capture notes from the session. This blog post is meeting that responsibility.

Y'see, one of the sessions I proposed was entitled, "Certified ScrumMaster??" I wanted to gauge people's opinions of the CSM certification: Is it valuable, is it real, or is it just résumé-padding fluff?

I got my answer. The groans, grumbles, and rolled eyes around the room confirmed my suspicions. In this crowd at least, it is worse than irrelevant. It is counter to and detrimental to the philosophy of the Agile community.

After the proceedings broke into less formal conversations, I caught up with some community members whom I respect and enjoy. They elaborated on their earlier non-verbal remarks. It is not difficult to get a CSM; you attend a two-day class. That's it. That sounds like just enough knowledge to be really dangerous.

Why do we even need certifications? What does a certificate indicate about my real skills, abilities, and past experience? No, I inherently reject any model that sets up a gate-keeper-style hierarchy to knowledge—a system that says, "We know things; you don't. Your ideas and perspectives are not as good as ours until we bless you and permit you to be one of us (and your check clears)." I don't accept religions that do this, nor governments, nor software project methodologies, for Pete's sake.

The true flaw in the CSM is the name: Certified ScrumMaster. Go to a hiring manager and ask which she'd rather have, someone with 3 years' experience as a Scrum team member, or a Certified Scrum Master [trumpet fanfare]. Those in the know, know that ScrumMaster is the role; you hear it without the space. But to those who are not yet well versed in Scrum, it sounds like Mastery of the Scrum process; they inject a space between the words.

The Training page on the Scrum Alliance website says it plain: "The journey to mastery begins with..." and "These courses [CSM and CSPO] provide a solid foundation to help you make the paradigm shift to managing a project using Scrum." [emphasis added] They state straight up that this is the starting point. But the name of the certification doesn't say that. The opportunity for misinterpretation will get people into trouble.

Why does it get my dander up? Personally, because it threatens to be Another Damn Thing I gotta do to stay in the game. Professionally, because agile projects can be magnificent, and certifications smack of the process-for-process'-sake mindset that turns software development into a tedium. Philosophically, because neophytes will incorrectly elevate the merit of opinions from a Certified ScrumMaster, no matter how little experience he may have, and dilute and muddle the tenets of Agile.

Mike Cohn the other night joked about the CSM culminating in a tattoo. I don't know, man, I might put more stock in that, if the tattoo embodied the Agile Manifesto. (Embodied—ha!) It would at least convey the right level of commitment.

Globally distributed scrum

I'm on record as saying that globally distributed scrum teams can work, but sub-optimally. I'd like to retract and revise that position, so that something I'd said doesn't inadvertently lead a team down a poor path.

My team's scrum adventure lasted from March 2007 to April 2008. (Why does it have an end date? Buy me a beer, and we'll talk. But none of the people who were a part of or were affected by our efforts wanted it to end. The project was a success.) We started out with four developers in Austin, six developers in Bangalore, a Test Lead in Austin, and five testers in Hyderabad. I'll call this the Two Parallel Teams period. Team members were moved over time, so that we became two developers in Austin, eight developers in Bangalore, a Test Lead in Austin, and three testers in Hyderabad. This is the One Distributed Team period.

We had a good collection of team members, and I think we could have worked together very effectively, had the distance between our desks not been so great. I am not criticizing off-shoring; I am criticizing scattering your product owners, developers, and testers across different continents. Note who I included in that list there; if your dev team is co-located, but your product owner is far away, you have a distributed team.

We did not have a choice about where our teammates should be located, but we had influence over which project methodology we would use. So the choice was not "distributed scrum versus co-located scrum," but instead "distributed scrum versus distributed waterfall."

Do I still think distributed scrum is better than distributed waterfall? Yes, although with less unbridled enthusiasm. It required more meetings from all team members (including product owners) at crazy hours, but it still made it easier for the product owners to get the system they need; it still had us writing more code, more often, which is way more fun than fighting over contracts; and it still enabled productive, visible progress toward our goals.

We were happiest in our Two Parallel Teams mode. The developers in one city worked on one feature, and likewise for the other city. The only people who really suffered here were the product owners and the scrum master, who had to accommodate a ten-and-a-half-hour time difference to have their sprint planning meetings.

We offset our two-week sprints by one week, so that the testers could be shared between the two sets of developers. It worked okay because it did not require the "save state and hand off" process inherent in distributed teams. That process is, at the end of the day, you write an email explaining what you did, where your thoughts are about the work-in-progress, what you want your teammates to pick up, and what you want them to leave alone because it's currently too fragile to explain or share. It's like "hibernating" in Windows--save a snapshot of where you're at--and it takes time.

The more distributed the team, and the more they need to collaborate, then the more time will be spent handing off, and the team will be less efficient. In our One Distributed Team mode, the hand-off process overwhelmed the development process, so that more time was spent saying what you're doing than doing. This is the dangerous mode I want to warn people away from. If multiple people are collaborating on a feature, they have to be able to talk to each other, in person, real time.

There are still dangers lurking in the Two Parallel Teams mode. The most insidious is the way it undermines egalitarian, democratic, self-organizing decision making. For a team to decide things like designs, system architecture, even working practices, they have to be able to discuss and debate as a team. This requires trust, camaraderie, and personal safety. Those things are built in informal, day-to-day interactions--y'know, the way friendships are built. Over email and conference calls, they happen incredibly slowly, if at all.

You have to be comfortable with someone to be able to argue with him. The threads stitching together a global team are tenuous, and we operate with great delicacy to avoid snapping them. The communication channel is so anemic, you have to choose every word carefully, to ensure it does not accidentally offend. This is the opposite of having the confidence to know that, after we argue about this topic, we'll still be a team. Which means a lot of decisions go un-debated; they get made by default instead of by consensus.

Do I recommend globally distributed teams? No. Regardless of the project methodology, and no matter how talented the team members are, you will be dramatically less efficient if the members of your team are scattered over the planet. If you're off-shoring, then off-shore--put developers, testers, product owners, project managers, the whole team in one place. Software development is intrinsically collaborative. Structure your teams so that they may collaborate.

This experience gave me a taste, however, of how fun scrum can be. With a co-located team, you could seriously rock and roll.

Scrum of Scrums

Most of the developers on my team are in India, which means we're a little less than co-located. Yet we use scrum because it is still better than waterfall.

Early on, our strategy was to organize ourselves into two teams, and have the Austin-based team work on feature A while the Bangalore-based team worked on feature B. That way, we could reduce the impact of our globe-spanning timezones. (There are no normal working hours that overlap for either group. 11.5-hours difference.) We would stay out of each others' way and hardly need to talk at all.

...Hardly need to talk at all? Yeah, that should have caught my attention right away.

But we do learn—this is why we have retrospectives. Exceeding any conference-call discomfort was the pain of not knowing what our teammates were doing, not being involved in additions to our code, not collaborating on a shared, emergent design. So we set both groups to work on the same feature, and scheduled more conversations.

We have two conference calls a week, one in the morning, one at night. Morning-aligned people take the early one; night owls attend the late one. The calls are just for developers, to talk shop. Some of our topics include:

• What we've done so far and what we're doing next;
• How we'll structure our database tables;
• The business domain;
• Suggestions for improving the code.

I've started to enjoy these calls. Not only are they useful (essential, even) for building a coherent application, they are forming the social glue that allows us to collaborate and argue about the design, pulling us together into one effective team.

Convincing through Understanding

People resist change out of fear. Winning people over to change requires identifying, discussing, and collaborating to resolve their fears.

I had the opportunity last week to talk with a small software company about what's exciting about scrum. My battle scars all come from years in a BDUF (Big Design Up Front) shop, so I was non-plussed to find that this small, smart, co-located group was looking to scrum because they craved more structure. It's an important reminder: Agile methodologies are processes. They're just processes for adapting to change, instead of anticipating and squelching change.

Not everyone in the audience was a fan of scrum. Some were skeptical, or intrigued but full of questions, while others were adamantly opposed. A totally different company from the one I work for, yet the objections were eerily similar:

• Maybe that works for a [big/small] company, but it won't work in our [small/big] company.
• More meetings?!
• We don't have enough resources for [testing/support/pair programming/a Scrum Master who isn't a developer].
• Constant feedback? That's so disruptive. They keep changing their minds. I'll never get anything done if I talk to them every day.
• If you build the architecture as you go, what if you get it wrong?
• When do you create documentation?
• Who prioritizes the requirements? How do you prioritize? How do I get infrastructure and foundation pieces onto the list?
• How do you know if you're on time?
• I prefer my private cubicle. I don't like talking with people all the time. I'd rather be efficient than social.

You can hear the fears behind these objections if you listen openly:

• I know how to do what we do, and you're talking about changing how we do what we do. That's going to make me look less competent.
• I'm stressed about deadlines and my workload, and it sounds like you're increasing my workload.
• I'm constantly harrangued about dates and deadlines, and you're proposing a deadline every [1 to 4] weeks. That sounds like incessant stress.
• My past conversations with my [customer/user/business partner/product owner] have been abusive and dysfunctional. Every time they tell me what they really want, I have to disappoint them because of resource constraints. They have no faith in our estimates of effort or duration. I can't convince them to invest time in supportability, maintainability, or scalability requirements. There's no love here.
• Face it, I'm an introvert. Why do you want to force me to be extroverted?

Once you're hearing what people are really telling you, then you can discuss the underlying concerns. Together, you and your audience can collaborate to clear up those concerns. What was initially a roadblock—a rigid resistance to change—becomes a challenge to be solved together.

I feel like a big cheese monkey for quoting The Seven Habits, but it's elegant and succinct on this point: Seek first to understand, then to be understood.

What tools do you use?

I've been meeting with other teams at work who are curious about how my team is using scrum. The most common first question is: "What tools do you use?"

I've finally hit upon the answer. Previously, this question had been so daunting to answer because it is inherently the wrong question, when you're just starting out. At least, if you translate "tool" to mean "software application." eScrum or Mingle or VSTS does not make you agile. Your philosophies and your strategies make you agile.

Here are the tools that we use:

1. The Agile Manifesto.
2. Shared sense of ownership, where developers, testers, and business people have an equal stake in, and equal responsibility to, the success of the project. We're all pulling together.
3. Rigorous software engineering practices, especially source control, continuous integration, readable (soluble? grokkable?) code, and automated unit tests.
4. Communication. All the damn time. As much like face-to-face as you can manage. We do our best with a globe-spanning agile team; if your teammates all reside in the same city, then for goodness sake take advantage of that luxury and meet in person.
5. Frequent feedback, in many different forms. CruiseControl always tells us the health of our build; testers are testing functionality every day; business partners are reviewing and providing corrections all the time. The elapsed time between making a change and knowing if it is good is as short as possible.
6. Retrospectives, where the team talks honestly and candidly about what is going well and what could be improved, and then takes direct action on those improvements. Contrast this with end-of-waterfall "Lessons Learned" sessions; by the end of the project, it's too late, there's no point in trying to implement any changes because you won't be working with these people. Instead, meet every week or two weeks, or whatever works for your team, to decide what you want to do together to help your team.
7. Empowered, self-directed team members, who collectively decide what fits best with their team. I'm happy to tell you which tools (from the "software application" sense of the word) we use and how long our sprints are and what processes we follow, but your team is best qualified to determine what will work for your team.

From this sense, what tools do you recommend?

Why scrum?

Why not scrum?

Until about January, our shop had been significantly process-encumbered. Where we could, those of us who cared implemented small strategies for improvement—preaching code readability, meticulous source control, building as if your code will still be in use five years from now and you will be the poor slob maintaining it—but we're talking about an organization that lauded a Roles & Responsibilities Matrix of 99 line items, of which one said "Source code and executables."

And then there was a culture shift. You could feel it. It felt like stepping on an invisible extra top step, and then seeing the sun break from behind four years of cloud cover. Leadership changed, and everything became possible.

My teammate Josh came to me with this notion of scrum, a light, responsive, democratic way of collaborating on software. He recommended a book, Ken Schwaber's Agile Project Management with Scrum, which is always the best way to get my support on something.

This book made me want. Deeply and acutely, I wanted to work like that, to feel effective, productive, valued, and fast.

First we convinced our developer teammates, then our project manager, then our manager. We tried to convince our test lead, got a new test lead, and convinced the testers. Then our business partners (now, Product Owners), who were the easiest to win over of the whole bunch. We even convinced the process people, provided they were allowed to observe, document, and possibly codify our process. Permission had been granted. I felt drunk with relief.

Which was naive, of course. I still need to explain, justify, define, and defend, every day. The wanting has not in the least abated. In fact, after eight sprints and a successful deployment, love notes from users and cake from the Product Owners, and rowdy basketball games with our visiting India-based teammates, I couldn't bear the idea of going back to waterfall.

So I'm visiting other teams, plucking up my courage to ask pointed but polite questions to senior managers, setting up speaking engagements, hanging out with other agile-oriented troublemakers, getting tips from my dad, and generally fighting the good fight.

It's often scary and wearying, but absolutely worth it.