Agile Principles: Self-Organizing Teams are Motivated Teams

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
– Agile Principles


Allow the people doing the work to self-organize and discover the best implementation they can given what they know right now. Protect them from organizational politics and outside distractions, enable them to focus on the work at hand.


While we encourage self-organization, we remember the need for direction. While the team does not self-direct, they need a clear vision and an understanding of success in order to attain the autonomy and purpose required to feel motivated.

Agile Principles: Collaborate Everyday

Business people and developers must work together daily throughout the project. – Agile Principles

Email is not Enough

Working together involves more than exchanging e-mails about the software. It’s more than passive instant messenger conversations. It’s not reviewing a digital agile tool in isolation. Working together means collaborating, negotiating and exploring the software that is being built.

Too Busy for Success?

If you’re too busy to interact, fairly frequently, on a daily basis with the rest of the team, you’re too busy to enable product success. High performance teams don’t allow their schedules to be overrun by meetings. They don’t let anything get in the way of daily collaboration, negotiating and exploration.

Agile Principles: Frequently Deliver Working Software

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
– Agile Principles

Quick Feedback

A short feedback cycle is incredibly valuable. A short feedback cycle helps ensure you’re building the correct thing. A short feedback cycle helps you decide if you should keep going. A short feedback cycle helps you know if you should stop.

Product vs. Project

Shift your mindset from working on a project to working on a product. Products don’t have end dates, they continue to exist and the organization realizes their benefits over and with time. As time goes on, incrementally release working features for the product so that you can harness the power of short feedback cycles.

Probability, Velocity and Re-Estimating User Stories

When working with user stories, story points and SCRUM, it is not uncommon to come to the end of a sprint and realize that a smaller story took longer to complete than a larger story. While this is an excellent reminder that story points reflect complexity, not effort, it is often misinterpreted as an indication that remaining stories need to be re-estimated. Basic probability distribution shows us that over a large enough sample, all three point stories in the product backlog will take about the same time to complete. A team’s desire to re-estimate stories in the product backlog based on a few stories deviating from the norm is a mistake.

Not All Stories are Created Equal

If you were to roll a pair of dice a million times, you would see the majority rolls sum up to seven. If you graphed the data, you would see a bell curve shape. User stories are no different.

Over a large enough sample, you will start to see the same bell curve shape in the time it took to complete those stories. Some three point stories might take two hours to complete while others take twelve; but most take seven. At the same time, some of your five point stories will take ten hours to complete and some twenty four; but most take eighteen. Consider the overlap in the following diagram:

The overlap between the time to complete some of the three point stories and some of the five point stories should not be mistaken for a need to re-estimate any stories. Sometimes a three point story will take as long to complete as a five point story.

Commitment Driven Planning

One technique from which all SCRUM teams could benefit is that of Commitment Driven Planning. From Cohn’s Agile Estimating and Planning

A commitment-driven approach is an alternative way to plan an iteration. Commitment-driven iteration planning involves many of the same steps as velocity-driven iteration planning. However, rather than creating an iteration plan that uses the yesterday’s weather idea to determine how many story points or ideal days should be planned into the current iteration, the team is asked to add stories to the iteration one by one until they can commit to completing no more.

So what happens when a three point story is tasked out and comes to ten hours, and a five point story is tasked out and comes to nine? Often times the first inclination of the team is to inflate the three point story. Especially interesting is that almost no one suggests to shrink the estimate of the five point story. Again, we should expect that some three point stories will take the same amount of time to complete as some five point stories, but in the end this will even out.

Velocity is The Great Equalizer

Again from Mike Cohn’s Agile Estimating and Planning

What’s happened here is that velocity is the great equalizer. Because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. We cannot simply roll a die and assign that number as the estimate to a feature. However, as long as we are consistent with our estimates, measuring velocity over the first few iterations will allow us to hone in on a reliable schedule.

As the team complete more and more sprints, developers will come across three point stories that are a little larger than average and five point stories that are a little smaller than average. Between our bell curve distributions and velocity acting as the great equalizer, over time, the bumps in the estimations will smooth out and the desire to re-estimate stories will fade.

