Archive for March, 2009

I have been assimliated!

March 28, 2009

I moved my blog last year because I had two Google accounts and I was two lazy to figure out how that impacted me editing my blog. In the mean time I have become fed up with Hotmail and Bloglines. Thus I have become a googlite. Gmail, reader, blogspot, docs, calendar are all now my tools of choice. Therefore I will go back to mwpolen.blogspot.com. Thanks for visiting.

Being Agile in a Waterfall Environment

March 21, 2009

Where I work the waterfall process is the norm. For a while I have let this fact frustrate me. This has led to me doing a less than stellar job. I would simply throw my hands up and say “It is what it is” and thus pass the blame to others. The victim anti-pattern! What makes this story even more ironic is that almost 7 years ago Rich McCabe and I wrote a paper titled “Should You Be More Agile?” in which our target audience were people in my current position!  Recently I have changed my attitude.

I knew I couldn’t do Agile full blown as access to the customer was off the table. I did have a BA that could act as a customer surrogate so I ran with it. The process has requirements handed off between development and a BA. I got permission to use a teammate to pair with. My pair wasn’t fully dedicated to the project as we both had multiple hats to wear.

We started each day with a 1 hour pairing/check-in session. The first one we  prioritized the requirements that we understood and started working. The first obstacle is that we were adding features to an existing system that was basically un-unit-testable. We did our best to work in short cycles and test (via GUI and DB) as often as possible. It was slower than I would have liked, but it worked better than our typical “one program in a  cube for a while” process. In between each session I would meet with the BA about requirements we needed clarification on as to not slow up the time the pair was together.

After 1 week of working this way we got all the new features done except one new report. The report looked harmless. We estimated it at 3 sessions. After 3 sessions we didn’t even have all the data requested, let alone a presentation of it. After 8 sessions we had the data on the screen, but unformatted! Needless to say we let our enthusiasm of our early success color our estimate. We also didn’t break the feature into small enough chunks nor take enough time thinking about how we would get that data. We also go stuck in several approaches to display the data that came to dead ends. To top it off we had no tests! We decided that making the system testable would have not added enough value in the short time we had. I didn’t like it, but practicality won out.

I have learned some things in this short effort:

  • When stuck, go back to first principles and find a way. Initially I balked at the idea of not involving the customer, but after some reflection realized that though it was less than ideal I did have a customer surrogate.
  • Remain practical. TDD can’t be followed with out unit tests. Spending more time on making a system unit-test-able than it takes to finish the project without it will only cause doubters to have reason to doubt. Use the principles and move forward, adding value each day.
  • Keep disciplined. We could not dedicate 100% of our time to the effort and on some days we got less that 50%. We were able to remain successful when we stayed disciplined (only code together, test everything, estimate small chunks). We failed when we let our guard down and underestimated a fairly large chuck that should have been split. Then we used the pressure of making a deadline to cause us to stop testing everything and code separately when one of us was busy with other things. When we refocused we go the job done without much effort. Discipline is key and doubly so when you don’t have a good support system (automated testing, full-time team, customer involvement).

Given that we are doing this at a time when we are moving platforms gives me hope for the future. The new platform will start off testable from day 1 and hopefully the other obstacles to better productivity will also be removed. Until then we will keep on keeping on.

Software Craftsmanship

March 8, 2009

Thanks to Uncle Bob I found the Manifesto for Software Craftsmanship. Is is built on top of the Agile Manifesto. Since it is short I will, repeat it here:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive

After reading and signing it, my mind brought me back to my job. This week was especially challenging. A system I inherited had several production issues. I did not ask for the system, nor do I respect it. This attitude has led me to treat it with disdain and thus not do my best on it. I let my guard down and did everything I know to be bad practice (e.g. no unit tests, large methods & classes) just because the code base was in the same vain.

The first item above struck a cord with me. I had working software, but poorly crafted. It led to a stressful week for me when I could have done better and prevented the problems. I often find myself in situations that appear to be no win. All my friends and colleagues agree with me. What I fail to do is realize this simple truth:

If you don’t like something, change it. If you can’t change it, change your attitude.
Maya Angelou

I am going to attempt to stop complaining about the hand dealt to me and strive to do my best . This will hopefully lead me to achieve the goals in this manifesto. I will also try not to enable those around me to adopt the same SSDD attitude that leads them to do poor work. I know I will fail more than I succeed, but it is nice to write it down and join a large group of other similarly minded folk.