Ken Schwaber talks SCRUM at Google

This seminar presents the basic framework of Scrum and some of the implementation issues associated with it.

Keeping Customer Tests Interesting

I've gone back using GUI driven tests for the majority of Customer Testing situations. This comes after spending a lot of time and effort introducing "under the GUI" testing tools like Fit/FitNesse into projects, only to see them fall into disuse through lack of (ongoing) interest from the Customer.

In an Agile/XP project, Customer Tests are those tests produced for (and ideally by) the customer. The defining characteristic of a Customer Test is that it is interesting to the Customer. A test that isn't interesting to the customer isn't really a customer test. So how do we make Customer Tests that are interesting to our Customers?

Traditionally Customer Tests are manual tests, using the user interface to exercise specific test cases. I find Customers like this approach because it mirrors exactly how they will use the system. Unfortunately, as the system grows and flexes, Regression Testing becomes ever more onerous, until it becomes so backbreaking that it consumes the project. At this point either milestones or (and?) quality start to slip.

Automated testing tools automate this manual task with user actions are recorded as macros. These automated tests can then be replayed without human involvement. Unfortunately these captured tests are often expressed in strange macro languages that are hard maintain, making the tests brittle.

Fit/FitNesse type tests that run "just under the GUI " allow specific features and functionality to be isolated. This helps us reduce the overall brittleness of our automated test suite. Unfortunately that same isolation of features can alienate some Customers.

For many projects, using this type of testing requires a tech savvy customer, and even then are really only suited to a small subset of customer focused tests. Without real customer involvement, I'm often better off just expressing these business tests with xUnit. As practices like Test Driven Development have matured, most problems I see these days are now integration and configuration based problems.

More recently I've been using Ruby with the Watir library and rSpec to create user interface driven customer tests:

• These tests are scripted in Ruby, and drive functionality through GUI using the Watir object. This familiar GUI driven approach to testing keeps customer interest.
  
• Whilst tests are Ruby code and not English, using rSpec gives the test scripts a “plain english", easy to read and write feel.
  
• Since we are using a first class scripting language we can ensure that our script code is GoodCode. This significantly reduces the brittleness of the test scripts.

This isn’t to say that there isn't a place for Fit/FitNesse style "just under the GUI" tests. For the moment though, for me, in most cases both me and my customers are happiest with "via the GUI" testing using Ruby+Watir+rSpec.

Definition of Good Code

In practicing SimpleDesign, I've found Kent Beck's disarmingly simple definition of good code to be invaluable. Basically, good code:
- Passes all the tests
- Clearly expresses intention
- Has no duplication
- Has the fewest number classes and methods

That's it. As a driver for Refactoring in Test Driven Development it has helped me to produce some of my most simple and elegant designs and architectures.

While it's important to understand standard design patterns and object oriented principals such as Single Responsibility, Open Closed, Liskov Substitution, etc. Increasingly I feel that they are just techniques to help achieve a better balance across the above 4 points.

Why do I need to write the tests first?

When adopting practices like Test Driven Development, developers often ask why they need to write the tests first. Why can't they just write the tests after the code?

Emergent design is a fundamental principal in Agile development, where the overall software architecture emerges through doing the simplest design to meet the currently implemented features and modifying the design as new features are added.

For the design to emerge as both clean and elegant, we will need to apply lots of small refactorings as we go. To know that we have applied a small refactoring correctly we need to know that we have preserved behaviour and not broken anything.

The simplest way to do this is to run the tests.
If you don't have the tests until you have written the code, you can't run the tests.
That's why, for each little bit of production code,
you need to write a test first!

try ruby in your browser

Why the lucky stiff has created an browser based version of Interactive Ruby (irb). It's pretty good.

What's even better it has a built in step by step Ruby tutorial.

With great tools like Ruby on Rails for web development and Watir for browser based testing, if you arn't already using Ruby you should be. This is a great tool for getting you started.

Give it a try at http://tryruby.hobix.com/.

are you agile....enough?

A recurring question on many of the Agile discussion boards is what is Agile? The problem is that at it's most basic, Agile is simply the values laid out in the Agile Manifesto.

The Agile Manifesto was an agreement that was made by key software thought leaders including:
- Kent Beck, Ward Cunningham and Ron Jeffries (XP, JUnit, Design Patterns),
- Ken Schwaber (SCRUM),
- Martin Fowler,
- Dave Thomas and Andy Hunt (The Pragmatic Programmers).

The Manifesto was basically a statement of values, specifically:

"We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more."
Source: The Agile Manifesto

Great words, but how does that help us in practice? I believe that the key to being Agile is held in that last value: being able to respond to change.

In software development change affects us through changes in requirements, and changes in our code.

Coping with changing requirements
Requirements can change either because we realise that there has been a misunderstanding between developers and customers, or because the underlying reason for the software system has changed.

With traditional approaches we create detailed requirements documents and get customers to sign these off. We then try to discourage changing these "signed off" requirements by introducing heavy change control procedures. Unfortunately this approach doesn't work too well when:
- the requirements are still "wooly" (the customer isn't actually that sure what they want); or
- the business that the system is to support changes rapidly.

Unfortunately this approach also ignores the fact that it is actually extremely difficult to get a picture of a working system from a requirements document. This increases the change of misunderstandings between developers and customers.

With Agile approaches we try to respond to change in requirements by developing software iteratively. This drastically reduces the time to having something to show our customers, which in turn increases the feedback. Getting the feedback earlier means we can react to that feedback quicker. Getting feedback quicker makes it easier to incorporate any changes. The shorter the iteration - the shorter the feedback cycle.

This has to be a balance though - too short an iteration and you risk not being able to get anything meaningfull done. Most agile advocates recommend between 1 to 3 weeks as the sweet spot.

Coping with changing code
Changes in code happen each time we add or remove a line of code. This change is continuous, and carries with it the risk we break something.

With more traditional methods, we try control this change through clever architectures and up front design to limit the impact of this change.

With Agile approaches, instead of trying to control this change, we attempt to embrace it. We accept that we have a very good chance of breaking things when we change code and rely on fast running automated tests to help us catch this. Each time we add a small amount of code we rerun our tests - if they all pass - we have a confidence that we have not broken anything.

Fast running automated tests and short iterations
Fast running automated tests and short iterations. These are the two core tools that help us respond to change - and that is what keeps us agile. Many of the most of the popular Agile practices are based around making it easier to do these two things effectively and leveraging their effectiveness.

If you can get these two things working effectively for you. You are most of the way there.