Agile Principles: Iterate. Evaluate. Repeat

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The first thought here is the means, the second the end. Let’s start with the second.


We want to afford the customer the ability to adapt to rapidly changing markets. Processes that restrict the customer’s ability to adjust the implementation strategy of their vision make it impossible to use change as a competitive advantage.


Focus on current priorities, delivering value with a consistent cadence. As you iterate, allow for the customer to evaluate changing conditions in the marketplace.

Iterate. Evaluate. Repeat.

Agile Principles: Deliver Early and Often, but Always Deliver Value

The Agile Manifesto describes twelve principles of agile software. In a series of twelve blog posts, I will explore each principle.

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

This principle can be broken down into two separate thoughts. Continuously delivering early, and always delivering value.

Delivering Early and Often

Delivering early is more than just delivering something before the competition. Delivering early is more than just delivering before you would have had you not been being Agile™. Delivering early means specifically delivering less than you could have otherwise. Continuous delivery and iterative development are synonymous, it is not enough to just deliver early, you need to frequently do so.

Always Deliver Value

Delivering value is difficult. At a high level, it is difficult to know what is and is not valuable. Following the process and being disciplined can get you to a point where you are delivering early and often, but without a unified vision of what you are creating, it is very difficult to deliver real value.

Delivery early and often, but always deliver something of value.

Using Bundler and Capistrano Behind a Proxy

When you’re developing applications for a fortune 50 company, you’re bound to run into a problem with their security focused IT department. Recently, I was having trouble deploying a rails application to a server that was sitting behind a proxy. I tried to solve the problem by changing bundler, then by reconfiguring capistrano, but those were both dead ends.

Setup Your $http_proxy

I thought that I could edit my .gemrc and that bundler would use those settings, but that didn’t work. I had been installing gems by using the --http-proxy flag so it seemed like that would work. I had also been contacting the outside world (for git and other things) by setting the http_proxy environment variable, but I was doing so manually each time I needed it, rather than setting it up in my shell’s rc file. Here’s how I fixed it.

This assumes that the shell you’re editing belongs to the user that deploys the application in capistrano.

1. Add the http_proxy to your shell’s rc file

# bash
export http_proxy=

setenv http_proxy

2. Ensure that when you create a new session, the http_proxy environment variable is actually set

$> echo $http_proxy

Now, when you deploy with capistrano, the bundle command will the proxy that’s setup and communication with your gem sources won’t timeout.

Why Developers Avoid Testing

While the drive towards a culture of “always be testing” has existed for some time, the recent detour into software craftsmanship has helped to create a new style of getting the word out. What used to be, “Test driven development is a great way to approach solving a problem” has turned into “If you’re not testing you’re a shitty developer.” The testing evangelism going on in the community today is misguided and would convert more people if it addressed the real reason people aren’t testing.

It’s Like Losing Weight

To the ever testing software craftsman, it can be puzzling why people don’t write tests. The assumption much of the time is that developers are lazy, that they don’t care about the quality of their code or even that they think testing is an abject waste of time. In my experience this is almost never true.

People skip testing because, ultimately, it’s hard work. Think about what it takes to lose weight or to quit smoking:

  • Break familiar habits
  • Disrupt your personal relationships
  • Acknowledge that you’re deficient
  • Find help
  • Fail often before you succeed

As a developer working in an organization that does not maintain a culture of “always be testing”, it’s going to be difficult to:

  • Change the way you think about solving problems
  • Upset peers who are comfortable in the status quo
  • Admit that you don’t how how, what, when and why to test
  • Find a mentor willing to help you improve
  • Not give up every time you get stuck

End the FUD!

Think about what it means to start testing when you never have before. Not only do you have to come to terms with not knowing what you’re doing, you eventually realize that you’ve been “doing it wrong” until now. This is fearful self-doubt territory for a lot of people.

If you’re serious about getting more of your industry peers to start testing, stop:

  • Going on about craftsmanship; people don’t strive for mediocrity.
  • Playing the doomsday “If you don’t test…” game.
  • Talking about how testing makes you so much faster; their personal experience points to the contrary.
  • Overlooking their perception of testing.
  • Forgetting when you were in their shoes.

