What I’d Go Back And Tell Myself – Part 1

My team was lucky in having Brian Marick visit us last week, interviewing some of us for his book “Travels in Software”. He had visited us back in 2004, and I hope it was interesting for him to see that 1) we used a lot of ideas we got from him, such as using examples to drive coding and 2) we’ve changed and grown a lot and are a productive team.

It was fun to be interviewed by Brian, and he asked thought-provoking questions. One question was, what would you go back and tell your 2003 self, when you first started on this team? Or presumably, even my 2000 self on my first agile team. This has started a couple different thoughts in my head.

Here’s one thing I’d be sure to tell myself. “Lisa, you are good at picking up a new domain, and you’ll learn about 401(k) plans, all their government regulations, how all the different users use the application and other knowledge directly related to the application under test pretty fast. However, there’s lots more to know than you think. You’ll still be learning about parts of the app you never saw before in 2009! Also, you’d better learn about the whole business, not just the parts that are automated in the app.”

Since Day 1 of implementing Scrum, our team has been committed to delivering the highest possible quality software, and I think we’ve done a fairly good job. However, one of our biggest problems has been that we sometimes misunderstand customer requirements, or miss requirements entirely, even though we are driving development with tests.

It was only after we made a conscious, concerted effort to sit with the business people, learn all their processes in detail, and document them, that we got a full enough understanding of the business. For example, only recently did I learn about all the different bank accounts through which money moves around, because much of the movement is done manually. It’s critical to know this, however, because it’s very bad when cash balances stop reconciling correctly, or when the clearinghouse or bank says we have a different amount in each account than we think we do.

Maybe it was important that we first master agile practices such as TDD, CI, refactoring, driving coding with examples and tests at all levels, and test automation, before we moved on to getting a broad and deep understanding of the business and of every person’s job. You can’t do everything at once. Still, it would have helped me to at least have a sense of what I didn’t know yet, so I didn’t have a false sense of confidence.

Do you know your business inside and out? Or only the application for which your team writes code?