Feedback Junkies

Live Naked Planning!

Here's a short screencast about Naked Planning. The content is from my presentation at the Houston TechFest on value based planning systems. Enjoy!

Naked Planning and Other Risque Topics on the Improving Podcast

Mike and Allen from the Improving Podcast just published our recent discussion on Arlo Belshee's Naked Planning process, product development, and how it all overlaps with Software Craftsmanship.

The Improving Podcast is really good, and I think this one was no exception. Give it a listen and let me know what you think!

People Are Not Your Most Important Asset

Heresy! How dare you challenge the most treasured platitude in software development. Well, I'm sorry, but it's just not the case. The most important asset that any software development organization has is...

Test Driven Development in Java: Live and Uncensored

Here's the slide deck from my Introductory presentation on Test Driven Development. People seem to really get a lot out of it, and I've gotten a few requests for the slides, so I thought I'd share.

The second half is all coding, so the slides don't really do it justice, but if you've seen it already they can be a handy reference.

Download slides for Test Driven Development in Java: Live and Uncensored

We're not ready for Kanban

As an industry, we're not ready for Kanban. We can hardly do Scrum, which is just barely iterative at all. Forget one-piece flow...most teams can't even make a user story small enough to fit in an iteration, much less a day or two. Before we start talking about the next great project management paradigm, we need to take stock of our most essential skill: Our ability to deliver.

So you work on an "Agile" team? Let me ask you this: When you hit the end of an iteration or sprint, what do you do with your product? I'm sure you do a demo. Everyone does a demo. Do you actually ship it? To real users? Who really use it to do their real job and make real money?

If you don't, I'm sorry, but you're missing a key point of Agility. Yes, we have standups now. Yes, we have big visible charts. We have team rooms, and retrospectives, and even pair program from time to time. But if you were shipping to customers every 6 months back when you were using RUP, and you're still shipping every 6 months now that you're doing Scrum, all that stuff is just ceremony. From the customer's view, you haven't changed at all.

Not that the customer is the most important thing. Making money is the reason we all get up and go into work every day. If our customers won't pay for our products, it doesn't really matter how often we ship. Which is why I think most people under-rate the value of shipping early and often. Sure, customers are great. Revenue is great. What we really want out of shipping early and often is validation of our vision. Getting the real, hard data that shows we can make customers happy make money using the approach we've chosen, or alternatively, that we need to change course. That information is more valuable than the actual revenue because it validates our strategy. Operating for prolonged periods with an unvalidated strategy is one of the most costliest mistakes an organization can make.

Of course, the reason you don't ship your demos isn't because you don't want to, it's because you can't. Fear of your product crashing and burning once it gets into the hands of real users keeps you from shipping. You know those technical practices that XP talked about, that were left out of Scrum because they were "hard"...yeah, turns out, you're gonna need those if you want to jump on the Kanbandwagon. If you want to split up your work into Minimum Marketable Features, stop doing iterations, and ship every few days (instead of every few months), you're going to need some seriously hard-core test and deployment automation. And I don't mean those selenium scripts that Steve over in QA wrote after your last release. I mean fast, reliable developer tests that give you enough confidence with a press of a button (or, in the case of Infinitest, the press of the save button) to ship your code to the people who are actually supposed to use it.

Technical excellence is the key. It's the only way to advance to where you want to go. The good news is that once you get there, the focus is on value delivery. IT stops being just one big cost center, and starts contributing to the top line. Priorities shift. Goals become clear and story points give way to dollars. That's when you really start to walk the walk of early and continuous delivery of valuable software.

Inline Assertion Templates for Eclipse

One of the benefits of continuous testing is that it makes a lot of other techniques more valuable. One great example of this is an inline assertion. Inline assertions are added to production code, rather than test code, to prove whether or not various conditions are exercised in the code. For example, let say we're working on a authorization system, and we have a class called User.

public class User
{
    public final String name, password;

    public User(String name, String password)
    {
        this.name = name;
        this.password = password;
    }
}

Suppose we're curious about whether or not we ever test the system with a user that has a null password. If we're working with a legacy system, we might wonder if this class is tested at all. When using a continuous test runner, we can quickly add an inline assertion to find out, like so:

public class User
{
    public final String name, password;

    public User(String name, String password)
    {
        org.junit.Assert.fail();
        this.name = name;
        this.password = password;
    }
}

After inserting this inline assertion, the CT runner will run our tests and, if any failures occur, we'll know exactly which tests are exercising this constructor. If we want to dig deeper, we can change our inline assertion to:

org.junit.Assert.assertNotNull(password);

If this fails, we know that the condition we're interested in (namely, a user with a null password) is, in fact, created as part of our tests. We can check check the failing tests to determine how this case is supposed to be handled.