Instead, ask questions, get to the root of the problem, don’t settle for “testing makes me slow” or “that’s not my job”, dig deeper.

I believe that as an industry we should strive for increasing code quality, robust test suites and better problem solving. As the minority who are practicing TDD/BDD/test-first/TATFT etc., we need to change our tune. Let’s stop preaching the benefits and start addressing the fear, uncertainty and doubt that keeps smart, capable and dedicated developers from enjoying these benefits.

Let Conversations Write Your Tests

I consider myself an early adopter of Cucumber and have spent a lot of time using, thinking about, writing about and discussing cucumber and, at a higher level, behavioral driven development. Lately however, I’ve really been rethinking how I use Cucumber and why. Am I getting enough benefit from the overhead and abstraction of plain text features? Could I do the same thing with RSpec if I just approached RSpec differently? Am I cuking it wrong?

This shift in thinking is due in part to Liz Keogh’s Step Away from the Tools and Dan North’s Who’s domain is it anyway?. Both of these got me thinking about how I’m using the term BDD (rather loosely) and how much of an investment I’m making in a specific tool (Cucumber).

More Meaningful Planning

Having meaningful planning meetings with their customer/product owner is one thing with which many teams struggle. Too often, we go too fast, don’t uncover enough detail, use the wrong language, don’t understand “done” and leave too many loose ends.

To combat this we draw screens, discuss workflows, ask leading questions and a variety of other techniques. I felt that while I was doing these things, I was still frustrated with the other part of the planning process. I’ve never liked traditional tasking and I’ve never like the idea of having to translate all of the data gathered with the customer into some other form only to express it later in a test in yet another form.

What if I wrote my tests during the planning meeting?

I decided that changing the way I gathered conditions of satisfaction, defined “done” and discussed workflows with my product owner would give me the biggest boost in value delivered, so one day I did just that.

For the following examples, assume that we’re adding a feature to an e-commerce website.

As a user I should be able to manage addresses so that I don’t have to enter my information more than once

As I’m discussing the feature with my product owner, I will discuss with them the possible scenarios, including workflows, required to use the feature. Some scenarios for this feature might include:

  • When I am on my account page
  • When I am creating a new address
  • When I am deleting an address

These scenarios might have scenarios of their own:

  • When I am editing an address
    • When I successfully edit my address
    • When editing my address fails

So far I’ve been able to ask the product owner something like “So when I’m editing my address, and I miss some required fields, what happens? What do I see? Where do I go? What are the required fields?”. I can also draw pictures to explain the workflows and ask more questions “What’s on this page? Where is the error message displayed? Do I see error messages for the fields that are missing?”.

For each scenario, I can capture assertions that come from answers to the questions I’m asking:

  • When I am on my account page
    • I should see a link to “My Addresses”
  • When I click on the “My Addresses” link from my account page
    • I should be on my addresses page
    • I should see “My Addresses” in the page heading
  • When I am on my addresses page
    • When I have existing addresses
      • I should see each address listed in format xyz
      • I should see an “edit” link for each address listed
    • When I don’t have existing addresses
      • I should see help text explaining how to add an address

If you’re an RSpec user, you might be thinking, “Hey this looks like RSpec!” and it does. During the planning meeting I can capture these scenarios and outcomes and then use them nearly verbatim for my RSpec acceptance tests. Even better, when I run my tests, I can use the “documentation” format that RSpec gives you to output that’s almost identical to the scenarios above.

The conversation required to really define these scenarios and outcomes is challenging, but at the same time, very rewarding. I have also found that it’s pretty powerful to be able to sit with the product owner and view two nearly identical documents side-by-side knowing that one is automated test output.

Desert Code Camp April, 2011

Below are links to my slides and Speaker Rate profile for each of the three talks I gave today at Desert Code Camp.

Ruby on Rails 101

Speaker Rate

Everyday Extreme Programming
Speaker Rate

You Don’t Have to be a Ninja to Learn HTML5
Speaker Rate