I was pleased to learn that my StarEast talk on an agile approach to defect management generated more discussion on the topic at the conference. Please read Gojko Adzic’s new post “Bug statistics are a waste of time” – it shatters a lot of illusions that organizations treasure about defect tracking and bug metrics.
This month’s issue Dressage Today had some articles about the two-time Olympian dressage rider and trainer, Steffen Peters. He talked about the role of discipline in turning dreams into reality. For him, this means keeping himself mentally and physically fit through a thoughtfully planned exercise and diet routine, as well as understanding the capabilities of each horse and how it can learn best.
My own dressage trainer tells me all the time, “It takes a million repetitions to change a bad habit.” That’s only a slight exaggeration in my case. I remind myself (and she reminds me) about 50 times a ride to correct each bad habit, for example, to put my hands closer together and keep them centered over the horse’s withers. Some of my bad habits are 50 years old, so they’re hard to fix, but I’m slowly getting better.
Discipline is a critical component of delivering high-quality software, too. We need to thoughtfully plan to use the right practices for us. We need to remind ourselves every day, via big visible charts, information radiators, retrospectives, any means that works to learn new good habits and reinforce the things we do well.
During a recent estimating meeting, our product owner (who normally knows better) asked, “About 6 weeks ago you estimated this XYZ story at 5 points. Is there any cheap, hacky way to do it for one point?” One of the developers responded, “Possibly, but we are not going to do a cheap, hacky solution”. It’s tempting to cut corners to meet a business need, but hacking in a quick fix that increases our technical debt down the road isn’t the way to do it.
Another example where discipline and good habits came into play occurred in this morning’s Scrum. A couple of the customers brought up a significant piece functionality that they had accidentally omitted from a story we’re already working on. It was tempting to say “OK, we’ll add that in too.” But it was too big a change to put into the story at this late date. We discussed possible workarounds, and one of the customers came up with one that would do the job. They will write a new story, and if we can, we’ll pull it in this sprint. If not, they’ll get it two weeks later.
Sometimes we do make compromises about quality, and implement a solution that is less than ideal. There are always business trade-offs to consider. But we don’t make these lightly. And even after more than five years of agile development, we spend time on a serious retrospective every iteration, and work hard to keep improving the way we work and the quality of our code. Some of our bad habits have been hard to fix, but we keep working at it. Our business continues to grow, which to me is the best feedback about our disciplined approach to keeping up good habits and eliminating bad habits.
This sprint has been an excellent example of why the whole team must commit to quality for the team to succeed.
In the past few sprints, we started to slide into the bad practice of having leftover testing task cards that got carried over into the next sprint. Some of these were cards to write new FitNesse fixtures to automate tests for a particular new piece of functionality. Some were end to end testing cards that simply take a long time to complete. There were also development cards left over. A couple of stories had dragged on more than two sprints. This was getting awful! It felt like we were dragging through waist-deep mud of technical debt.
In last sprint’s retrospective, we got serious about solving these problems. Here are our action items:
We focused on finishing all the “leftovers” first. For the new FitNesse fixtures, the developers asked that I first write example tests with my idea of how the test should work. The remote developer then wrote the fixtures and updated the tests as needed so that they pass. These fixtures were difficult to do as they had to use a lot of legacy code, but the ROI will be big because they test critical areas where we’ve had expensive production problems in the past.
There was only one incident of untested code being checked in, and we talked about it right away and discussed ways to ensure this stops happening.
6 days into the 2 week sprint, we still had lots of testing cards and not many development ones. The developers, of their own volition, decided during the Scrum to attack the test cards. By the end of the day, most of the test cards were finished! Then they went on to the stories that were new that sprint.
Since a glance at the online storyboard now tells us who the main developer is on each story, communication has improved. When more than one developer works on tasks for a story, they’re communicating better. Lots of pairing is happening too. Communication is better all around, including with the remote team member.
8 days into the sprint, a developer was writing up the information on the functionality he had changed for a batch processing story, and as he wrote, he realized that he missed a use case. He fixed it, but was concerned there wasn’t enough time left in the sprint to adequately test the new functionality. We decided to postpone that story to the next sprint. Consciously deciding to put off testing to the next sprint isn’t a bad thing, when there’s a good reason for it.
Although we are still very busy, it’s a great feeling to see our storyboard for the sprint with almost all the cards moved to the ‘done’ column. Since it’s holiday time, people are taking time off, so time is short. A task to automate testing for a new UI feature implemented with Ajax has been rolled over to the next sprint, because the test script is blowing up (anyone out there have experience with the mouseover command in WebTest?) Again, this was a conscious decision, not a case of “Oops, today is the last day of the sprint and we didn’t get this finished”.
Many teams struggle with trying to finish all the testing for all the stories by the end of each iteration. If this happens to you, the first action to take is to limit the amount of new work brought into the next sprint, so you can focus on finishing the leftovers. As you catch up and are able to reduce your technical debt by finishing testing and test automation tasks, you’ll be able to increase your velocity later, without sacrificing quality. This has to be a team effort.
Please post comments and questions and I’ll follow up on those. This is such a central factor to team and agile testing success, I’d like to talk about it more.
Agile testing practitioner and coach
