Turning Around an Agile Project Gone Awry

By ChrisEdwards | Published: August 1, 2007

To those who say, “We have tried Agile, and it just didn’t work”
I would reply, “Well, the first time I rode a bicycle it hurt pretty bad, and it wasn’t fun.”

Agile is easily done wrong. I have just started a new job, and the biggest reason the company hired me was to help implement Agile principles. They have been having troubles with their pilot Scrum/XP project. I have now become an expensive pair of training wheels.

Since coming onto the project I have seen several things that were not done right, and because of all this, the project is behind schedule, estimates are completely unreliable, and morale is low. The project that was chosen for this pilot is the most high-profile project in the company (probably not the wisest choice for a pilot), so everyone is looking at Agile with great skepticism now…it simply hasn’t lived up to their expectations.

I think this scenario is more common than we realize, and I can see how many people, inexperienced in the principles, can easily stray off course. Agile is not a magic formula that just solves all your problems for you. It is a disciplined set of principles that you must tweak and follow consistently, or the reward will never be seen. Its a drastic departure from the norm…and its not easy to get it right the first time.

I don’t blame any single person on the team for the failure of the project thus far. Its really an accumulation of many factors:

Under pressure to meet time constraints, many of the practices that seemed less important were forsaken to help make up time. This was done simply out of mere ignorance (not stupidity…there is a difference). When a team has not experienced the benefits of clean, fully tested code, it is highly unlikely that they will place a high value on it knowing they can crank out mediocre code faster. They simply don’t realize they will pay for it later.

Without an understanding of what qualities make up a good user story, they estimated using very large stories with very little detail. This led to grossly inaccurate estimates…and thus, a slipping schedule that only added to the pressure and caused them to revert to their old ways, compounding the problem.

To make matters worse, they never tracked the time they spent on any of the tasks so they could see what was underestimated and why, so they never realized what the problem was or where all their time was going. Because there were no metrics, they calculated their velocity by adding up the working hours available for each employee during the sprint. Obviously, these hours were not all productive working hours, and furthermore, this calculation is a huge divergence from how velocity is used and calculated.

All these factors fed upon one another to bring the project quickly into the red. Thankfully, because they were using Scrum, they knew quickly that things were not going well, and they had time to make course corrections…

I’ll be writing several blog posts in the upcoming weeks on the problems I encountered, their solutions, and other lessons learned in this project. I hope it is of use to others considering implementing Agile principles.

-=CE=-

Posted in Agile | Tagged | Leave a comment

Tests as a Targeting System

By ChrisEdwards | Published: July 28, 2007

Unit tests should tell you more than just if there is an error, they should tell you where it is.

I was going through some of my older notes on unit testing and came across a note where I referred to unit tests as a “Targeting System” and it struck me as a very concrete way to define what it means for unit tests to be “granular” or “fine grained”.

Let us think of Unit Tests as a “targeting system” that locates errors in our code. What attributes comprise a good targeting system? Two that quickly come to mind are precision and accuracy. Accuracy is whether or not you hit the target, whereas precision may be thought of as how small of a target we can hit accurately (not exactly a precise definition of precision, but you get the point). Any unit tests (if they are working tests) can be considered accurate since they fail when an error exists. But the unit tests may only be considered precise when they closely identify the source of the error.

A nuclear bomb is an accurate weapon in that it will destroy its target, but it not very precise since it destroys everything around it for miles. A rifle, on the other hand, is both accurate and precise. It can pick off one target in close proximity to other targets without affecting those other targets.

Unit tests should be more like a rifle than a nuclear bomb. When a test fails, it shouldn’t tell you that your app broke, it should tell you exactly what class and method broke.

The nuclear bomb test
A nuclear test might look like this:

1. Add basic data using business objects
2. Check that a summarized report has correct results.

If there is a failure, you have no idea what caused it. Was it the business object? The database? The report? Something else? Sure, the test has found an error…which is good, but you have no idea where it is…which is bad. In short, this test has no precision. Its exercising way too much code.

Many developers that are new to unit testing write these types of tests, then complain that testing is a waste of time. Their statement is just as imprecise as their tests. Its not testing (in general) that’s a waste of time, its imprecise (or “nuclear”) testing that’s a waste of time.

The rifle test
Rather than writing one huge “test it all at once” nuclear test, it is better to write many small precise tests. These are fine-grained tests that cover each small unit of functionality separately. Here is a sample of possible tests to cover the same code that the single nuclear test covered:

  • Test that each business object correctly stores its data in the database.
  • Test that each business object correctly loads its data from the database.
  • Test that the report loads correct data.
  • Test that the report aggregates the data correctly.

This is just a sample, but you can easily see that when one of these tests fail, you have a better idea where to go in the code to find the error.

