The Scrum Yahoo! group is again undergoing some minor turbulence about proper use of the list. Someone from the Scrum Alliance laid out the law with a number of rules about what could and could not be posted to the list. Many people reacted poorly–supposedly this is the poster’s first post, and he’s not even a Certified Scrum Master (CSM). (gasp!)

Oddly, a year or so ago when there was similar agonizing over the use of the list, it appeared as if L. Ken Schwaber “owned” the Yahoo! group and thus controlled(an important word in the Scrum community) appropriate content. Not that there’s anything wrong with that. For those who like command & control, with the additional potential of being part of a good multi-level marketing machine, the Scrum system provides a wonderful starting point.

The nice thing is that you can still do Scrum and talk about Scrum without succumbing to the controlled community that is S©rum. As far as I know, there’s no licensing scheme required to be able to say, “I’m doing Scrum.” And that’s exactly what I’d recommend. No annual maintenance fee required! No required trainer tiering! Yes, you need a Scrum Master in order to successfully execute Scrum. But I don’t believe they must be “certified.” (I could be wrong–perhaps I need a lawyer here!)

Where might you find a good Scrum Master? Well, you should probably read L. Ken Schwaber’s book, Agile Project Management With Scrum (that link is my piece of the Scrum machine’s gravy train, by the way). You’ll quickly discover, through a number of case studies that L. relates, that Scrum and S©rum are mostly a matter of executing to common sense, best done by someone with good experience in people-oriented problem solving and leadership. Find someone who can do that well, and hire them. It really doesn’t matter if they’re a CSM.

Agile and PHBs

We all think Scott Adams has worked in our offices, given how often conversations between Dilbert, his co-workers, and his PHB (pointy-haired boss) seem like conversations we’ve just had. I remember some discussions with management about metrics; the very next Dilbert strip read like someone had recorded our conversation.

Today, Dilbert’s PHB paraphrases agile programming to mean “no more planning and no more documentation.” The PHB directs the team to “just start writing code and complaining.”

That’s precisely what many people think agile to be. It’s why I often curse the notion of big-A “Agile.” Buzzwords almost always end up suggesting equally succinct negative connotations. I spoke recently at a BA conference, and my audience quickly confirmed their perception of agile met these the big myths: no planning and no documentation.

I won’t belabor an argument. Basically, to do agile well, you must plan all the time. And with respect to documentation, agile generally says that documentation is a cost that must be recognized. It doesn’t say don’t do it; it says prioritize documentation with respect to its business value.

In the final panel of today’s strip, the PHB says to Dilbert, “That was your training.” In fact, that’s often all training is nowadays. A concept is distilled into an article, or even two sentences, and the corporation feels that it has adequately trained its people. I’ve actually heard management suggest that its people should be smart enough to seek out and understand new concepts completely on their own.

Yes, agile is a fairly simple concept. Yes, training courses only provide so much value. But there’s enough in agile to get wrong and misinterpret that you’d be a PHB were you to ignore the need to properly train your teams.


Hear hear!

Sadly, in process as well as in politics, often you are stuck with nothing more than the sound bite.

A Case for Pairing: Open Workspaces and Distractions

I currently work as part of an agile mentoring team in a large organization. Up until recently, we shared a project room. At any given point in time, there might have been one of four to six or seven team members (including a manager), plus one to three people that we were working with. On average there were four people in the room at any given time.

Up until this experience, I had always had positive sentiments about open workspaces and team rooms. In this current setting, I did benefit significantly from getting to converse frequently with all of the other people in the room. I learned things I probably would never have learned otherwise. And, I had a grand old social time.

But I also found that I wasn’t getting much work done when I had things I need to concentrate on. It seemed like I could be guaranteed a distraction at least every five minutes. Either someone was asking a question, or I was overhearing something that I felt compelled to respond to. It got to the point where if I had to find a couple hours to work on something (such as preparing training material), I ended up leaving the open workspace to find somewhere quiet.

The problem wasn’t the open workspace, it was the fact that none of us were really working on the same thing. The other mentors were usually working on a different project than I was. And my manager, well, you know how managers are, there’s always something they want you to pay attention to right away.

Escaping the room on occasion was an adequate solution, but the better solution ended up being pairing. I noted that as soon as I found a partner to help build a solution, or someone that I was mentoring, the distractions disappeared. I surmise two reasons: first, as a pair we were focusing on a problem. That meant I was no longer listening to any external conversations. Second, people are more reluctant to interrupt two people that they see obviously engaged in a conversation or task.

