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?

3 comments on “What I’d Go Back And Tell Myself – Part 1

  1. Since about a year now I am thinking through what I would have told myself back in 2000/2001 when I heard of Test-driven development and extreme programming the first time at university. I’ll come up with a blog entry this evening on it and reference your entry as a thought-provoking starting point.

  2. Hey Lisa…

    These points are completely valide… I am totally agree… here I can say something about QUALITY. Here the points come what we mean by Quality. Just providing what Customet/Buiseness wants or far more than that… Yes, that is very true that you should know the complete buisness structure before you automate them not entire system in one go but the learning and exploring part it should not stop.

    Very good question you have raised.. ” Do you know your business inside and out? Or only the application for which your team writes code?” To provide quality you should know what the expectation are from the Buisness.. its not enough just to write a code or test the app.. you should be able to co-relate and buisness logic and should be in a position to improve the buisness logic while implementing.. which requires deep study and understanding about the DOMAIN.


Leave a Reply

Your email address will not be published. Required fields are marked *


Recent Posts: