I had the pleasure of attending the Agile Project Leadership Network (APLN) Fall Leadership Summit in Richmond, VA yesterday. This was a great event and I would encourage anyone to attend future APLN sponsored events. I collected some quotes I overheard yesterday and have provided some explanation as to why I found them interesting. Some of the longer quotes are paraphrases; please forgive any inaccuracies.

10. “It seems like all of this Agile stuff is just common business sense.”
This late question during the Lunch Panel was from one of the few attendees who has not yet experienced effective Agile practices. Of course, Agile is based in the common-sense business practices of increased communication, eliminating bureaucratic barriers, empowering the individual and collaborative management. These may be common sense, but I am not sure how common they are in practice.

9. “You should take your customer outside and shoot them.”
This laughable comment was suggested during a Think Tank session. The customer in question was demanding an Agile approach and refusing to prioritize a thousand-item requirements document. The speaker of this advice was joking, I think.

8. “Agile will not create competence.”
Steve Greene, Director of Tools and Processes at salesforce.com, emphasized the strength of his team as an indicator of Agile success and the panel agreed that the transparency inherent in an Agile approach will highlight those who are struggling to perform effectively.

7. “The embedded social engineering practices of Scrum give it a significant advantage.”
In a personal discussion with Robin Dymond, a managing partner at Lean and Agile consultancy innovel, LLC, he highlighted the important concept that Planning Poker, Daily Scrums and Continuous Integration are all examples of social engineering constructs designed to improve communication (and eliminate a huge barrier to positive project velocity.)

6. “I’m not sure if we are reaching your Zen state of Agile with this answer.”
Responding to a question regarding the “next higher state” of Agile teams, this Panel answer from Roy Maines of Wachovia received a few laughs.

5. “Our biggest challenge is translating the value of Agile into a pricing structure that resonates with our customers.”
I heard this comment stated several different ways by development companies/teams with external customers. The challenge being that the customers want to know “what is this thing (the final version) going to cost and how long will it take to build?” The answer was ultimately some version of “let us deliver something valuable in our first sprint and build on it from there.” Several people indicated frustration that this answer was not good enough for their customers.

4. “Now that our projects are Agile, we are discovering our infrastructure is struggling to keep up.”
Of course, this one was near and dear to my heart, as Stelligent specializes in helping companies overcome this challenge. Several leaders noted that their waterfall-influenced development infrastructure and software developers unfamiliarity with accelerated delivery principles was a barrier to fully realizing the advantages of their Agile transformation.

3. The entire presentation from Israel Gat.
Unfortunately, I cannot provide a simple “nugget” from Israel’s presentation that moved from the bitch-goddess Success through empirical analysis of the actual impact of Agile within BMC Software. The real-world, large-scale analysis of Agile’s overwhelming success within BMC was fascinating.

2. “Despite all advice from consultants, we went all-Agile, all-at-once.”
Another quote from Salesforce’s Steve Greene in a very interesting talk about how inter-related project dependencies prevented them from the tried-and-true approach of starting Agile with a small pilot and allowing it to build through an organization over time. Salesforce turned Agile all on, all at once, and has never looked back…an impressive story of corporate culture, resolve and confidence.

1. “At a minimum, I want to be able to react to market conditions. My desire is to shape market conditions. My goal for IT is to not get in the way.”
The keynote speaker, Niel Nickolaisen, CIO and Director of Strategic Planning, Headwaters, Inc. led off with this important business perspective on why companies have interest in being Agile. The ability to link Agile practices will business goals is a key skill for anyone looking to transform an organization. I felt this comment best reflected the sentiment of the panelist, speakers and attendees that Agile is not the end, it is the means; business value is the true goal.

So, what do you think? Did you attend the summit? What did I miss? Regardless, what do you think of some of these ideas and thoughts? Are you experiencing similar challenges and successes?

In his excellent book, Customer Centered Selling, Robert Jolles relays a poem about consequences:

A recent client lacked concern about building software regularly and successfully. In his mind, build failures were equal to the annoyance of a hobbled horse: something resolved easily when a release date approached.

But this same chain of events could be applied to the software business. My crude version of the poem – adopted for software development – lacks the poetic prowess of Mr. Franklin. Hopefully, though, it illustrates a point.