As I’ve paired more and have worked with teams employing pairing, I’ve grown a long list of benefits that I’ve seen accrue from the practice. My experience here adds a new bullet item: pairing minimizes distractions.

Certification and the Agile Alliance

I attended a panel presentation, “To Certify or Not to Certify,” at Agile 2007 in Washington, D.C. The presenters included several esteemed members of the agile community, including (but not limited to!) Ron Jeffries, Michael Feathers, Mike Cohn, and Angela Martin. I thought the panelists offered some interesting but far from comprehensive thoughts on certification. The panel deliberately avoided “hot” or contentious questions, in favor of a subdued give-and-take on the topic.

What I heard was essentially this message: “certification is inevitable, so we should try to beat those other guys (whoever they are) to the punch.” Presumably, the interest would be to build good certification, so good that those greedy other guys don’t come up with poor certification. (The Agile Alliance issued a position paper on what they thought the value proposition was for certification; it can be found here.)

Shortly after the conference, I was invited to and joined an online action/discussion forum consisting of some of the aforementioned panel members. I asked for some goals for certification, thinking that there are many paths to many different kinds of certification. The first step toward any solution is knowing what the problems are, and how much of each problem you’re trying to solve.

If there is a discussion forum metaphor for blank stares, that’s what I got with my posts. A different action group formed, one where a decision was already made to build some sort of trust network (based on a notion similar to Google page ranks). I wasn’t so warmly invited to this second group. Perhaps my pointed posts helped kill the first certification forum.

Never one to be subdued by rejection, my response is to move forward on my own and establish a basis for a certification program for test-driven development (TDD). My intent is to produce a skill-based TDD curriculum, one about as rigorous as a typical university course. Is there a test? Is there a certificate? That’s probably not something I can build as a sole proprietor, but I’m open and ready to work on creating a standards body for TDD certification.

What are my motivations? They of course include profit, but they also include my strong interest in improving the level of professionalism in software development. While some decry profit motivations based on their belief system, certification schemes are primarily about profit, and I believe competition usually drives improvement. Let’s get competing!


Actually my nightmares will become a reality when certification in the Agile world comes. It’s close when you end up working for a moron with agile certificate, who knows shit about Agile software development – sorry, I couldn’t resist. It seams, it’s a time to create 4000 pages long agile process guide.

Right now, agile is “whatever Joe schmuck wants it to be,” for better or worse. To paraphrase the agile alliance folks, agile certification is coming, and their version of it is really going to suck.

I won’t bother if I think my version of certification is going to suck. If I certify someone, it will mean that I’m pretty confident that I would hire them, at least with respect to their TDD skills. If I can’t find a way to make that

I’m relatively new to the Agile world, but already I’m sick and tired of hearing to people who’ve read a book (any book) on Agile methods be a self-described expert.

I’m all for seeing a certification for Agile development. I’m curious to see if it would be biased towards any of the practices, or to general practices.

I think agile is interesting in that it doesn’t say all that much. That’s why it’s possible for the Scrum machine to offer a two-day class on Scrum. After talking about iterations, meetings, pigs, and chickens, what’s left? The challenge in agile is not in its mechanics but rather in learning how to solve problems (which are usually people problems) and improve upon such solutions regularly.

So I’ve decided for myself that at least TDD certification is valuable, because it is a demonstrable skill, whereas something like “general problem solving in an iterative context” is not so quantifiable.

To the anonymous who is new to the Agile world. Certification won’t make these people to shut up, actually I think they be first who get certified, so they could prove you they are actually an expert. Any discussion will end up with a statement “Don’t tell me I’m certified, so I do know how it should be done”.
Let me tell you an anecdote.
“The juggler was looking for a job and went for an interview to one of th circus. The CEO took a look at his resume and said:
– I see you have a juggler certificate. Can you juggle with 3 balls ?
– Yes, I can – replayed juggler.
– Can you juggle with 5 and more ? – asked CEO.
– Yes, I can – he replayed with a little smile.
– Great, that way I hire you – said CEO.
– But wouldn’t you like to see me juggling ? – asked the juggler.

Yes, I’m amazed at how we hire today. I’ve even had a number of people suggest that making people pair during interviews “just isn’t fair.” What, actually expect that they can demonstrate they know how to do what they’re about to be paid lots of money to do?

Still, we perceive some value in diplomas and university courses. I think there is value in the information that comes from close-knit interaction over several months, enough to say that “this person has potential.” Is a 15-week mentor/protege relationship be a sufficient basis for recommendation?


Agile Doesn’t Work If…

