But that’s not why the Certified Scrum Developer (CSD) is around.

Last post I mentioned that the CSD was created because Ken Schwaber and the Scrum Alliance were being asked to help with teams that had adopted Scrum, but weren’t seeing the results they wanted because they didn’t have the skills necessary to ship software – working software – that frequently. In other words, they didn’t have a problem *finding* people, they had a problem *training* people.

The connection hit home for me when I saw Jeff Sutherland’s tweet over the weekend about an opening for a ScrumMaster:

ScrumMaster job in MA. Great opportunity. Managers finished CSM class today.

They were looking for a ScrumMaster, but they weren’t planing on rehiring their developers. I can see the conversation going like this:

Bob 1: Boy, that CSM class sure was insightful. How are we going to convert our team?
Bob 2: Well, we’ll need a ScrumMaster. Ain’t nobody I’d trust to do that here! Haha
Bob 1: [Laughs heartily]
Bob 2: And I suppose we’ll put our team through CSM training.
Bob 1: Sounds great to me!

It sounds silly, but in reality it isn’t. I know, because I’ve seen it in several training classes. In fact, when I took my CSM with Jeff Sutherland and Mitch Lacey, 90% of the class was from the same company. I asked the people at my table why they were there and the answer was classic: “Because our manager told us to come”.

Now, let’s say we have the CSD in place. Bob 1 and Bob 2 will now just send the development team to the CSD training, the Business Analysts and Project Managers to CSM training, and the managers to CSPO training. And then we’ll be agile!

Lessons from GM

In 1983, Toyota took over one of the worst plants General Motors had – the Fremont, California plant. They turned it completely around in 2 years. But when GM tried to take the practices that Toyota was doing at the plant and apply them to other plants, it failed miserably. Why?

Because practices without principles are worthless.

Toyota’s practices around Lean Manufacturing were important, but more important and much more vital were concepts around Empowering Workers, Stop the Line, and other fundamental concepts which counter traditional command and control management styles.

But it seems so easy, doesn’t it? Sprinkle a little product backlog here, a stand-up there, some TDD over there, and you have a recipe for product success? Or, rephrasing in Slashdot lingo:

1. CSM
2. CSD
3. CSPO
4. ???
5. Profit!!!!

So changing our hiring practices is great, and worthy. But that’s not why the CSD is around. And it’s what makes it so dangerous – it’s an implicit assumption that if you just take the trifecta of certifications, you can become a Certified Scrum Organization, and won’t that be keen! And swell!

Let me know how that works out for you.

Scrum Development:

XP:

TDD:

I took the 2000 highest used words, filtered out some common ones (“the”) and popped it into the Wordle advanced interface which, surprisingly, handled it just fine. I had all of the messages locally in mbox format (because I use Thunderbird) which is essentially a flat file. So the Ruby script was basically file.each_line {|line| line.split.each {|word| insert into database} } which I then pulled back out sorted by word_count.

Be sure to click on any of the images to see a larger image. Enjoy!

If you’ve been following my blog, you’ll know that I’ve been calling for more technical support for software teams from the Scrum Alliance, and should be jumping around. You’ll also know that when I was the Community Liaison for the Scrum Alliance I supported the Certified Scrum Developer program at the time. But there are some big differences between then and now, and some important misconceptions out there.

CTISTAC – Certified That I Sat Through A Class

First off, the current CSD program looks very similar to what we had drafted earlier last year. A CSM just has to take 3-days of technical training and can then be stamped as a Certified Scrum Developer. Non-CSMs have to take a one-day Scrum training class, the 3 days of technical training, and a 1-day “elective”. To be a trainer, you either need to be a CST, Microsoft MVP in Application Lifecycle Management, or a Microsoft “Inner Circle” partner. If you are any of those, you just submit your content, get it reviewed by the Scrum Alliance, and off you go. If you aren’t one of those, you just need to apply and give credentials, and then submit your materials and off you go.

When I was at the Scrum Alliance, this was seen as a big farce. Jim Cundiff and I had many discussions about it, and there were several reasons why the Scrum Alliance ended up with a program like that. But, since there wasn’t much we could do about the CSD itself, we made two important distinctions to offset the impact:

