Kai Ramuenke

If you ask ten people for what Agile is about, you will probably get ten different answers. In this post i don’t want to create my own definition but instead discuss two basic drivers for doing Agile.

A common response i get to this question is: Agile will make us deliver faster. Though possibly true if you are a mature Agile organization i don’t think this is what Agile is about in the first place. Is going fast really what you’re after?

In my opinion the most basic driver is to generate business value as early as possible by delivering working software. This is different from just going fast as you can deliver quickly but not the right thing to produce value. Generating early business value is only possible if the team works on the most important things first. It requires high involvement from the business and continuous collaboration throughout the project to make sure the team generates value. Apparently this is often neglected by traditional organizations through their functional structure and thinking in silos.

Another basic driver for Agile is removing pain points and obstacles in the delivery process. This driver is highly influenced by Lean thinking. You look at your delivery process and ask the question: What is our biggest problem in delivering high quality, working software. You identify the biggest problem, look at the root cause, fix it and look for the next biggest problem. You do this continuously and you actually will go faster as you are removing your obstacles step by step. Typical examples for pain points and obstacles are functional teams rather than cross-functional teams, manual testing rather than automated testing or communication through documentation rather than face-to-face communication and finding placeholders for conversation.

Having these basic drivers is great but there is a tension between these two drivers. If you only go for business value you will end up with heaps of technical debt. Technical debt can be generated by a change of direction to tackle the most important things first. Or by the simple fact that the team gains more and more knowledge about the system and domain from iteration to iteration. Technical debt also tends to have a high interest rate and the longer you wait to remove technical debt the higher the interest rate will get. On the other hand if you concentrate your effort purely on removing technical debt you will lose focus on business value or won’t deliver business value at all.

Hence the trick is to find the right balance between the two drivers when you plan your iterations. Deliver business value but also allocate time to tackle your biggest problem. I can’t really tell you the right balance but if you are new to Agile i would recommend to favor removing your biggest problem over delivering business value as it will have a long term effect on your overall delivery.

To define a user story as done can be a tricky task. It’s about negotiating with the customer and setting the right expectations. A common tool we use in our projects is defining Acceptance Criteria for user stories. Using Acceptance Criteria is great because we set expectations on the application’s behavior right from the start before implementing the story. We can drive the expectations of the customer on what will be delivered at the end of an iteration. Furthermore we can translate those Acceptance Criteria into executable and automated tests (more on that later). Thus we make sure that we do not break any existing functionality as we move on in the project. If a story passes all Acceptance Criteria it can be considered as done.

So how does an Acceptance Criteria look like? Let’s say we have a simple user story called “Login”:

As a registered user i want to log in so that i can view my personalized report

Acceptance Criteria are then described as scenarios. As an expample let’s look at a typical main success scenario for the user story above:

Given a registered user u
When entering username FooFoo and password BarBar
And logging in
Then the personalized report for user u is shown.

A story can have as many Acceptance Criteria as necessary to consider it as done. Don’t be fooled to believe you can define every Acceptance Criteria upfront. As the team gains more and more knowledge while proceeding in an iteration more Acceptance Criteria may be discovered. Your initial set of Acceptance Criteria should be enough to make everyone comfortable to deliver that story.

So why this format of “Given” “When” “Then”? On my current project we use RSpec, a Behavior Driven Development framework for Ruby. You start by writing your stories with the scenarios in plain text files:

Story: Login
  As a registered user
  I want to log in
  So that i can view my personalized report
 
  Scenario: login successful
    Given a registered user u
    When entering username FooFoo and password BarBar
    And logging in
    Then the personalized report for user u is shown.

Each Given, When, Then is a step and i can define these steps in Ruby:

steps_for(:login) do
  Given("a registered user $user") do | user |
    user.should exsist
  end
  When("entering username $username and password $password") do | username, password |
    page.type(username, account)
  end
  When("logging in") do
    page.login
  end
  Then("the personalized report for user $user is shown") do | user |
    page.should be_personalized_for(user) 
  end
end

The great thing about this is that you can reuse the steps for other scenarios and hook up the RSpec framework with functional testing tools like Selenium or Frankenstein to have real end-to-end testing. In addition you can integrate the tests into the Continuous Integration server to have automated regression testing. The effort the team puts into fledging out Acceptance Criteria is directly translated into automated test code producing minimal waste.