… you think it’s stupid. Or if you don’t want to do it. It should be obvious, but to truly succeed with something in life, you have to truly believe it’s worth doing.

As such, I’m going to suggest something to all the people out there who don’t think agile is a good idea: don’t do it. Please, find something better. Maybe you’ll hit across something we can all learn from. I’ll be happy to move on from agile once I see something better. Just remember that saying “I’ll do these kinds of things when I feel like it” isn’t agile.


Today, I received the following post on a few of my Yahoo group lists (refactoring, scrumdevelopment, etc.):

Greetings, everyone.

I apologize for the spam, but I wanted to share with you a new initiative on the web to help large organizations make the transition to agile. I have been working with several customers over the past few years, and their biggest complaint to me has been about scaling up their agile transition when it’s so expensive to find genuine agile experts. So many people have jumped on the bandwagon last year!

So we have joined forces with some large organizations, many of which you’d recognize, to take that first important step towards solving this problem. In the spirit of being agile, our first presence is small, but we’re growing it incrementaly, so I hope you will show us your support.

Please visit to become certified and spread the word. It’s easy!

John Smith

I highly recommend clicking through the certification links. You’ll also find a good letter from Tom DeMarco (which looks to be written in 1998) that talks about the value of certification.

The Great Loyalty Oath

Anyone who knows me knows that I have a good sense of humor. I’m usually the one in the back of the meeting room, making wisecracks and trying to keep a spirit of levity.

The Scrum(TM) development list this weekend has been rife with accusations about other people’s senses of humor. This is in response to Ken Schwaber, one of the Scrum founders, having promoted a secret handshake (which apparently is supposed to be accompanied by wolf howls).

Almost everyone has a sense of humor. What’s also true is that almost everyone has something for which they don’t have a sense of humor. In other words, they find offense in attempts at humor around these elements.

The best we can do is accommodate these peoples’ sensitivities. It doesn’t mean that we should stop doing the things that these people find offensive. If that were the case, half of human conversation would need to cease. Some people are just touchy about everything.

No, what “accommodate” means is that we don’t go out of our way to force our “senses of humor” on others. Telling dirty jokes in front of a religious person, when we already know better, is doing likewise. Making everyone howl like a wolf or touch one another in some potentially inappropriate manner is forcing our sense of humor. Simply put, it’s about showing appropriate respect. (Some people don’t find humor in anything–we best show these people respect by avoiding them, I suppose.)

I’m not offended by the whole thing, but I do find the whole “great loyalty oath” aspect of Scrum embarrassing. Not necessarily for the participants, but the for the whole of the “agile movement” (no, it’s not that kind of “movement”–that’s probably inappropriate humor, isn’t it?).

One thing that agile gets criticized for is the fanaticism of its proponents. I know, because I’ve been accused of being a fanatic. It’s an odd accusation, because anyone who has ever listened to me has heard me temper my statements, and suggest that these agile things we find valuable aren’t for everyone.

In any case, I have a hard enough time defending agile concepts to people who view them as childish and unworkable. This sort of unnecessary posturing just makes it all that much more difficult.

I do need to pause here and give credit to Mike Cohn. In his posting, referenced above, he explains it as “If we do something silly and a few people woof along with me, everyone remembers it”. I think that’s the right attitude. Unfortunately other peoples’ fascist tendencies (such as the other poster referenced above) lead them to look upon with disdain people who don’t feel like participating. We are branded as humorless and ostracized from the group.

I guess I don’t have the “right” sense of humor. My response, guaranteed to offend at least a few people, is at

We can do better. Instead of being indignant because someone dared resist the tide, we should look to find out what is turning them away. Instead of adding things to agile methods that are divisive and exclusive, what if we just concentrated on how to get teams to work together well? It’s really how great software gets produced.

“The important thing is to keep them pledging,” he explained to his cohorts. “It doesn’t matter whether they mean it or not. That’s why they make little kids pledge allegiance even before they know what ‘pledge’ and ‘allegiance’ mean.” – Catch-22

Practicing Programming

I was able to entice Ron Jeffries to speak at the Colorado Springs Agile Users Group (cosAgile) a few months ago. As usual, the talk was very entertaining. Ron, deck of 3×5 cards in hand, went through a number of topics, talking about “why software development is easy.” Or not.

One of the central messages was about practicing the craft of programming. Musicians do scales, professional sports teams have scrimmages, and firemen run drills. But most programmers I know don’t seem to practice much.

Or maybe they do, but I just don’t hear about it. There are gobs of open source projects out there, and geeks who just sit at home working on pet projects. Do these count as “practice?”