1. To be a CSD trainer (or SAREP) you had to co-teach with a specially designated trainer. In short, the Scrum Alliance was going to identify a short list of people who had the Scrum knowledge, technical knowledge, XP knowledge and passion for the role. Then anyone wishing to offer the course had to have one of these handpicked people come in and co-teach with them for one or two classes. At that point, the trainer would be signed-off and free to go about teaching. It may sound a bit like a “good ol’ boys club” but I was very comfortable with the initial people because I felt they were being held accountable by the community. Further, it was designed as a short-term designation to seed the community, at which point the existing trainers could co-teach.
2. The entire CSD program was going to be deemphasized. The CSD is a joke. I haven’t found one person who hasn’t said it is a joke. The training, however, is not a joke, and important as a starting point. So the term bandied about was a “Certified Scrum Developer Practitioner” which was going to be a much more in-depth certification, involving hands-on practices, experience levels and other aspects which weren’t just about sitting in a class. So, since we couldn’t stop the CSD, we’d make it like a high-school diploma – fine to have, but outside of that, basically worthless.

In Ron Jeffries’ latest blog post he shows several examples of how the Scrum Alliance is committed to developer quality. And, in fact, I think the Registered Education Provider isn’t a bad step by itself. After all, it makes sense to have a list of the things that are important and make sure that they are covered. The rub is this – if you become an SA REP, and you teach the technical content, you are explicitly supporting the CSD program. There is no way around that. If you are against the CSD, but you become an SA-REP, then saying the CSD is a joke counters your actions.

Ron and Chet are great examples of the conundrum at play here. I think the course they offer will be fine and dandy, and that people will learn a tremendous amount from it. But imagine the power that would have happened, and the message they could have sent, by saying they would only become SA-REPs if there wasn’t a CSD program.  I understand Ron’s point about influence, and I believe him. But for many others, it’s about money.

It’s All About the Benjamins (with respect to Puff Daddy)

Let’s do some quick math. The CSM class currently sells for $1000-$1500 USD a seat for a 2-day class. If you sell 20 seats in the class, your income is ((20*$1500)-(20*$50)-$1000) = $28,000. The $50 is the fee you have to pay the Scrum Alliance for each student, and the $1000 covers facility cost and catering. Even if you bump the costs up to $4000 USD, you are still clearing $20,000 USD for a 2-day class.

Since the CSD is going to be longer, more intensive, and rarer to begin with, let’s imagine you can charge between $1500-$2000 a seat. There is no fee to the Scrum Alliance, so you end up $35,000-$38,000. Teach 5 of those a year (15 days of work) and you have cleared $175,000 USD of income.

And it’s no surprise that the certification sells. As Ron says in his blog post:

And still, it sells better. We do our best to sell and teach without deceit, and as an insider I am certain that the Scrum Alliance and the Scrum Trainers that I know do the same. There’s certainly a conflict of interest that I feel: on the one hand, I’m the same delightful guy with or without the certificate. On the other, I get more students, and thus more income, when I offer the CSM. On the gripping hand, I also get to influence more people.

Now, Uncle Bob in his latest blog post asks the question of what problem developer certification is trying to solve. And I think I know.

Purse strings.

Many very good coaches and trainers offer training classes all over the country. But they can’t get people to go to them. But suddenly tack on a 3-letter acronym and employers everywhere are willing to jump on it. So why is that a bad thing?

No-CSM (with respect to Eric Evans)

Because the Scrum Alliance didn’t need to do it.

Let’s go back to why the Certified Scrum Developer, and its separated-at-birth twin the Professional Scrum Developer were created. Teams were implementing Scrum but not getting good results because they didn’t have the skills necessary to ship software that frequently. Companies were begging (to hear the story) Ken Schwaber and the Scrum Alliance for help. Imagine if the response had been for the Scrum Alliance to just offer the SA-REP program and show people where they could get more information, more experience, more training. Theoretically people would have jumped all over it. But for some awful reason they still had to stick a meaningless certification in front of it.

And so it comes to this. Either we stand for our principles against certification and let this CSD program die on the doorstep, or we explicitly support it with the thought that we can influence it later on. You know, after I’ve paid off my house and car and socked away a nice chunk of change. From my perspective, I know that Uncle Bob called for Craftsmanship over Crap. And I view the notion of certification in the same vein as a do the idea of writing tests after the code, or pretending we can adopt agile principles without changing our organizations –as crap.

To me, it’s about integrity. I signed the Agile Manifesto and the Software Craftsmanship Manifesto because I truly believe we need serious change in how we build software. And I’m beginning to think that people are OK with that – when not being waved large sums of money in their face (at least judged by the number of “Certification sucks, but I’m going to apply to be an REP anyway” statements I’ve heard). And, call me a softie, but that truly and utterly breaks my heart. Because this community is who I’ve always turned to when I needed to know that taking a stand was the right thing to do. And, without that, I honestly feel that perhaps I should just stop standing up for this stuff and effectively just look for what will make the most money. I have a strong SharePoint background, and I know how to do .NET and Software Architecture, and there are always offers being waved in front of me to go do that.

