Disclosure

• I am a Professional Scrum Developer Trainer. That is: I have been certified by Microsoft and Scrum.org to teach others about Scrum and modern engineering practices on the Microsoft platform. More information about all of that is available here and here.
• I teach for a living. Mostly Visual Studio ALM along with topics I believe are focused on making better software craftspeople.
• I have watched teams get it wrong (and sometimes right) for about 20 years now. That admission makes me feel very old.

A Bit More Background

Choosing to enter the Microsoft and Scrum.org program and be part of the certification process for developers was not an easy one for me. Indeed, as several people I irritated with my waffling for over 6 months will attest, it was a decision I spent a long time considering. In the end, I obviously elected to become an instructor for certification courseware and this in this post I will tell you why.

On Scrum

I first practiced Scrum in or around 2003/4, if memory serves. I didn’t see it done well for several years after that.

On paper, everything sounded just spiffy when I studied Scrum and considered bringing it to my team and organization. Who wouldn’t want the benefits it promises of frequent feedback, clear accountability, and no-nonsense shipping of product? To get started we hired Jeff Sutherland to come in and teach the original Certified Scrum Master course offered through the Scrum Alliance. I was baffled that at the end of the 2 day discussion to receive this thing called a “certification”. My colleagues and I actually joked about it at the time as being proof that we didn’t fall asleep in class. As Ken Schwaber pointed out to me in an interview recently, we probably could have nodded off and been fine, actually.

My team struggled a great deal trying to use Scrum well. I won’t bother including the long list of mistakes we made, but we eventually got traction and settled into a cohesive rhythm. After we figured things out, Scrum became an amazing vehicle for delivering product, which was the original intent.

To my knowledge, Scrum is still used today in that organization. At the time of my departure was in fairly healthy shape.

Looking back on Scrum’s contribution to my professional life and its contribution to our industry as a whole, I am humbled. Scrum as an idea has done more to drive agile software development than perhaps any idea other than the original manifesto itself. TDD ranks right up there, but fewer CEOs have heard of TDD. There are a lot of reasons Scrum has won the marketing war, but the simple fact is that our profession is a better place for the presence of the Scrum framework and the people who provided stewardship to it, Ken Schwaber and Jeff Sutherland.

I know good and well that other techniques are very effective. Kanban is a wonderful way for many teams to operate. Feature Driven Development is a powerful model for the teams who need to formality of it. And of course, the gaping hole left by the absence Extreme Programming reminds us that zealotry has its costs. Scrum, as it advertises, is not a silver bullet. It won’t fix anything, in fact. Only people of good intent who come together and try to do something well can make that happen. Scrum can merely provide the rules of engagement.

Scrum is popular for several reasons. When it comes to the mechanics of the framework:

1. It is easy to understand.
2. It is easy implement and follow the basics.
3. It can show dramatic return in a short period of time.
4. The first Scrum in an organization is a highly visible Kaizen Blitz.

With all of those benefits, Scrum is plagued by the same problems as every other process or methodology framework in the world.

1. Human beings are the ones who try an implement it.
2. Human beings are the ones who try an implement it.

Scrum is great when wielded for good. It is the lowest barrier-to-entry agile technique I know (excluding engineering practices, like TDD and CI). Teams who currently live in plan-driven organizations derive great benefit from Scrum and so do the organizations themselves. Scrum can be very, very effective.

I chose to work with Scrum.org specifically because I know from experience there are more shops out there that need to change than those who don’t. I believe most of those shops cannot handle something like Kanban. [See this for more] My professional life as a trainer is focused on helping developers love our craft again. Those of us who got a thrill from lighting up a pixel many years ago have just been beaten to hell and back since deciding to do this for money. Although Scrum is only one arrow in the quiver, Scrum as a great vehicle for improving people’s professional lives.

On Certification

Ken has readily admitted that using C-word in the beginning of the Scrum Alliance has resulted in a complete and total mess. Primarily because certification involves a demonstration of something, typically knowledge. Unfortunately that requirement was never required to obtain a Certified Scrum Master “credential”. We can all recognize this is not a credential in it’s current form as offered by the Scrum Alliance, but merely a roster of class attendees. ‘Nuff said.