Inline assertions are intended to be temporary, and we remove them as soon as the tests finish running and we learn what we need to know. So, if we want to be able to add these assertions quickly, we can create Eclipse code templates to insert them with just a few keystrokes:

Download CT-Template-Probe

Download CT-Template-ProveNull

Try using this technique the next time you're working in an untested or partially tested project. It's a great way to identify untested cases in your code.

You're Already Using Continuous Flow (poorly)

Many teams out there are doing Scrum with a 30 day sprint. If you ask them, they'll tell you one of the reasons they adopted this process is to be able to quickly respond to change. If you look at the way they work, it's very much in line with that stated goal. The problem, however, it that what they actually do is totally different than what Scrum prescribes.

Lets examine the process of a typical Scrum team doing 30 days sprints:

• On day one of sprint #1, someone introduces a bug. They don't realize it, and it makes it way through the end of the sprint.
• On day one of sprint #2, a stakeholder happens to be playing around with the version of the product that was demoed for sprint #1. She notices the bug, and it's critical, so she adds the issue to the very top of the backlog. However, planning for sprint #2 has already come and gone, so it will have to wait for sprint #3.
• On day one of sprint #3, a developer fixes this high priority bug. The fix is demoed at the end of sprint #3, and the fix is now (at least, theoretically) ready to ship as we begin sprint #4.
  

This is what your certified scrum master will probably tell you is the "correct" approach. Do we actually address critical bugs this way? Of course not, because waiting 90 days from the point where a critical bug is introduced to the point where it's fixed is absolutely insane! No rational team would do that. Here's what really happens on these teams:

• On day one of sprint #1, someone introduces a bug. They don't realize it, and it makes it way through the end of the sprint.
• On day one of sprint #2, a stakeholder happens to be playing around with the version of the product that was demoed for sprint #1. She notices the bug, and it's critical, so she goes to the team lead and asks to have it fixed right away for the PR demo she's doing on Thursday.
• The team lead and the stakeholder argue about process and deadlines for about an hour.
• The team lead then relents, branches the sprint #1 demo code. He works into the night to fix the bug, test it out, deploy the new version, test it out again, and merge the change into the trunk.
  

At Improving Works, we use a continuous flow process for handling changes. As new bugs and features are pulled from the backlog, they are completely defined, implemented (using TDD) and deployed one at a time. That is, each completed feature or major bug fix results in a new release of the product. As a result, we release often. Very often. Infinitest, for example, is released an average of every 2.1 calendar days. These releases go directly to customers, because until we put those changes in the hands of our customers, they might as well not exist.

What is happening in the second Scrum scenario we outlined above is not all that different, from a process perspective, from what we do at Improving Works. We're both fixing critical bugs as soon as we possibly can. The difference is that at IW, the technical practices we employ give us confidence that our frequent releases will be stable, valuable, and work as expected. Ask the technical lead that hacked out a fix at 2 in the morning whether or not he feels the same confidence, and I suspect you'll get a very different answer.

Pretending that you don't have to respond to a crisis is irresponsible and unrealistic. The Agile value of "Responding to Change" demands that we rigorously employ the technical practices that allow us to react calmly and effectively when things go wrong.

TDD Survey Results

The results of our first annual TDD and Automated Testing Survey are in, and the results are surprising.

First, some interesting data:

• 49% said they ran a local build 10 times a day or more. 
• 50% said their local build failed 2 times a day or more.
• 23% said their build takes 5 minutes or more to run.
• 54% said they break the build on their CI server at least once per week
• 41% said they work on projects with test coverage greater than 75%

One of the things I was looking for in this survey is some data that reflects the cost of a failing build. We don't want our builds to always pass. You don't get any feedback from an indicator that always reports the same thing! But we also don't want them to fail too often because each failure has a cost. Whether it's having to fix the problem and re-run the test, or blocking the team while you fix the build on the CI server, there's a balance between the feedback we get and the cost we pay for failure.

One way to think about this is the cost you pay for getting the feedback is a hedge against finding out something is broken later. For example, I'll gladly take a minute to be 99% sure that my 30 minute deployment process is going to work. I had suspected that the typical failure rate for a local build is around 10%. However, the data seems to point to a failure rate that is closer to 20% (maybe more!).

If this is true, then it's very likely that people are paying way too much when running local builds. That is, they need to adopt practices like Continuous Testing, that help them fail faster. I'd be willing to be that there's also an inverse relationship between build length and failure rate. I think faster builds would lead to smaller steps, which naturally decrease failure rates. I'm looking forward to following up with more surveys to prove this theory.

You can get the raw data from the survey here.