But I know if I do that, if I let this go, then I may as well not be involved at all. Because I couldn’t take it. And that’s not what I want. But if this is the integrity we have, if this is how we respond to something we all agree is bad – then what’s the point?

I hope I’m wrong. I hope that we see a lot of things changing. But I was on the inside. I pushed and yelled and screamed for things to be changed. And look what came out. I don’t see how those who are making hand-over-fist amounts of money would be able to have any more impact.

So, we could wait and see. Or we, as a community, could recognize this as a serious problem and offer an alternative – not a certification, or an organization – but a path to technical excellence. I just haven’t found anyone up to actually doing something like that. And so it goes, the CSD comes in to play, developers jump all over it, and now I get to work with teams who say they are doing Scrum AND XP, and still not shipping software.

Hmm, wonder if that SharePoint contract is still open…

(Addendum: I want to make it explicitly clear that the integrity issues of having money waved in front of you I in no way think affect Ron and Chet. I have the utmost respect for their integrity, and while I wish they didn’t support the CSD, I believe in their statement that they are trying to influence the community by being on the inside. Besides, I’ve seen the pictures of Ron’s car.)

Yes, I want this to die. But Jesse Fewell has posted some thoughts around the Scrum Alliance that in fact what they are doing is right, and correct, and they should fix the leaks and stay the course.

I’ll try to be brief with his arguments:

1) “The 75% failure rate of Scrum is one man’s hunch” – Um, no it’s not:

• “Why there is such widespread failure is no mystery to us. We’ve been studying why Scrum works and doesn’t work for years”
• “I’ve mentioned Scrum because when we see this problem, Scrum seems to be particularly common as the nominative process the team is following. “
• “Now many people who call me already have Agile in place (they say), but they’re struggling. They’re having trouble meeting their iteration commitments, they’re experiencing a lot of technical debt, and testing takes too long.”
• “Does Scrum really fail to achieve its promise 3 out of 4 times? I am afraid so. I have heard that at the last Scrum gathering this number was bandied about and although it was somewhat arbitrarily selected, seems to have won general acceptance.”
• “As XP / Agile / Scrum have become more popular, many teams and individuals have wanted to do them, or “be” them. This has led to a school of Agile methods that wants to be called “context dependent”. The idea is that whatever brand of Agile is under discussion is “too rigid” and “doesn’t fit our context”. So we have to modify Agile because God knows we can’t modify our context.”

If the 75% number was way off-mark, there would be many CSTs jumping to counter it. Heck, even the Scrum Alliance doesn’t counter it. It’s an accepted fact of life. And that’s the troubling thing – it isn’t the number, but the reaction to the number – one of, “Oh, yeah, well, we know”. (And yes, I know some of the quotes above mention agile. I’ll deal with that in a minute)

2) “But what if we instead asked “How many of those who tried Scrum or Agile techniques saw at least some positive improvement?” or “How many teams were in on the whole at least a little bit better off for exploring Scrum?” I bet the answer would be much different.”

Read this. Go on. If you don’t want to read it, look at this quote:

What does a high touch Scrum team do? A high touch Scrum team does
many things to incorporate touch into its daily practice. High touch
Scrum teams:

1. Hold hands during the Daily Scrum.
2. Give each other standing backrubs at the start of the Sprint
   planning meeting.
3. Hug each other at the end of the retrospective

How many teams would be, on the whole, a little better off for exploring that? I bet most would be. And what does that tell us?

Nothing.

Because Scrum isn’t about making people “a little better off”:

• “Over fifty organizations have successfully used Scrum in thousands of projects to manage and control work, always with significant productivity improvements.” (from Control Chaos)
• “With Scrum, these impediments are prioritized and systematically removed, further increasing productivity and quality. Well-run Scrums achieve the Toyota effect: four times industry average productivity and twelve times better quality.” (from Scrum Alliance)

(emphasis mine)

But wait. That last quote is so great, because of what is on that page.

Successful Scrum implementations have many benefits for teams and management. Scrum does, however, require a change from the status quo.

then

These results can only happen, though, when leadership commits to the required changes: teams that adopt Scrum must move away from command-control and wishful-thinking-predictive management.

then

“On the surface, Scrum appears to be simple, but its emphasis on continuing inspect-adapt improvement cycles and self-organizing systems has subtle implications.”

And what are those implications?

Oh. Yeah. That’s the end of the page. Guess you have to figure that out on your own.