I also see there is value in demonstrating knowledge through a genuine certification process. For example, we all take driver’s tests. I look for ASE (Automobile Service Excellence) certified mechanics to work on my car. I trust a BMW certified technician to work on my motorcycle. What is a university diploma if not a certification award?

In almost any field, it is impossible to certify competence. Certification can demonstrate knowledge, but not ability, talent, experience, or wisdom. It is exactly for this reason that I never got hung up on a college degree as a hiring manager but went to great lengths to try and know a person. A college degree did show me what that person experienced, though, because I basically know what it means to get a university degree. There is value in that credential because it had to be earned.

Given the current state of the industry, there are 3 logical progression paths for Scrum certification.

1. Change nothing and remain a mockery.
2. Drop the certification word and idea altogether.
3. Add meat to C-word by actually testing for it.

Scrum.org is taking the 3rd option and I am going for that ride. My reasons include:

1. Working for change within a system is typically far more effective than pushing from the outside.
2. Scrum as an idea continues to help teams and individuals improve.
3. I respect the people involved in the stewardship of Scrum.org.
4. “Certification” means a demonstration of knowledge by a taking a test in this crowd. Not perfect, but a good start.
5. I believe the teams and other trainers I work with have the best interest of the craft at heart. Really.

On The Future of the Craft

In the last 60 years of programming computers, we have have learned that developing in small batches and delivering incrementally works. Scrum gives us a model for doing exactly that, and it will still be helping teams until the next great thing is found. Now that I know Ken a bit better I can say that Scrum itself will likely evolve to incorporate whatever works better.

Ridiculing certification or Scrum may well be the in-crowd thing de jour, but I see that Scrum addresses a core need in our industry, and genuine certification has its own benefits. Lean offers some wonderful directions for us, and shows all the signs of providing a path forward. But, let’s not forget that Scrum is an inherently Lean idea.

But I digress.

Another time, perhaps.

If you recall from my original post on Elegant code, I stated that elegant code is:

Something that is simple yet effective, delivered with grace.

By writing self-documenting code we are hopefully able to achieve some of the aspects of simplicity and grace, but it tells us nothing about the effectiveness of the code.

Bringing the dead to life

Throwing out comments is a debatable topic.  It raises quite a bit of controversy, as you can see from some of the comments on my post about the subject.  The reason, perhaps, that so many people are so staunchly opposed to the idea, is because they are worried, and rightly so, that throwing out comments will reduce the documentation of what the code is doing.

Think about that for a second.  Is documentation of what the code is doing important?  It better be.  What we are trying to accomplish by writing self-documenting code instead of comments, is to take the vessel, which is the code itself, and make that same vessel be the documentation of what the code does.  It is by doing this that we creating a living representation of the functionality of the code.  Comments are akin to a dead representation of the functionality of the code because they do not change automatically with the code.

I diverge to talk about comments so that I can draw a parallel to another form of documentation which is valuable and should be considered necessary.  That other set of documentation is requirements.  Have you ever written requirements documents?  Have you ever captured requirements from the customer and put them into UML diagrams, or perhaps plopped them into some templated Word document, which is never updated again, and no one reads, because no one trusts it is correct?  Wouldn’t it be great if we would replace that dead document or set of documents, with a living one?

The good news is we can, and some of us have.  And I fully expect this recommendation will be just as controversial, because I am suggesting that we don’t have to write low level specifications of the system at all, instead we can write good unit tests. When we do this, we are taking a dead form of document and bringing it to life.

Unit tests tell us why and how our code is effective

If

i = 5;  // Widget count defaults to five.

is replaced with

widgetCount = DEFAULT_WIDGET_COUNT;

then

1.1.5 When a new widget is created, the widget count should be increased by one.

is replaced with

public void When_NewWidgetIsCreated_Then_WidgetCountIsIncreasedByOne()
{
     WidgetFactory.Count = 3;
     WidgetFactory.CreateNew();
     assertEquals(4, WidgetFactory.Count);
}

The unit test is replacing the low level requirement, which is somewhat open to interpretation and untied to the code, with an absolute and completely tied-to-the-code, specific requirement.

The unit test is telling us why our code is built the way it is.  It is telling us what requirement that particular structure of code is trying to address.  It is telling us what end result that code is trying to accomplish and what the expectations are on the results of a given condition.

