August 6, 2014

When it comes to software development, there is a lot that goes into this one principle that is critical to agility. Let’s take a quick look at a fictitious scenario that reflects all too many actual experiences.

You are a development manager for a company that is launching a new product, and everyone is excited to be starting fresh. However, this fresh start doesn’t mean that unlimited funds are available. It has been made clear by the executive steering committee that a marketable product must be produced within one year.

And after some initial wrangling a high-level feature set is targeted. Even though it is understood that the likelihood of everything making into the first release is small, there is a quiet expectation that most of the feature set will make into the first release. This concerns you, but you are comforted by the fact that you have a team of young, energetic, eager-to-please developers and testers who are up for the challenge.

They come out of the gate fast. New features are developed rapidly and it looks like you are in for clear sailing. And it is, for a while. Unfortunately, during the latter half of the project the team begins to struggle. It seems that every day testers are finding more and more defects. Your brief situational analysis:

The developers can’t keep pace – defects are being reported faster than they can be fixed.

Addressing all of these defects is taking time away getting the remaining feature set finalized.

You don’t understand the root cause of the defects, but the following concerns flash through your mind: Have these defects been there all the time, undiscovered until now? Is the team getting tired and perhaps a little sloppy? Are there greater issues with the underlying design of the software itself, causing what should be unrelated areas to break when new functionality is added? A combination of all of these?

While you would like to dig into these issues and take corrective action that will benefit you and your team in the long-term, you have another consideration. The business wants what they want.

Ultimately the team burns the midnight oil for weeks on end and makes the deadline for the first release. There is a modest celebration of the event, but not the hearty congratulations of a job well done. Even a toned-down celebration feels hollow to you.

You are taking a political hit because some of the desired features were dropped from the release, despite the expectation being set at the outset that this would most likely occur. Adding to your woes is that while the quality of the product is deemed good, it isn’t considered great. Everyone knows – but doesn’t talk about – the downgrading of some defects at the end of the cycle so that the deadline could be met with the quality goal of “no critical defects” in the product.

In addition, your team has told you that they really need to clean up some of the code because they brute-forced the coding of the final features in order to meet the deadline, plus they now realize that some of the early foundational work could be improved as well. Your hope is that there will be time to address to these issues later, if the product proves to be a success.

And shortly after its release, the product turns into a success – good news! The bad news is that there is a demand for new features and an ever-increasing volume of defects being reported by customers that need to be fixed. Revenue growth becomes intoxicating and being “responsive” to the customer is equated to fixing their defects and shipping new versions to meet contractual demands. (e.g., “I’ll buy this product if you add x…”)

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.

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.

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:

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:

Problem: Identify and briefly describe your top three problems that your product is addressing.

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.

Unfair Advantage: What do you have to offer that can’t be readily copied or bought?

Solution: What is the minimal feature set that will satisfy your customers in ways that they will pay for?

Key Metrics: What actions will users need to take that maps to acquisition, retention and revenue?

Channels: How will you reach your customers?

Cost Structure: What are fixed and variable costs?

Revenue Streams: How will you generate revenue?

Unique Value Proposition: Based on this information, what is the product’s primary differentiator and reason that it is worth buying?

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)

Welcome!

I'm currently an independent agile coach, residing in Portland, Maine. My work experience includes being a developer, a development manager, product manager/chief product owner, and agile coach. This blog is about channeling my passion for business, software development and writing – with an emphasis on agile leadership. The opinions expressed in this blog are my own and do not represent the views of my current or former employers.