We would all be well served to remember the potential impact of small problems as we consider where to spend our resources. Little annoyances like failed builds or test cases can be very early indicators that you are “losing the war” in your development efforts.

How important are the little annoyances in your software organization? Do you get concerned if a particular build effort fails? Do you have developer test cases? Are they executed regularly? Who gets heartburn if they fail?

You probably know the rest of this quote, but likely have no idea where I’m heading with it. Well, it’s a brief conversation about making snap judgments.

At a client recently, we were discussing the effects of code coverage, code complexity, code dependency and other automated analytics and whether developer testing actually improves the ability of a company to effectively deliver software applications.

I was internally amused when a developer said, “This one time, we hired a guy who was a big-believer in JUnit, but his code wasn’t any better than mine.”

That was his objection. In total. One time he was underwhelmed with a colleague, so he really shouldn’t give any credence to reconsidering the topic.

It might be laughable if it wasn’t common. In fact, as a society we promote the idea of quick, intuitive decision-making. Malcolm Gladwell’s book, Blink: The Power of Thinking Without Thinking is a great example of modern trends about instinctive reasoning.

I, personally, love the byline of Jerry Adler’s review of the book How Doctors Think: “Snap judgments are cool, except when they’re wrong.”

The concept of “diagnosis momentum” in medicine is not dissimilar to development teams who are myopic in evaluating how they produce software. The best answers are found when you move forward with “deliberation, caution and systematic thinking.”

The next time you suggest a new change to your team and a fellow member starts an objection with, “This one time,” I hope you remember the “band camp” scene from American Pie. Try not to laugh out loud, but do try to challenge the notion that such a limited experience set is not of great value when contemplating change.

So, what’s your experience? Do you work with colleagues that often have an objection based on single-case experiences? Are they influencers or ignored? How do you lead them towards more deliberate examination?

The only thing more reliable than death, taxes and – perhaps – the Energizer Bunny, is the relentless churn of new feature requests for software products.

The moment you complete the (ridiculously ambitious) feature-set you are working on today, your executive, marketing and sales teams will be dropping a new set of requests in your lap tomorrow.

Another tight schedule. Another Herculean effort. Another amazing delivery.

Then, again (it keeps going, and going, and going), a new set of features.

The problem at most organizations is that the features you add today actually make it harder to add new features in the future.

For a project manager, or VP of Engineering, you can quickly get caught in an ugly cycle:

1. For the new features, you need to increase the size of your team
2. As your team grows, your budget pressure grows
3. With new budget pressure, you have to cut corners on testing and other important infrastructure
4. If you succeed, the cycle starts over (with an even larger team)

Occasionally, I will talk with someone who suggests that a growing team means growing responsibility and more importance within the organization.

But the problem is that this inefficient cycle reveals itself as the solution ages. A few cycles down the road and we see:

1. It gets more expensive to add new features
2. New feature calendars get longer and longer
3. The budget begins to spin out of control
4. New features introduce serious defects in seemingly unrelated code

Once a product reaches this stage, the “hero” of the growing team is now answering some difficult questions. The CEO begins seriously considering “moving the product offshore” as if that is some magic elixir – the new team in some foreign country has no domain experience or familiarity with the code, but adding three times as many people will save the day.

Regardless, the fun work environment of addressing customer needs has shifted into a stressful environment of financial pressures and slipping schedules.

At Stelligent, we believe that the way you prevent this inefficient cycle is to invest in your “software assembly line”…find out what is really working and where you could improve. Start setting some targets for code growth, source complexity, code duplication and test coverage. Apply the business practices of “Measure, manage, execute” to your development efforts.

If you’re not sure how to get started, there are many articles here at testearly.com and on our company website that can help point you in the right direction. And, of course, you are always welcome to contact us directly.

Ask any development manager how their coding practices stand up against “average” and they will likely say, “Sure, there are things we could improve, but we are as good as (or better than) average.”

This response is known as the Lake Wobegon effect, after the fictional town in the Garrison Keillor radio series A Prairie Home Companion where, he opined, “all the children are above average.”

A 2005 article in the New York Times found when investigating an online dating service that only one percent (1%) of the population admitted to having “less than average” looks.

Funny and interesting, but what does it mean about your code?

Psychologists tell us that, especially in areas we consider important, we have poor skills at “comparative ability.” If tasks are important to us - whether we consider them easy or difficult – we respond with empirically illogical numbers: 75% - 90% of us claim to be “above average”.