The unit test is telling us how the code is to be used in order to achieve its result.  It is serving as a living reference to the syntax and use of the code we built.  Instead of providing instructions on how to use our API, we are providing a living example, and proof that it will indeed work. Examples are often much more effective than instructions anyway.

What exactly are we replacing?

At this point we are not trying to replace all the documentation of the system (at this point).

With self-documenting code, we sought to eliminate comments, and replace them with good variable and method names.

With unit tests, we seek to eliminate technical documentation and requirements of the system, that is targeted at a developer or technical audience.

We are NOT trying to eliminate high level specifications of the system, or use cases. Unit tests DO NOT replace that kind of documentation! We will talk about replacing that kind of documentation when we talk about automated functional or system tests.

Simply put, any kind of documentation that you would give to a developer so they understand how the system works and how to use the code or APIs, can be easily replaced by writing good unit tests.

Our simple goal is to replace the “dead” documentation (meaning that it does not update automatically with the thing it is documenting), with “living” documentation in the form of unit tests.

One last point.  I want to be clear that I am not saying that having unit tests automatically results in the ability to replace technical documentation.  Just like having long-named methods and variables doesn’t automatically replace the need for comments.  It is a matter of the quality of the unit tests that are written, just as it is a matter of the quality of the self-documenting code.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Scenario 1

Bob: “Hey, where should we go to lunch?”

Joe: “I dunno, get in the car and we’ll decide later.”

Bob: “Yeah, we’ll just be agile about it.”

Giggle, giggle. Tee hee hee.

Scenario 2

Bob: “Hey, what are you working on?”

Joe: “I’m not sure what to do, Manager X told me to … and Manager Y told me to …”

Bob: “Ah, so you are being agile then?”

Gales of laughter, followed by a knowing wink.

Shut Up, Bob

Bob, you are causing harm. You are the reason agile has been coopted. You are undermining the efforts of your peers who are actually trying to better our profession. They are doing this for you, Bob.

Your cheap joke mocks a body of knowledge and professionals who are trying improve the life of your teammates. The fact that you will spend the next 20 minutes hanging out at the water cooler and planning lunch instead of driving positive change in your team lets me know where you are coming from.

When your CTO passed by and heard your little joke, it confirmed his suspicion he needs to keep the current command-and-control mechanisms in place. This also influenced his ideas of what agile really means, because all he had before is the contents of a 3 year old InfoQ article.

Bob, shut up. You aren’t just hurting yourself. You are undermining all of us.

The Passionate Programmer: Creating a Remarkable Career in Software Development by Chad Fowler is a book focused on helping you become fit as a developer – leading you along the path of life decisions that make the difference between a job and a remarkable career.  As Chad says, “You don’t win a race by trying not to lose.  And you don’t win at life by trying not to suck.”  You have to be tactical, strategic, and deliberate if you want to avoid your career being “one big series of undirected coincidences.”

I won’t belabor all of the points you can find in this book, but I’d like to call out some things that stood out to me.

• Be the worst
  • If you’re the best, nothing is challenging and pushing you to grow/perform.  Seek associations with people that are better/faster/smarter than you.
  • You’re not as bad as you assume.  Give yourself the chance to discover it.
• Practice at your limits
  • Chad’s background as a musician provided opportunity to compare skill improvement to music practice.  While performances are expected to be as perfect as possible, practice is raw, gritty, and doesn’t always sound good.
  • If all you’re ever doing is sitting down churning out elegant code, you’re not pushing at the edges (where all the improvement comes from).
• Study the work of masters
  • In the arts (and many other disciplines), much time is given to learning from the work of those that have gone before.  In the past, this was more difficult in software development due to its proprietary nature, but the sheer volume and quality of open source projects makes this much more accessible now.
  • Existing code reflects on your own capabilities for growth and new avenues of thought.
• Focus on the present
  • If your head is always in the clouds of tomorrow, you’ll miss the daily victories.

  One topic Chad alluded to but didn’t build much on was approaching your career development in an Agile fashion.  I thought this was a great concept, and from some comments on his blog, it looks like he’d like to build on this in the future.  My takeaway was that I’d better start my sprint planning for my career.

