Automated Unit Test Coverage and TDD: A Means to an End

June 3, 2014

“We have 100 percent coverage with our automated unit tests.” Based on this statement, would you feel confident that new features can be added the system covered by these tests quickly and easily? That the code can be updated with confidence because adverse side-effects will be caught immediately by automated unit tests?

If you answered “yes” to these questions, you may be in for a surprise. Automated code coverage isn’t measuring everything you need to know about your code base any more than your speedometer on your car is measuring how safely you are driving. Your speedometer is a gauge, providing a metric that you need to consider along with other factors, such as:
  • Are you driving at the posted speed limit?
  • Are you driving in inclement weather?
  • Are you texting while driving?
Conditions provide context. If you are driving on an icy road in a snowstorm, it’s a good bet that driving the posted speed limit is unsafe. And 100 percent code coverage is meaningless if we can’t add new features to the system quickly and easily, or at the very least catch adverse side-effects immediately when we do update the code.

What to Expect from Pair Programming

April 30, 2014

When you hear the term pair programming, what thoughts come to mind? As a programmer, are you concerned that you won’t be able to concentrate? As a manager, does pair programming conjure up thoughts of paying two people to perform one job?

I certainly understand that knowledge workers such as programmers need concentration time. I just don’t believe (any more) that programming should be considered to be a solitary activity. Sure, we all need time to gets things clear in our own heads, and sometimes the best way to accomplish this is with a little quiet time. There are other times, however, when it is faster more productive to work with others.

I’m sure that you’ve had the same experience that I’ve had in working through a difficult problem, where the ability to talk through a problem with someone else, to share perspectives and bounce ideas off of one another yielded a much better outcome. And there are those times when the act of verbalizing a problem is all that you need to generate that little spark of insight. All in all, I’ve had plenty of times where I’ve been grateful that others were willing to collaborate with me in dealing with complex problems.

And that is what pair programming brings to the table. And it’s also why a manager shouldn’t walk around worried that he or she is losing productivity because programmers – or testers automating test code – are paired up. Knowledge workers aren’t a part of a typing pool. They are engaging their collective intellect on solving difficult problems.

“Speed Enablers” of Agile

February 24, 2014

My previous posts that comprise Chapter Three were all about the business end of agile. I outlined how work is initially defined and progressively refined throughout the delivery process. I also covered how work should flow to teams along with how those teams manage that work and emergent change. And while this is a great start, there’s more to being agile.

As we look at how software teams deliver a solution, we need to examine the technical practices that are used in conjunction with an approach that supports lean and agile values and principles and the characteristics of learning organizations (these are covered in more detail in my post, What is Agile Development?). Technical practices are the second of three pillars in the House of Agile:

Figure 4-1

Plan to Adapt – Part Two

February 18, 2014

In my last post I put forth a simple idea management approach that involved an Investigating step as a means of assessing and refining ideas and concepts. What does this look like from an agile standpoint?

One of the primary needs is to obtain customer feedback as rapidly as possible, for the least amount of cost and effort. We need a tool that enables us to engage with and iterate with potential customers quickly and easily while assessing whether an opportunity is worth pursuing. One such tool is Ash Maurya’s Lean Canvas shown in Figure 3-13, which is an adaptation of Alex Osterwalder’s Business Model Canvas:

Figure 3-13 The Lean Canvas

The Lean Canvas is divided into two sections: Product and Market, with Product on the left–hand side and Market on the right-hand side. You fill in the canvas by moving between the two sections:
  1. Problem: Identify and briefly describe your top three problems that your product is addressing.
  2. Customer Segments: List who the customers are, and determine if they can be further segmented. If they can, it is recommended that you create a new canvas for each segment because other elements of the canvas will likely be different for each segment.
  3. Unfair Advantage: What do you have to offer that can’t be readily copied or bought?
  4. Solution: What is the minimal feature set that will satisfy your customers in ways that they will pay for?
  5. Key Metrics: What actions will users need to take that maps to acquisition, retention and revenue?
  6. Channels: How will you reach your customers?
  7. Cost Structure: What are fixed and variable costs?
  8. Revenue Streams: How will you generate revenue?
  9. Unique Value Proposition: Based on this information, what is the product’s primary differentiator and reason that it is worth buying?

Plan to Adapt – Part One

January 26, 2014

As I covered in Chapter Two’s The Depth of Agile discussion (in the What is Agile Development? post), agile is built from a foundation of Lean and Learning Organizations. Focusing on the business is one way of categorizing the values, principles and characteristics that serve as our foundation. Conceptually, the Business category is one pillar of what will be a House of Agile that has a common foundation:

Figure 3-10

The House of Agile is a model to act as a guide for reflection and conversation. By focusing on one pillar (I’ll add more in upcoming posts) we can ask ourselves what it means to be agile from that perspective. If we consider what it means to be agile in a larger business context from that of a development team, a couple of questions come to mind:
  • How do we plan, budget and govern our strategic initiatives to maximize ROI from an agile perspective?
  • What fast, cost-effective, lightweight techniques can we use to improve our decision-making on what to pursue from a strategic perspective?
We want to avoid is building a product based on speculation because it is extremely wasteful to build the wrong thing the right way. This happens all too often already; roughly three-quarters of the money invested in product development work results in products that do not succeed. (Christensen & Raynor, 2003)

Forecasting without Details

January 13, 2014

A good Product Backlog is an enabler, allowing agile teams to:
  • Get to work quickly, deferring on elaborating all of the details up front.
  • Accommodate changes quickly and easily, maximizing value while keeping the cost of change low.
In order to accomplish this, the Product Backlog should have four qualities that make it DEEP (Pichler, 2010):

Figure 3-8

Agile teams pull work from the top of the Product Backlog, where items are more finely defined than they are towards the bottom. This is what is meant by being detailed appropriately. Each Product Backlog Item, or PBI, in Figure 3-8 is represented by different sized blocks. The larger physical sizes of PBIs further down in the list in Figure 3-8 visually represent the greater scope relative to the smaller, more narrowly-defined PBIs at the top of the backlog.