This, of course, is especially true with subjective measurements. Asking someone how good-looking they are is a different exercise than asking how their weight compares with others who are the same height – especially if you first provide them with a scale and an actuarial chart of average weights.

As we self-evaluate our own capabilities in the important area of code (and code quality), we must recognize our own vulnerability to the Lake Wobegon effect. A great way to accomplish this is to move from the subjective to the objective.

Analysis of cyclomatic complexity, code duplication, code dependency and test coverage are objective measures that can provide meaningful, actionable information about how well our coding practices actually work. Without an objective score, you cannot measure your progress. And, as Bill Hewlett (HP) stated, “You cannot manage what you cannot measure.”

Once you have objective measures, seek out comparables within your organization and/or your industry to see how you truly fare against relevant averages.

But the real value is not in actual comparables, it is in avoiding the negative impact of our own common weakness of comparative ability and transforming our self-analysis from the subjective world to objective measure.

For the record, I don’t think you’re ugly. And, for those of you who are even more offended by the latter statement (you know who you are), I don’t think your code is ugly either.

If you are outsourcing development or quality services to India, consider that even top companies like Google are struggling to hire talented engineers there. Two slightly different versions of an article describing the challenges can be found on the InformationWeek and Gulf Times websites.

If high-value companies like Google are struggling, you would expect outsourcing companies to have even more difficulty attracting talent.

A study published today in the New England Journal of Medicine concludes, “stepping on a scale every day, and adjusting eating and exercise habits accordingly, can go a long way in helping dieters maintain a weight loss.”

This reminds me of my favorite theme in accelerating the delivery of software: measure, manage and execute.

The same human nature that causes us to regain lost weight will cause our software projects to spin out of control if we do not regularly assess our progress and, importantly, adjust our actions to achieve our desired outcomes.

There is no simple scale to “step on” in the software development domain. But Stelligent has created the Accelerated Delivery Index™ to help your company quantify development.

Whether you use this index or develop an aggregated system of code, coverage and use metrics yourself, a daily reading of your status and adjusting coding and testing habits accordingly, can go a long way in improving your ability to quickly deliver reliable software solutions.

Are you stepping on the scale every day?

The “impossible” four-minute mile was accomplished by Sir Roger Bannister on a windy day in May of 1954. Now you can do it too. It is not that complicated when you think about it: just run four consecutive quarter-mile sprints in under sixty seconds each.

Okay, so maybe the actual execution isn’t trivial. But his approach to the problem correlates directly to successful software delivery: measure, manage, execute.

Bannister pioneered measurement, assessment and adjustment in competitive athletics. He studied how his body reacted to exhaustion. He modified his running technique to eliminate unnecessary movements. And he created a specific plan to track his progress and achieve his goal of being the fastest man in the world.

So how does all this relate to the software industry?

We all have development goals that can seem as daunting as the four-minute mile. All too often, our attempts at sprinting devolve into a death march to failure.

One reason, I propose, is that we are failing to capture what efforts are working and what efforts are failing. We often know very little about the actual source code we produce. And we rarely invest resources into measuring important data that could materially affect the way we manage our teams.

Bannister set up a regimen of ten quarter-mile sprints, meticulously measuring his results until he could accomplish them all in sixty seconds each. He recorded his times and tracked his progress. He adjusted his strategy based on the results.

What are you measuring related to the code generated by your teams?

Do you know how much code is regularly produced? Do you know how complex the code is? Have you calculated test coverage? Do you have visibility into module dependencies? What is the percentage of duplicated code? How long does it take to generate a complete build? What about a complete build on an entirely new machine?

Have you established internal targets for any of these metrics?

At Stelligent, we help companies measure their development effectiveness based on the Stelligent Quality Risk Index. A significant part of our expertise is working with our customers to determine which measurements are applicable to their individual needs. Then (just as in Bannister’s case) we record and track progress and help adjust the strategy to achieve their business goals.

The end goal is not to create less complex code, reduce defects or lower integration times – these are just the positive time results of quarter-mile sprints. The end goal is to accelerate delivery of reliable software. But you cannot achieve that larger goal by simply showing up at the track and running as fast as you can. You have to measure, plan, train and improve execution.

And it all starts with a simple question: how well do you run the quarter-mile and what measured factors are preventing you from running faster?