3) “The Scrum Alliance is NOT a company that has to choose between a narrow vertical industry or a very specific generic offering. Rather, it is a formalized body that supports an organic movement to “transform the world of work”. It is a big tent that provides tools and products to equip any one person’s niche within that movement. Whether offering an article for how to interact with a large company PMO, or supporting a local user group consisting mostly of GUI designers, the SA responds to what its members ask for.”

I covered that in my last post.

4) “However, I do not think the SA’s execution issues point to having the wrong mission.” – Unfortunately he doesn’t say what it does point to. But I can tell you.

Let’s say I create a new digital camera. People who use it are blown away at how much better it is than every other camera out there. But some people, in fact, many people, aren’t seeing the same results. And when they go to my company’s web site, I tell them:

“The CFmera is a revolution in camera design. However, to use it, note that you have to rethink what it means to be a photographer. The way you shoot pictures has to change, and everything you know about what constitutes being a good photographer is applied differently. If you don’t do these things, then you won’t get the results from the CFmera. Sorry about that.”

Is that their problem, or mine? I don’t offer them any guidance, any pointers, any suggestions. If my goal is to transform the way people capture memories, well, that doesn’t really seem to help, does it?

Scrum does good in the world. Even Alan Shalloway admits that. I’m not saying that Scrum is at fault.

What I am saying is that the Scrum Alliance is at fault. They say themselves that to adopt Scrum you have to alter the fundamental tenants of management and organizational behavior. Right there, on their web site. But I’m not seeing trainers updated with the latest advancements in Organizational Behavior, or Change Adoption. CSMs aren’t getting paths to how to adopt it in their organization and how to deal with the fallout (some CSTs do this, I know). And this is all in the context of software development, where we have a very strong base, and a fairly good understanding of the issues involved.

But Jesse’s key point was that the Scrum Alliance can do both a Depth and Breadth approach. I disagree. It needs to choose. Either it’s about Scrum, the framework, with no underpinnings in software, or it’s about software and helping build that out. I actually prefer the former, and having industry-specific groups split out, each that can control the requirements for their subsegment.

Scrum is a good framework. And it’s a stable one – it doesn’t change. That means that the Scrum Alliance mission isn’t to make Scrum better, but help organizations adopt it. And since they say that to adopt Scrum you have to change things – fundamental things – about your organization, doesn’t it make sense that most of their work would be in enabling people to understand how to make that change?

It does to me. Because if we want to “Transform the World of Work” we ain’t gonna do it by sticking people who have no authority to make change or understand of how to introduce change through a 2-day class and collecting some fees. We do it by a concerted effort to change how businesses think about delivering software, interacting with customers, and running their entire company. That’s change, and that’s power, and that’s something that could theoretically be within the grasp of a money-making machine like the Scrum Alliance.

And an organization doing work like that can gladly have my fifty bucks.

Here’s my question though, if the SA isn’t going to be the one to apply agile thinking to lawyers, financial analysts, music producers, and managers, then who will? Are tech workers the only knowledge workers worthy of agile thinking?

Scrum Alliance Background

(If you don’t want all of the background, skip to Cory Gets to the Point)

It’s a good question. Let’s start with why the Scrum Alliance exists. On their web site it says:

The Scrum Alliance is a nonprofit organization committed to delivering articles, resources, courses, and events that will help Scrum users be successful.

But if you scroll down and look at the Form 990 filed for tax year 2008, it says:

Scrum Alliance’s mission is to promote increased awareness and understanding of Scrum, provide resources to individuals and organizations using Scrum, and support the iterative improvement of the software development professions

(Emphasis mine). Further, in section 4a it says:

Scrum Alliance is organized and operated exclusively for purposes of furthering the advancement of the “Scrum” software development process

(Again, emphasis mine). And while the board members aren’t compensated, the managing director made, in 2008, $240,000 USD. In fact, all told, the Scrum Alliance paid out three quarters of a million dollars in “independent contracting” fees.

Not bad for managing a 3-person staff of independent contractors. Full disclosure – I worked as an independent contractor for 6 months for the Scrum Alliance. I imagine my compensation should be available in the 2009 filing form. But, let’s just say, it was pennies compared to the above numbers.

Ok, so now that we see that the Scrum Alliance states their purpose is furthering software development, let’s look at the break down of staff:

• Managing Director
• Creative Director (new as of this year – Tobias’ position)
• Accountant
• Membership Coordinator / Website Coordinator
• PR
• 5-person board

And the heart of Jesse’s question becomes, what is the most effective use of a team like that?

SoftwareScrum < Scrum::BaseScrum