Ron is one of those guys who practices the bowling game, over and over, to see how his solution improves each time. I’ve done the same thing, working on building a database interface layer. It comes out a little differently and a little better each time. The last place I was at, we used this database interface layer as the basis for a weekly lesson in TDD.

CosAgile meets weekly to work on a password manager application, PeakPassMan. While the result will be a functional, usable product, that’s not the primary goal. The goal is for programmers to get together, share ideas, and work on a common source base while trying to learn more about things like test-driven development. CosAgile is certainly not the first group to promote the idea of getting together weekly to practice building code, but it sets a good, shining public example.

Practice makes perfect! Well, there is no “perfect” in programming, but honing your skills by practicing a problem is a great idea.

XP Pros & Cons: Reflecting on XP Experiences

A colleague in a graduate degree program recently posed a question to me on email:

> We’ve had quite a bit of eXtreme Programming discussion this week in my
> Software Processes class. Unfortunately, none of us have actually been
> involved in a real, live XP project. I’ve tried to defend it, but my XP
> background is pretty weak.
> I know you’ve been involved in a lot of XP work. Can you give me some info on
> what type of projects you’ve worked on, how successful they were, and what
> you think the pros and cons of XP are? If you don’t mind I’d like to quote
> you a bit in our online class discussion as someone who has really been in
> the XP trenches.

My response, with some name changes to protect the “innocent” and some additional cleanup, follows.

In general, the XP projects I’ve worked on were slightly more successful than the non-XP projects. I’ve probably coached 20 teams; this includes a mixture of small teams (2-4 people), lots of medium-sized teams (6-12), and a few large ones (18+). Some of the shop types included government, retail, airline industry, grocery, financial, telecommunications; everything was all over the map.

Prior to XP, I did lots of waterfall-based development at places like MCI, Marriott, and ChannelPoint [a failed Colorado Springs dot-com]; I also worked in a number of smaller shops where some flavor of waterfall was in place. I also did some spiral development at MCI, and I’ve consulted in a couple of shops where they had some implementation of RUP.

The most extensive XP effort I had experience on was with [a grocery chain I’ll refer to as IFC] in Texas, where I was initially in the trenches doing paired development. About two months after starting the contract I ended up running a short-term subproject to develop an offline solution for their pharmaceutical processing system.

The IFC effort was a good example of both success and failure in XP. Using test-driven development (TDD), the development team had managed to build a significant amount of reasonable quality production code within a short period of time. They reported a very low number of defects. The code had an extensive body of tests. The IFC team had an open environment and mandated pairing. However, there were a number of XP practices that the team did not follow. Specifically, they did not adhere to fixed-length iterations, and their planning was somewhat ad hoc; also, they did not refactor as much as necessary.

The upshoot was that at some point after I joined, they were unable to sustain reasonable delivery periods, partly due to some network dependency issues that exacerbated poor design in the code. Making changes to the code base was difficult, since the tests were overly dependent upon the implementation (they abused mocks). However, they were able to make a significant number of changes and improvements rapidly, since they had tests in the first place. Management insisted we develop an offline solution.

The offline solution I directed as coach/tead lead was to me a testament of the value of XP. In a matter of 8 weeks, we built a complete and successfully deployed solution that allowed offline pharmaceutical fills. As a coach with full ability to direct the XP team as I wanted, I took a number of “lesser” developers and showed them how to adhere to the simple rules that they had neglected over time: fixed iterations with simple but comprehensive plans, and hardcore as-you-go refactoring. The “senior” guys (including some expensive Vitria BusinessWare consultants) were left alone to solve the stability problems; they floundered and ultimately failed. My mostly junior team learned how to trust each other as a team (despite some early ugliness) and enjoyed working together. They also saw success and progress on a two-week basis.

I’ve seen many similar examples. At [a failed dot-com in Orange County], the development team continued to enjoy working on and delivering product while the walls and rest of the company crumbled around them due to a bad business model. At [a large company in Dallas], I worked with a number of different teams on a short-term basis; some of the teams had abysmal performance while others delivered spectacularly to expectation. The differences often could be attributed to adherence to practices.

The teams that took the values to heart and believed in what they were trying to do were successful. The teams who resisted and thought they were too smart for anyone else’s ideas on how to build things failed. Ultimately you could say this about most processes, not just XP. The best thing you can do is to get a team to gel: to learn how to communicate well and to trust each other. This means trusting each other enough to say when things aren’t going the right way. Or to speak up when something seems like it’s a waste of time (e.g. attending meetings where little is accomplished).