There were many other points and topics covered including interaction with peers, management, and customers.  Chad includes a number of “Act on It” exercises which will challenge you to grow in the areas he covers.  Overall, it was a great read with a message I needed to hear, and I’d highly recommend it.

I recently had the privilege of facilitating a Birds of a Feather session at PDC. The title of our discussion was “Agile – Triumphs, Teams, Trials, and Tribulations” and really just provided an opportunity for attendees to share stories. The session was extremely popular. So much so, in fact, that a fire marshal showed up to remove a few people from the room.

Cool, eh? Here is that not-so-cool part.

About 35 minutes into this discussion, I realized I hadn’t heard a question or comment that wasn’t related to Scrum. I asked the room, “How many people are on an agile team that is NOT using Scrum?”

5 hands. Seriously, out of about 150 people of so. 5 hands.

What in the world?

Is this simply a sign that Scrum won in the marketing wars? Is this just because some people have heard about Scrum? What’s the root cause of this?

Is it the C-word (certification) that goes along with the 2 day CSM course proving you didn’t die midway through class? Is it the fact that there are some MS Press books on the subject? Is it the fact that there is a soon-to-be-released Scrum Developer course endorsed by Microsoft?

I am not bashing Scrum, but it certainly isn’t for everyone. In fact, I find that Lean with a Kanban system is typically far more effective in medium to small organizations. I am just incredulous that Scrum is so ubiquitous in the Microsoft-stack enterprise.

Scrum does not define agile software development. It drives me crazy to hear someone say, “We are doing Agile. We have Sprints and everything.” I assure you, dear reader, 2 week time boxes does not an agile team make.

The other thing that really fries my chips is that something south of 20% of people who profess to be using Scrum actually are doing so. I have seen so many ScrumBut implementations I have started to expect it in any company that claims to be using the process.

My standard advice for any team is to implement a process without modification for at least 3 months before they think they understand it ell enough to tune it to better fit their needs. Of course, no one does this because “we are different”.

Yeah, sure you are.

The bottom line was stated perfectly in the BOF session by Simon Bennett.

“Don’t tell me by-the-book doesn’t work without at least reading the entire book.”

Additionally, we ended up on the one mystery topic that has always eaten away at me. That mystery for me is simple:

Why does one person or team pursue excellence relentlessly while another hits the door at 5:01 and doesn’t think about software development until tomorrow morning?

I got into the same discussion with Ted Neward at the recent P&P Summit while playing pool. Heck, it was almost an argument. I said something stupid that night. I said, “It’s all about incentives.”

Wrong.

One Theory: Incentives

I have had the opinion for years that there must be some motivator, some technique, or some dynamic that will affect people positively to simply care. This is the whole idea behind coaching, after all. A well-versed and motivating individual comes into a team and works with them to get better results. This happens every day.

If this will really work, it necessarily means that people are motivated by incentive. What I mean by that conditions like salary, a great leader, wonderful co-workers, free pizza and soda (or something) will inherently motivate someone to care about excellence.

Certainly no one can deny that incentives like these contribute to an enjoyable workplace. Heck, I love visiting the Microsoft campus and downing those free V-8s. All of them combined though, probably cannot cause someone to ponder, read, and learn. Incentives cannot move someone to try a new coding technique just because it might be interesting.

The Irritatingly Simpler Theory that is Likely True

There is just something about unique about people who can’t stop trying to improve. It isn’t the great boss or the great office space that causes me to think about the finer points of TDD in the shower. It’s just because I can’t NOT do it.

Both my mom and Ted Neward tried to get me to see that incentives will get you behavior and results (sometimes the ones you actually want), but can’t create passion. That is something that is simply innately there or not there.

This isn’t to say that there is no value in the person who wants to do their bid and get fair pay for a fair day. That’s not what I’m talking about. I am talking about the fact that most genius is recognized by relentless pursuit, the kind we can’t define.

The Good News

OK. Uncle, I get it. The great news is there are so many of us passionate geeks out there striving to improve. You wouldn’t likely be reading this if you weren’t one. Heck, I even geek to work with some!

What’s your theory? Are passionate professionals just the obsessive-compulsive ones?

Recently, it occurred to me to ask her a seemingly innocuous question:

When a client asks you to make something you’ve never made before, what do you tell them it will cost?