Well, let’s look at the existing programs:

• Certified Scrum Master
• Certified Scrum Coach
• Certified Scrum Product Owner
• Certified Scrum Trainer
• Scrum Gatherings (4-5 per year held around the globe)
• Community outreach (funding of User Groups, Welfare CSM, etc)

Which seems to be the right lineup for what Scrum is (3 roles – ScrumMaster, Product Owner, and “Other”). So, in fact, if one was going to set out to “Transform the World of Work”, then keeping the offerings and programs industry agnostic seems like a good thing. Except for one thing.

Magic. Magic is the little dots in the Scrum diagram which shows what actually happens in those 2-4 weeks sprints, and those 24-hour increments. In software terms, Scrum is an abstract class, which doesn’t implement Do24Hours() and DoIteration(). You have to do that. Anyone implementing Scrum has to do that. It’s that magic which distinguishes the successful teams from the non-successful ones. It’s where Lean and Kanban and XP and all sorts of other things get put in. Or, in other industries, where the real work happens.

For example, if I’m a Lawyer, that 24-hour period, or that iteration, I’m going to be going to court, preparing cases, visiting my clients, bribing judges, etc, etc. Or if I’m a movie producer, I’m going to be coordinating shoots, editing previously filmed clips, pampering the actors and actresses, etc.

Which means that if we want Scrum to be successful, what happens during that 24-hour period, or that iteration, has to be successful. If it isn’t, then what happens outside of it – the product management, the demos, the daily stand-ups – doesn’t mean diddly.

new Scrum::BaseScrum() //raise NotImplementedException

(Also known as Cory Gets to the Point)

In fact, in a quote as famous as the Bill Gates “Nobody needs more than 640k” quote, Ken Schwaber says:

I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.

Proof is in the pudding. If Scrum isn’t executed successfully, it doesn’t work. Which means that if we want Scrum to succeed, then we need to be helping those teams figure out what happens in the “magic” areas of the Scrum process.

So far, so good. Jesse’s question still stands – why not help everyone find the magic quadrant?

Because we can’t. The one thing any coach will tell you is that every engagement is different. Some political game. Some quirk about the product. Some jursidictional rule. Some working hour filming requirement in Pago Pago. But, if the Scrum Alliance wants to help, there are at least two options:

1. Build a Community of People to Implement Scrum In Specific Industries – Let’s recognize that each industry has specific needs, and therefore will need Scrum taught different ways. In fact, it was already recognized with the creation of the PMP CSM class held earlier in 2009 (I can’t find a link right now). But to expand, you need leaders, and to get leaders, you have to seed the community. The existing CSP/CST program isn’t setup for that at all. So drop it. Stop centralizing the certifications from CSMs all the way up to the CSTs and push that out to the industry-specific subgroups.
2. Get Scrum Working Well in One Industry – Scrum started to help software teams, and its stated purpose is to help software teams. Yet 75% of the teams aren’t getting the benefit. Hello? Is anyone listening? Why don’t we find how to fix that problem before spreading out to lots of other industries?

Here’s how I look at it. You have a board and directorship of software industry leaders. You have thousands of people in the software industry using Scrum. You have people begging for better ways to do software. And you have your founder saying that 75% of teams aren’t getting the benefit. You want to look at all that and say, “Let’s branch out?”

Look over to your right. That’s a laser going through a prism. Alright, that’s what happens when a laser goes through a prism. It gets split into lots of shiny objects. That are so very pretty to look at. And hear about. Now watch this video:

The Scrum Alliance can be a shiny object, pretty to look at, fun to talk about, neat for a demo or two. Or it can be a focused cost and quality-overrun killing machine by helping the software industry find out what is in those magic circles which is causing 3/4s of the users to not get the benefit. Or, to put it in real numbers, find out why of the members who paid collectively a tad over $2.6 million in 2008, three-quarters (or around $2 million dollars worth of fees) aren’t getting the benefit they should be getting.

So, Jesse, that’s why. The Scrum Alliance can’t hold the keys and want to open the doors at the same time. Either fix what is broken, or split off an industry specific group which has control over the certifications for that industry and can fix it for them.

Personally, I’d prefer to see the certifications dropped and the Scrum Alliance focus on fixing the industry-wide pandemic we call software development. But that’s just me.

Edit: William Pietri points out that lasers are monochomatic, and so when shot through prisms, they split into multiple beams as shown here. It’s still shiny objects with less power than the original – just better represented. Thanks William!

The orange dots you see may really look like the Scrum Alliance logo, but really means “magic happens here”. That’s because Scrum is a framework, designed for application in any industry. At the Scrum Gathering in Munich, they even had a lawyer present how she used Scrum as a part of her practice.

