Quality over Short Term Speed
test driven development, scrum, software development
As a manager I had a proud moment on Friday at a regular standup meeting. Everyone went around the room as usual and since it’s nearing the end of the sprint, the testing members pressed on when the code would be ready in QA to start formal testing. The developer responded:
“We’ll be done Wednesday, like we said.”
The scrum master chimed in with:
“Well, could be be done Tuesday afternoon, or how about Wednesday morning?”
Again the developers responded:
“We’re going to be done by the end of the day Wednesday. That still gives you four days to test before the end of the sprint. It won’t be done until the late Wednesday because we still have a whole JSF page, backing bean, service, DAO, and unit tests to write. On top of that RAD is crashing on us all the time.”
The scrum master responded:
“OK, I was just checking to see if we had some wiggle room, sounds like we’ll test starting Thursday morning.”
I’ve been coaching my developers to always keep in mind everything they have to do including unit testing and refactoring and not to compromise quality when the push comes to get things done faster. Here was an example of a developer really standing up and asserting that they weren’t going to rush it and cut corners.
Ed Gibbs @ April 23, 2006
“RAD is crashing on us all the time”
I don’t know if you noticed but that’s an impediment that can be dealt with. It’s also one I’ve heard of quite a lot.
Good catch on the RAD thing. It is an impediment, but so far we haven’t been able to track down a root cause other than it crashes a lot more when working with its design views like the HTML design view.
So far dealing with it has meant staying out of design views more, but it still crashes at least once or twice a day for all the developers.