“First of all,” she replied, “every single job is something I’ve never done before.”

Boom. I think we’re on familiar ground here.

I wrote some questions for her to answer in an email and this post shows her responses. Her answers appear in italics.

I find this a fascinating discussion of project estimation and craftsmanship.

What do you do when the client doesn’t know what they want?

There are two kinds of clients that fit into that category: 

1. Those who have some sort of unqualified vision and hazy idea of what they want, but lack the vocabulary and expertise to complete their thoughts
2. Those who want something different from what they have, and don’t really care much beyond that.

Customer  #1 is the most work of the two.  They deserve and require time, since they are paying me for my services.  It takes time sitting with these clients, talking through concepts, drawing things on paper, asking questions and offering ideas trying to get to the core of what they want, what they actually need and what’s physically possible.  I have found that it takes a high level of skill to create something that is perfect to someone else.

Customer # 2 doesn’t happen often, but is a lot of fun!  These are the rare clients that enable my inner artist to flourish and shine, with no constraints or outside demands.  These are the clients want something new and shiny, but don’t have a huge list of demands. They want some sort of element of surprise. 

Problems ensue when I think I’ve got a #2 and didn’t ask enough question to realize I was dealing with a #1. 

How do you charge your clients?

Certain jobs have a set fee.  These are tasks I’ve done for 20 years; I know how long they take, I could do them in my sleep, and they’re the same regardless of the client.  On the incredibly rare occasion one of these jobs isn’t what it appeared to be, my bad and I eat the cost (and I’ll pay more attention next time!).

Other jobs, the custom jobs, are harder to price out.  Now that I have a larger body of work, I have a better idea of how long things take.  If it’s something I’ve never done, I estimate my time in my head, and then (because I’m always overly optimistic in my estimation) I double that to come up with my estimated total of time.  Then I factor in  what my time is worth per hour. 

I also have to know what other professionals are charging for similar services, as it’s tough to get clients if I’m charging twice what everyone else wants for the same service.

Do you tell them up front what a job will cost?

If it’s not a custom job, I always tell my clients the cost up front.  I may adjust the cost of a task between clients, but I don’t change the price after I’ve quoted on non-custom jobs.

Pricing custom jobs is a lot harder.  I run my formula:  estimated time, doubled, multiplied by an hourly rate.  And I offer that as an estimate.  I explain to my customer that it is an estimate to the best of my abilities, and that the price could fluctuate up or down.  I’ve learned that I don’t want the clients who aren’t willing to work within this structure;  these tend to be the people who really, really want custom work and really, really don’t want to pay custom prices.

What do you do when it takes longer than you thought?

I’ve found that the bigger the project, the more willing the customer is to accommodate  an extended deadline.  At the first sign of missing a deadline, I call the customer. It helps a lot, at this point, to be able to show my customer what I have actually accomplish already.

Also, if it’s something I’ve never done before, I tell the client that I’ve never done a job exactly like that one, and my time estimate is only an estimate.

On a long or complex project, when do you consult with the client to guide your decisions?

If it’s a client #2, I don’t usually consult with them once I’ve started the project.  If I’ve come to a point where things veer wildly in opposite directions, I may have the client stop by to choose option A or B.  Usually, with customer #2, I do it how I want to do it.

Custom jobs for a client #1 elicit a lot of phone calls.  I like to check with the customer at each phase when I’m not completely sure what they’d choose;  a 2 minute phone call takes a lot less time than picking 150 staples out of someone’s wingback chair.  I have never had a customer be irritated with me for making sure I was meeting their needs.

Here’s a link to the screen cast.

In this episode, Tommy visited with me about effectively applying Team System to some agile software development practices. This ranges from Continuous Integration to the tool aisle at your neighborhood Sears store, but I’ll leave that for you to discover.

• Tommy’s Blog
• Scrum for Team System
• Manifesto for Software Craftsmanship
• Visual Studio Team System

Get the show here

The slides from the talk are available below. The slide deck I am posting here is a bit larger than the one used in the talk. These slides include some interviews with the Starr kids that were left out of the slides at the conference for time reasons.

This episode is less rocket surgery, and more brain science. I hope you enjoy the show.

• IEEE Paper
• Slide Deck in PDF

Get the show here