So, if Scrum is a framework, design to be applied to any type of business, why all the fuss about engineering practices? I’ll save you a lot of headaches and just say that software development teams happen to be the primary people who use Scrum, and for them, they need more than “magic happens here”.

Certified Scrum Developer

And, that’s OK. The Scrum Alliance back in 2009 even started down the path of creating guidance for developers. They called it the “Certified Scrum Developer” program, and they got together a group of people like Ron Jeffries, Chet Hendrickson, Brian Marick and Jim Shore to hash out what the heck a CSD would even mean. And what they came up with was more along the lines of a long-term commitment – not one you could teach in a 5-day class, but instead something which led down the practitioner path. In fact, internally there was a big push to say that if they were going to be “stuck” with a CSD program (more on that in a moment) then they should define a CSDP (Certified Scrum Developer Practitioner) which could likely pass the muster of what the community was pushing for.

At Agile 2009, Ron and Chet held an open-space session on the CSD program. At the time, I was the community liaison for the Scrum Alliance, and was there as well. What I saw was a community fed up with where we all stand as developers and development teams. And that desire to change meant there was a lot of passion into the CSD program. And honestly, I think it could have been a great thing. Love it or hate it, (and you can see which side I’m on) the CSM has spread through large organizations and smaller companies like wildfire, and the CSD/CSDP program stood a chance of actually being worthwhile and riding the coattails of the CSM to have a serious impact in the fundamentals of how corporate software is built.

The Scrum Alliance and the Community

One of the challenges the Scrum Alliance faced was community support. There was – and is – a lot of distrust around the Scrum Alliance. I was asked to join after the Orlando Scrum User Group debacle to help with the outreach and communication to the community. I truly believed that the Scrum Alliance was trying to be much more open, honest and transparent in their operations. They certainly were challenged in that none of the people working for the Scrum Alliance had a software background, and so hadn’t been much involved in building software communities (not counting board members). But I was willing to push hard for them in the community because I believed in the direction they were going.

Internally, however, there was a lot of strife going on. Staff members were being told to go in two different directions, and to top it all off, here I was, practically the antichrist to the Scrum Alliance (at least based on what the staff told me). And then, just before the Scrum Gathering in Munich in October, was the final showdown. It led to Ken Schwaber leaving the Scrum Alliance, and appeared to also have Jim Cundiff leaving as well. Lowell Lindstrom became the Managing Director, and the people in Munich were greeted by a board they hardly knew, a CSM Test that no one could say for sure what was going on, and unsatisfied feelings by some (OK, OK, I know, Andy’s hard to please anyway. ;))

Transparency

It seemed like good things might still be on the horizon. The Scrum Alliance had the chance to really break free. They still had the support of the community on the CSD program, and a community energized by the open space session in Munich. What happened next surprised many people. They simply stopped communicating. 22 out of 26 CST applicants were rejected (with very little reason why). The questions around the exam were left open. The CSD program went nowhere and was eventually dropped as a priority due to lack of support from the board or management. As the community liaison, I started finding out information by blog posts and emails from the community rather than internal communications.

In the meantime, Ken Schwaber moved on to create Scrum.org, which caused even more confusion. And, to top it all off, the CSD program – the one I said was dead earlier? It was still moving forward under Ken and Microsoft. All of the alphas and betas of the course still happened.

Towards the end of the year the Scrum Alliance got Mike Cohn on as a board member, and hired Tobias Mayer as “Creative Director”. In general this is viewed as a very good thing. However, the transparency still doesn’t seem to be there – for example, Jim Cundiff is back as the Managing Director and Lowell has stepped back down, but there haven’t been any real announcements around that (although they could be just waiting for the Orlando Gathering). And to cause some more confusion, Mike Cohn has been telling classes that a change is afoot to the naming of the certifications.

Professional Scrum Developer

Which leads us to Ken’s announcement that Scrum.org is putting together a Professional Scrum Developer (PDF) program. The program looks strangely similar to the one I saw around the CSD program, so I imagine it is the same. This particular version didn’t get the input that the community put together which doesn’t make it good, bad or ugly. Time will have to tell, but right now it’s the only thing going, and it’s being heavily promoted in the Microsoft / .NET space (with versions planned for Java as well).

Whether it takes off or not, the truth is the Scrum community has a fracture in it. The support for CSD has moved on to other things, the main figurehead of Scrum is doing his own thing, and it isn’t clear what’s going to happen next. I do know Luke Hohmann has been working closely with the Scrum Alliance using his Innovation Games to help them decide next steps.

