Getting some SCRUM on Part 1

Unless you’ve been under a rock for the last 5 years, you’ve heard about agile, xp, scrum and a bunch of other strange buzzwords.  Personally, I’m about 5 months into my first real hands-on experience with scrum and agile and here’s what I’ve learned so far.  Remember, your mileage may vary!

It ROCKS!

I rarely get excited about project development approaches, but SCRUM and agile just plain rock.  We are seeing dramatic changes from a project management perspective and a development perspective.  Honestly, seeing it in action is 10x more impressive than reading testimonials or “how-to” books.  I wish they would have called it “Common Sense Approach” instead of SCRUM, but oh well.

Development Impacts

Quality

Our #1 development priority is quality.  Not features, not time to deliver, but quality.  To achieve this, we’re spending significant effort building automated unit tests.  Everyone thinks they know how to build automated unit tests, but until you do it, you won’t appreciate the complexity.

The first step is to make unit testing one of the most important steps in you dev effort.  To do this, we approach building our app as follow:

1. Build the entities (we’re using nHibernate)
2. Build out the repository/data access (crud operations, searches, etc.)
3. Build the unit test (lots of them)
4. Finally, build the UI or services

By sticking to this approach we’re pretty much guaranteeing that business logic stays out of the UI.  Duh, of course “we do that”, but be honest, how many times does a little business logic leak into the UI.  Yeah, I thought so.  Some may argue to unit test the entities, but they are just to hold data, so there’s nothing much to test.

Good unit test are hard to write; there’s books written on the subject.  Here’s what we’re doing:

1. Full CRUD operational tests.  Using an ORM, you’ll find a few WTF moments after looking at the generated SQL.  While we don’t automate looking for the WTF SQL, creating the unit tests and logging the SQL makes it real easy to spot.  Besides, it is good practice to ensure that our data access can perform the basic CRUD operations.
2. Test the various search operations with varying parameters.  Test with valid and invalid parameter; test several boundary cases and throw in a few “gut feel’ tests.  You’d be surprise at how many gut feel tests discover the hard problems.
3. When we find a bug in QA or in UI testing, stop immediately, write a unit test that covers the bug; fix the code and you’re golden. 
4. A few other rules that are just good unit testing practices:
   1. Guarantee that each test can be run independent of the other tests.
   2. Guarantee that all tests can be run in any order.
   3. Do your best to construct your own test data; don’t rely on pre-existing data.  All good frameworks have test setup and destroy (tear down) methods; use them!
   4. When you need large amounts of data for a test, such as data paging tests, either bulk load data before your tests or pick a range of data in your DB and tell everyone to LEAVE IT ALONE.  TDD purist; back off; I know that you can test without the DB and it is overhead, blah, blah.  In my world, keeping a few hundred thousand rows in the DB is a much easier approach. 
   5. Find tools that will help generate the test code.  We’re just starting to investigate this and are looking at T4 templates, MyGeneration and other tools. Let me know if you’ve got a good one.
5. Each test should do ONE and ONLY ONE thing.  Don’t try to test all the crud operations in one test; you’re just wasting your time.
6. We are NOT following full test driven development (TDD).  We’re making some first steps and hope to get there eventually.

All the rest of SCRUM and Agile/XP approaches are very valuable, but I’m finding this to be the most valuable.  If you’re not ready to dive head-long into full SCRUM and agile, take up automated unit testing.  And while your at it, help your QA team to automate their testing. 

Other Benefits

• Reduces the ever growing boat anchor effect.  By this I mean that as you add features, you have to regression test, which becomes a bigger burden, aka boat anchor.  Automated unit tests is insurance against the boat anchor and introducing bugs.  Make changes, add unit tests, re-run ALL tests and when everything is green, you know that you didn’t break anything.
• The ability to refactor your code and really trust that you haven’t broken anything is enormous.  Change a few classes, run the test, all checkmarks turn green.  DONE!  Eliminating code debt over time provides tremendous payback in the long run.

My final word on automated unit tests is that your comfort level in not breaking things is ONLY as good as the tests you write.  And you can’t test everything and you will leave a few holes.  However, the benefits so far outweigh the time commitment that you should start now.

 

Small Chunks of Work

The second piece of SCRUM and agile that is dramatically changing how we work is breaking down the work into little pieces and getting them to QA quickly.  Honestly, this is just how I work anyway, so it wasn’t a change for me.  I’ve always tackled things one screen at a time or one business function at a time, so this just works. 

We’re finding that breaking tasks into 6 hour chunks works really well.  Knowing that something needs to be done by tomorrow is a huge motivator.  As an example, day one may be add a new page skeleton, including CSS and style.  Day 2, add basic functionality.  Day 3 add ajax and fancy UI (jquery anyone) transitions.  

Study after study has shown that tackling three tasks in a row is far faster than tacking all three at once.  It takes an average of 30 – 45 minutes for you to get back into the groove, so stick to one thing, do it right and get-r-done.

 

Final Thoughts

There’s a lot more to agile than I can cover, know or am experienced enough to discuss.  Here’s a few other key points to consider/research:

• Pair programming – I thought this was the biggest waste of time on the planet when I first heard of it.  However, if you have one engineer focus on the unit tests while the other is building the entities or repository classes; BINGO!  They will refactor on the fly, discuss problems as they arise and generally you’ll get far better code.  
• Continuous Integration – Just DO IT!  It is hard work, takes a lot of discipline, but is well worth it.  Java has had it for a long time and .NET is starting to catch up.  Just do it; really!
• Check-in code frequently – If you break work into 6 hour chunks, there’s no reason for code to be sitting on an engineers workstation.  Check it in, so we can all see what’s changing; no more secrets.
• Try things; break things; it is YOUR TEAM, so do what works best for you.

Project Methodology Impacts

I’ll cover our initial experiences in Part 2.

References

http://www.extremeprogramming.org/rules/unittests.html
http://www.scrumalliance.org/
http://www.testdriven.com/
http://www.methodsandtools.com/archive/archive.php?id=103

Advertisement