So we can easily see that our unit tests should be fine-grained. This means that each of them should only cover a small portion of code so that when it fails you don’t have to look far to find the error. Poorly written tests cover a large set of code and thus you have to look through much more code to find the error.

Thinking of unit testing as a “targeting system for errors” will help you to design tests that reveal more than just the fact that an error occurred. They will reveal the source of that error as well. After all, fixing the error usually doesn’t take that much time, but finding it does. Write tests that pinpoint where errors are, and you will spend more time writing code, and less time reading it looking for errors.

-=CE=-

Posted in Test-Driven Development, Testing | Tagged , | Leave a comment

Code Smell: Using the Debugger

By ChrisEdwards | Published: July 28, 2007

When you have a lot of code to look through to find an error, you often times use a debugger. You use the debugger to step through code to find out where it is failing. This is a code smell.

CODE SMELL: If you find yourself using the debugger, your tests are not fine-grained enough.

Using a debugger indicates that your tests are a poor targeting system for errors. They have failed to find the error and you have had to fall back to another system to locate it. Refine your tests by breaking them into smaller units that test less code. That way, you have a smaller “probable failure zone” to look in when you get a failure. Ditch that debugger!

Posted in Test-Driven Development, Testing, Uncategorized | Tagged , | Leave a comment

Tests as an Auto-Notification Process

By ChrisEdwards | Published: December 29, 2006

Looking at tests in a different light.

In looking at how tests help eliminate bugs, I realized that one way it does so is by automatically notifying you when something doesn’t work in the way the test specifies it “should”. This got me thinking about tests from a different perspective…as an auto-notification process.

In looking at tests this way, I find myself asking a very different question: “What do I want to be notified of?”

The “normal” way of thinking about tests will lead us to answers like: “When feature X doesn’t work” or “When scenario Y doesn’t produce output Z.” But these are narrowly focused questions. Is that all we could possibly want to know about our code or the system under test?

What other conditions would a notification (failed test) be useful for?

Maybe we have an expected failure when the volume of data exceeds a certain number of rows. We know we need to make certain changes to the system when this happens. A test could “remind” us of that automatically when that happens.

We could have performance monitored by writing a test that will notify us if it takes more than X number of seconds to perfom operation Z. Thus we know we need to peform some optimzation.

Looking at tests in this light opens up the possibility thinking “outside the box” concerning testing.

Some of the uses that stem from answers to the question “What do I want to be notified of?” may be better suited for other tools than your standard xUnit suite, while others may not. Its just something for your brain to chew on.

I’m interested to see what others think of this, and the different ways it could be used.

-=CE=-

Posted in Test-Driven Development, Testing | Tagged , | Leave a comment

Thou Shalt Not Love Thy Code

By ChrisEdwards | Published: August 14, 2006

On my most recent project I have learned a very humbling, yet very useful lesson. Never fall in love with your code, or it will be too hard to let go.

In the Agile world, your code needs to adapt to changing requirements and the introduction of new features. When this happens, it just might be time to send that code you are so in love with off packing. If you cling to your code, or your design, you will not be so ready to do away with it…even when you should.

I learned this lesson the hard way. I had a design I was proud of. It was quite a masterpiece of abstractions an cleanly separated, reusable code. I had worked on the design and massaged it for over a year before we brought a new team of coders in to add some new features. At this point, I was the only one who understood the code…and rightly so since I had designed it. The problem was, it was so complex that others had a hard time grasping it. During a design meeting, we were discussing flattening out the system and removing a lot of the abstraction. I was strongly opposed to this since it would do away with some of the reusability I had designed in. I was outnumbered 3 to 1 in this debate, so I paused and sat staring blankly at the wall.

Let me pause here and back up to get some external context on my mindset at the time. My small bible study group had been studying the book of James, and I had been praying for humility. I had felt pride welling up in me and didn’t want to let it get the best of me so I asked to be humbled. This was only a day or so prior to this story…

So as I stared at the wall, I realized what was happening, and decided to be “easily entreated” and submitted to the requests of the group. I really didn’t want to, at the time, but I did. We removed the unnecessary abstractions and complexity.

Now it is over a month later, and I must say that it was the best decision for the project. I was humbled, and let go of my code. Now the system is much easier to work with. I understand it better than I had before, what’s more…so does everyone else! Our project is making better progress than it ever has, and it is still reusable.

I was hanging on to code that added no value to the customer, but only added to my pride. Now we are all much happier, and the code is much simpler.

Next time you are faced with a situation and find yourself clinging to your design, ask yourself why. Then allow yourself to be humbled…just let go…change happens.

-=CE=-

Posted in Agile, Continuous Learning, Design, Humility, Soft Skills | Tagged , , | Leave a comment