But all of this has led us to forget about those developers and team members, working in Scrum Teams, building software, who need guidance. As Mike Cottmeyer points out:

I do not believe it is right to offer certification when there is not standard or a published set of competencies. We should not certify more than Scrum is willing to include in its body of knowledge. 

I still strongly believe that helping teams build better software should be the primary focus of the Scrum Alliance – not “Changing the World of Work”. And while I have no idea what they have planned, this is my wishlist:

1. Cut the “C” - We get it. It’s a cash cow. In Munich I learned there were Scrum Trainers making $400k USD a year + just doing CSM trainings. 2 day class * 15 students * $1500 a head – you do the math. But the CSM needs to die. Now. Make the CSM worthless, and put all of the focus on the CSP.
2. Refocus on the development space – Software Teams doing Scrum need help and guidance. Should those teams go to Scrum.org? And, if so, then why shouldn’t they go there for everything?
3. Change the focus of the Scrum Alliance – According to the Scrum Alliance site: “The Scrum Alliance is a nonprofit organization committed to delivering articles, resources, courses, and events that will help Scrum users be successful.” What we really need is leadership in the Scrum Community.
4. State the intent for CSTs – Is the goal to have only high-quality CSTs, or to actually reach out to the community? I know people are concerned that if the market is flooded with CSTs, that the cost per class won’t be as high. I say, “That’s great!”. The cost for an instructor shouldn’t be based on the scarcity of instructors around the topic, but about what the instructor brings. People like Jeff Sutherland, Mitch Lacey, Ron Jeffries, Tobias Mayer and others deserve every penny they get.
5. Be transparent – for Realz, yo. Community-Vet the CST applicants. Be open about changes in management and the board. Clue us in on what is going on with name changes and what you all think about them. The Scrum mailing list is a great start.

I suspect that lots of news will happen out of the Orlando Scrum Gathering, so we should all watch that space closely. In the interim, keep pushing for transparency and integrity in certifications, and remember – the Scrum Alliance members pay the Scrum Alliance’s salary ($50 a year for CSMs, $250 for CSPs, $750 for CSCs, $7500 for CSTs). So stay involved – either through the Improvement Communities, the Mailing Lists, or good ‘ol moaning and whining. If we want change, we need to make that change happen. So let’s do it.

1. Not Reading the Principles of the Agile Manifesto – Everyone likes to quote (and misquote) the Agile Manifesto. But the manifesto is more than just the four value statements – there are also a set of principles behind it. And since you are reading manifestos, read the Software Craftsmanship Manifesto as well.
2. Not knowing what you want to change – This is the number one question I ask teams. What are you trying to change, and why? Imagine you picked up a book on carpentry, and several expensive tools and said, “This is to make my house better”. I’m pretty sure my wife would be not-so-happy if I did all that and then found out we had to dig up the entire septic system because the problem was a clogged drain.
3. Not having a solid product vision – Agile methods are designed to increase your quality and decrease your time-to-market. But if you don’t have the foggiest clue what you want to deliver or why, then all the sprints and iterations in the world is just going to cause rework and waste as you discover what you really do want. As an example, I coached a team recently who needed a way to keep features out of the mainline for 6-8 months (until the next release) because there were times when features were completely dumped at the last minute. That’s not waste, nor is it an agile problem. It’s insanity that needs to be fixed.
4. Not accounting for the learning curve – There are lots of grand claims made about agile, Scrum and Lean software adoptions and I’m here to tell you that they can be true! Those kinds of increases aren’t going to be seen out of the gate, however. Changing into a collaborative process from a heroic, blame-oriented culture takes a lot of adjustment – and requires time to allow trust to be built up.
5. Not having a plan for resistance – Your laggard adopters are going to want solid data, and are going to resist you every step of the way without it. Be prepared to have heart-to-heart conversations, and to find ways to provide ways to include resistors – or ways to move them out.
6. Surprises for management – “Surprise! The release you promised for July of 2010 will now be in November of 2013!” Keep management informed of what is going on, and find ways to help them with the conversations they need to have. After all, we may all find Gantt charts unrealistic and a waste of time, but if you help your manager generate them from burndown charts for her executive meetings, she may help support your team even more.
7. Not recognizing the value system of the organization – As I wrote in Reward Systems and Organizational Change there are deep, embedded assumptions in how people get recognized / rewarded / paid. The unfortunate norm is tying individual performance appraisals to raises. If you want a highly collaborative atmosphere, you can’t rely on rewarding individual employees the same way. Further, the changes you are trying to bring may not even match the organizational values. Trying to bring openness and honesty into a place which values closed-door, buddy system style meetings and exchanges will only lead to frustration.
8. Local Optimization at the expense of the organization – Anyone who has tried to bring change to a team can likely point out several areas that could not be improved due to organizational constraints (read: politics). To work effectively, agile adoptions need to be able to look at the entire value stream, including marketing, system administrators, database administrators, sales teams, etc. It’s not enough to just shove some development teams into training and hope for the best.
9. Using techniques for collocated teams with distributed teams – You may have a wonderful business case for how you distribute your development team all over the globe. But as you adopt agile methods, you’ll start discovering just how much time you have to spend communicating with the teams just to get the basics across. Stand-Ups, Planning Poker, Retrospectives, and Big Visible Walls are all vital techniques that require much more overhead to accomplish – with quite a loss in the richness of the information.
10. Forgetting that formulaic approaches need to be adapted – Sure you can adopt the 3/3/3’s of Scrum. Or the practices of Extreme Programming. But as you begin to gain context and insights, you and your team should be adopting and adapting the practices to fill the gaps. If you just shove forward without reflecting on what you’ve done, and what you want to do, you’ll end back up in a status quo and a bunch of team members who can quit and go out to tell the world how bad agile is.

