Test Driven Development is not the same as agile!

So I was reading a recent blog post on this issue here. Here are a couple of key lines that really struck a chord with me:

• Over the last several years managers, directors, and executives have asked me to present empirical evidence that Agile will cost them less money and take less time

This is a great question. I'm interested in data from the community?

• A recent paper (here) published by Microsoft and IBM, showed that practicing TDD versus general unit testing reduced bug density by 40-90%. Reading this paper gave me one data point; bugs are one of the three things listed above that customers hate the most. The question is can bugs be equated to time and money?

This is really insightful and would suggest a renewed focus on eliminating bugs to reduce cost. But the author fails to include which is listed in the white paper is the associated cost of TDD. Here are the costs as noted by the paper "Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD." Despite the increase in additional development time, TDD is worth it as the costs of fixing issues post-customer launch is very high.

Overall the author of the blog has the right idea, that TDD is the way to go! However, he seems to conflate agile and Test Driven Development. They are two distinct things. One can practice agile and not TDD and vice versa. Now we can debate whether or not you should write unit tests for "private" methods :)

Benefits of Agile Software Development

Agile Software development is well documented all over the place. You can see the agile manifesto here. I'm not going to expound on all the details that already all over the place, rather I'm going to focus on the benefits that I have seen in practice. Enough of this theory and explanation of how agile would ideally work, here's the real scoop. There are some drawbacks of Agile and other benefits, more on that later.

1. Customer's change their minds and that is ok - The burden on trying to know every single detail of the customer/market requirements is greatly reduced. I have never worked in an organization where there were enough product managers to do everything that product managers are supposed to do. Having to write complicated and detailed technical requirements up front before development begins was always a huge burden. I hate being on the critical path. With Agile, I don't have to know every detail up front, I can accept the fact that the customer can see the product and change their mind.
2. Estimating work is much better in Agile - I love the concept of story points and velocity. It let's the team achieve a natural capacity and work speed rather than trying to work overtime to achieve an unrealistic deadline because the product manager took too long writing the requirements.
3. Team work is really emphasized - This is the real strength of Agile. Teams work together, teams communicate daily, teams communicate verbally. It just works well rather than just trying to throw "artifacts" over the fence to the development team.
   

The best advice I ever got

I read this recent article in Fortune (here) and wanted to share with folks. It contains interviews with several well known business leaders in which they share the best advice they ever received. I typically enjoy these types of articles as they allow us to "peak" into these personas to see what makes them tick. While I'm not in the same league as those folks, I did want to share some advice I've received that I'll never forget.

I used to work for a fellow by the name of Alex Bloom (now CEO of Handango) and he told me one time that "Results matter". I know this seem quite obvious, but often times folks jump into a situation without thinking of they can truly deliver results. It has to be tangible and deliver business value. So think about this before you accept your next project. No one jumps into a pool before checking to see if there is any water.

Another piece of advice I'd like to share with folks is "Always be prepared". Everytime I walk into a meeting I want to know my audience and be the most knowledgable person in the room. Everytime I ask a question, I want to have a good handle on the answer before I ask it. Everytime I prepare a presentation I want to know my audience and anticipate their questions. I always get a warm fuzzy feeling when a person in the audience asks a question during a presentation and I respond with "Great Question, I've answered it on the next slide".

Theory vs. Reality

When I got my MBA and they taught me about organizational culture, motivation, compensation, etc., I formed this ideal image of HR as playing a critical role in fostering an intangible resource (people) through all of the many things that HR can do. I thought to myself...this is how it should be!

But one step into reality has taught me that theory and practice are not quite one and the same. In reality, I've worked at companies where HR focused strictly on dealing with compensation and was nothing more than a blunt tool to be used when costs needed to be cut. I've also worked at one place where HR reported into the CFO. I thought to myself what message does that send to folks?

So I got to thinking, why is there such a disparity between what is taught in the classroom and the reality that I see. Then the answer hit me! The professors that teach these courses are rarely industry HR veterans, rather they are PhDs who get "real world" experience when they get hired as consultants to fix companies problems. So essentially I'm getting a consultant's perspective. How many of us have ever had a great experience with a consultant?