Steve McConnell observed as early as 1993 that, “trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often.” This quote from Code Complete is as true today as it was then.

I joke with my team that “testing” to improve product quality is like trying to make your car go faster by looking at your speedometer.

Why then, am I the CEO of a company that chooses “Test Early” as its motto?

Because testing – specifically, developer testing – is the most powerful way to assess the quality of code and introduce meaningful practices to improve code quality.

There remains an ongoing debate about the economic impact of software defects, the relevance of testing to address that economic impact and even the definition of “quality software”.

But, without testing – again, early developer testing – software developer teams are flying blind and relying on the implicit hunches of their most influential members.

Note that I used the phrase “most influential” rather than “best programmers.” Anecdotal evidence should assure the majority of us that these two groups are often not the same people.

My company focuses on quality of software during the manufacturing process. An analogous example would be to say if we were in the automobile industry, we would not examine a completed automobile, nor would we examine the plans for an automobile. We instead inspect and improve every step along the assembly line.

It is clearly true that a car with poor design plans will likely have poor quality – even if every step along the manufacturing process is executed perfectly. Also, a well-designed and built car could have little financial success if the final, completed product does not resonate emotionally with the car-buying public.

So, gaps in design and market assessment can have material impact on the quality of applications, independent from the effectiveness of the manufacturing process.

I believe, though, that the software industry’s biggest gap in competency actually lies in the manufacturing process itself.

Ask any VP of Engineering or Director of Software Development to provide metrics for the overall cyclomatic complexity of an application. Or the ratio of unit tests to complexity. Or the rank of modules by their dependency from other modules. Or the frequency and coverage of executing unit tests. Or the frequency and duration of a complete build of an application for final production.

My experience is that very few engineering teams give meaningful service to these critical measures of the software manufacturing process.

Does that mean that the code quality of these teams is poor? No. It just means that an assessment of code quality is based on the input of the most influential members of the team rather than independent, objective measures.

Another joke of mine is, “I’m not only the hair club president, I am also a client.”

I embraced this idea of improving software manufacturing by contracting a consulting firm a few years ago for my JNetDirect product business. I was so impressed with the way early software quality can transform the way developers engage in the creation of code that we acquired the company and launched Stelligent.

While testing does not make software better, it does give objective feedback regarding the quality of code that constitutes the product. Constructing meaningful tests that (1) become an artifact of the code repository and (2) are executed with every change to the product will provide real feedback to the engineers who author code.

Looking at your speedometer will not tell you why the car is moving slowly, but it might remind you that you have left the parking brake engaged before you start smelling the fumes from your brake pads.

As in any competitive endeavor, you cannot win unless you keep score. If improving software quality is your goal, you need the scoring mechanism of developer testing to gauge the effectiveness of your efforts.

Testing may not make better software, but it will let you know whether the software you are making is getting better or worse.

Without testing, you are playing the game with your eyes closed. You might score. Then again, you might be shooting at the wrong goal.

In my last blog entry, I discussed Software Quality for Acquisition Valuation and identified that acquiring companies can negotiate lower valuations for software companies who do not follow early testing practices.

The positive corollary to how these practices affect acquisition valuation is that early testing practices have material impact of the value of software assets. In fact, early software quality practices add critical components that dramatically increase the value of software assets for an organization.

In software engineering, we think mostly about problems and solutions, leaving the questions of business value to our fellow executives. A simple illustration of what developers tend to do is shown below:

In traditional manufacturing, the business value of “process” is well understood. Even lay people can appreciate that the value of an automobile manufacturer is not in the ability to produce a single instance of a car. It is in the reliable and repeatable ability to create high-quality cars at a predictable cost.

The actual business value of source code is related to its ability to reliably produce quality executable programs as requirements evolve. A primary factor in valuing source code as an asset is its independence from the developer who authored it.

Early testing practices have appreciable positive impact on the quality of executable programs. But, much more than that, they add artifacts to the source repository, which help build independence from authorship.

Using continuous integration practices and ensuring that code complexity, test coverage, source dependency and other metrics are maintained at reasonable levels helps increase the value of the source code assets.

Many software organizations discuss strategies that include a sale of their organization to a larger entity. Shouldn’t the engineering team consider the impact of their process decisions on the evolving value of its source code?