What mistakes have you come across?

Scrum taught us one thing – we’re still doing waterfall!

The statement itself is actually not a knock at Scrum, or agile topics in general. It’s a realization said time and time again that you can’t just adopt some tools and practices and hope for the best. You have to be willing to change fundamental things about your organization – something that isn’t easy to do.

As an example, let’s say that you decide to adopt Scrum in your organization, and you utilize iterations, story points and burndown charts. You notice over time that your charts look something like this:

The red line is what the team “should” be accomplishing each iteration. The blue line is what they actually “are” accomplishing. The one thing you should notice (other than the two lines not meeting) is the shape of the blue line. It’s not smooth. In fact, it kind of looks stepped. Almost like the team is doing…waterfall!

That’s likely because they are. Each iteration things are not getting done, done, and so it builds up until a big batch is completed at once. Except that a batch is almost never completed at once. There are invariably bugs that crop up, and since code has already been built on that batch, the code has spread out further into the base, and takes more work to fix. Of course, the fixed code isn’t finished until the next batch, when more issues are found, etc, etc.

Worse, this kind of a stepped appearance to burndown charts is typically the graphical manifestation of a deeper systemic problem. And that problem is that change is hard, especially when the organization doesn’t really want to change.

If you are wondering if you are really doing waterfall inside of an agile methodology, you can ask yourself questions like:

• Have we ever talked about a “development sprint” and a “testing sprint” and an “acceptance sprint”?
• Has the phrase, “I had to stop work on Feature Z because the QA team found a bug in Feature Y I finished up earlier this week” ever come out on a stand-up?
• Can anyone articulate the vision, strategy or goal of what we’re doing?
• Are you using a burndown chart, but seeing it burn up?
• Are people surprised daily by the things that come up at the stand-up meeting?
• Is management surprised at the end of an iteration that things aren’t done?
• Does management even care that things are done during an iteration (as long as you darn developers get it done by the release!)?

I’m sure I could turn this into a funny checklist with scoring numbers where you could get a badge saying, “We’re Scrummerfallaristic!”, the fact is that it isn’t funny when you are in the middle of it. The good news is that once you recognize the challenge, there are lots of resources to help you. The book Fearless Change is a great start. Reading books like Lean Software Development, Implementing Lean Software Development and Lean-Agile Software Development are great ways to understand the challenges of batch processing and having a lot of work in progress, and how to go about fixing it. For Scrum specific information, Succeeding With Agile is one of the better books out there, but I highly recommend looking at a holistic view of your teams and your organization.

And when worse comes to worse, you always have the option to change your organization, or change your organization. But hopefully you can stop the stairs of waterfall and instead navigate the journey to the bliss of agility.

If you are interested in learning more, I’d highly recommending checking out Tess Ferrandez’s blog where she has a set of labs for really digging into this stuff. If you are trying to debug an application or service that is crashing on startup, the blog post I mention is on my site, and the KB article for automatically attaching a debugger to a service on startup is KB824344.

Finally, you can download WinDBG from the Microsoft Web Site, and you can download the sample application here. The slides are available on SlideShare or you can download the PowerPoint presentation. And if you are interested in learning more, we offer a training class in WinDBG and Production .NET Debugging which includes much more detail in the fundamentals and a series of hands-on labs to really understand even more. Simply contact us for more information!