I believe XP promotes these values. If you want to talk specifics, the main value that I get out of XP practices boils down to three things:

  • testing/refactoring. These go hand in hand. Test-driven development (TDD) is the most valuable programming practice I’ve ever come across. The value of test-after pales in light of test-first. Refactoring is extremely important in extending the potential lifetime of software product; it is only really possible if you are writing comprehensive tests. And it’s really only effective if you do it all the time, i.e. if you build it into your TDD cycle (test, code, refactor, repeat).
  • constant planning. The problem with most projects is they attempt to plan once and assume they’re done with it. They spend a lot of time up front to come up with a date that everyone knows is bogus. XP takes the view that planning is good, but you really want to be planning and replanning all the time. Reality always intervenes with plans.
  • pair programming. Take a look at the article on my site called “Pair Programming Observations.” It contains a lot more information that I won’t repeat here. When done well, pairing is a wonderfully enjoyable and productive practice.

Here are what I consider the cons of XP:

  • As experience at IFC and elsewhere suggests, understanding and following through on quality design is essential. It is possible to depend upon “emergent design,” but if and only if you remain dogmatic about refactoring. A team needs at least a couple “refactoring zealots.” You have to eliminate duplication at all costs, and you have to ensure that the code remains expressive and clean. You have to write tests for everything. Tests are specs, and if you’re not going to write specs on paper, you have to write them in code. Write tests for everything, including exceptional conditions. Don’t write code unless there’s a test for it. Obviously you can’t test every possible condition, but you can at least test what you do know you have to code.

    The con here is that this is very hard to do. It requires a good coach to initiate and ingrain the rules into peoples’ heads. And it requires the people within the team to care enough to not let things get sour. Unfortunately, it’s almost impossible to get a team to be that meticulous. In retrospect, I’ve learned to invest just a small bit more of time up front in doing design. However, I temper that by ensuring everyone is fully aware that the initial design is a road map; reality will always take you on detours that end up redrawing your TripTik.

  • The temptation to let iteration deadlines slip is high. “Let’s just get that one more feature finished and then we’ll ship.” No. You have to learn to deal with deadlines in the small before you get anywhere near good at dealing with deadlines in the large. Management, unfortunately, has a hard time understanding this. So they slip. And then you lose all sorts of things, from consistency, trust, understanding of how to deliver product, and accuracy in estimates.

The pros:

  • Done well, XP gets a team to gel more than anything.
  • It builds true competency in all team members.
  • It makes for an enjoyable and honest work day.
  • It gets people out of their cubes and talking to one another.
  • TDD teaches developers about how to write quality code and how to improve their notions of design; it helps them to improve estimates. It improves the resumes of developers.
  • It gives management many tools, including predictability, flexibility of resources, consistency, and visibility into what’s really going on.
  • It gives customers the ability to see whether or not a company can deliver on its promises.
  • A personal favorite: you don’t spend a lot of time in stupid, wasteful meetings, and you don’t produce a lot of useless documents that no one reads and that aren’t trustworthy anyway.

With respect to TDD, the Jerry Jackson story about TDD is always good. I don’t remember if you’d ever met him while at ChannelPoint. He was one of the first authors of Java books; his book Java By Example was the fourth ever published on the Java language. I hadn’t seen him in a while; two years ago I met him in the fall while at Tim’s chess tournament. He said that he’d read a bit about TDD but hadn’t tried it yet, and that he was going to look into it. I saw him again about three months later, at another tournament. Before I could say anything to him, he walked up with his face lit up and said something like, “That TDD stuff is amazing!” This is the testament I get from anyone who’s given TDD an honest try. They all say similar things, about how cool it is and about how much it’s taught them about their coding and their design. Jerry now works at Cassatt; apparently they are all doing TDD (and a lot of their technique and inspiration is based off a paper I wrote for OOPSLA 2001).

Oh yeah… if you’re going to do XP, or RUP, or Scrum, or Crystal: Hire a process coach! It’s easy to screw any of them up. You would never field a football team without a coach, even if all of the guys had played before. It seems ludicrous that we slog away at building software, spending millions of bucks, without someone to make sure the process and techniques make sense.

I hope this helps.


What Are We Building?

Requirements, requirements. There are few things worse to me as a developer than having to guess what I’m supposed to build. I’m currently in a shop where we get high level requirements from an end customer, but the details are left to us.

–“Should this have a default, Bill?”
–“I dunno, what do you think, Jeff?”
–“I dunno, what do you wanna do, Marty?”

Ugh. It’s a huge comfort to have someone take the time to find out what we should really be building.