Pivot Time!

May 23, 2015

You may have noticed my blogging output has declined. Halted would be more accurate. Before I stopped I was creating a series of Agile Expectations posts that were intended to act as a draft of a short book with a working title of Agile Expectations. I like the idea of using my blog to draft material as it’s a lightweight way for me to explore topics and share my thinking.

Right now my thinking and feeling are along these lines:
  • Agile Expectations as a book isn’t saying anything new or unique. I may be saying things differently (hopefully clearly and succinctly), but I’m not really bringing anything new to the table. You can pick up another book (or books) and learn the same things.
  • As I’ve reflected on this, I’ve come realize that my drop in output is directly related to my lack of enthusiasm for this project. I need to add value to your day as a reader – or at least feel like I’m adding value. 
I’ve decided to – as they say in lean circles -- pivot. Where I am heading?

As an agile practitioner I’ve taken note that Alistair Cockburn’s writing about Shu-Ha-Ri and how it has been both a popular concept and a sticky one. On top of that, a few years ago I wrote a blog post Bruce Lee on Software Development that was the subject of a European talk radio show (or so I was told). At the time I didn’t feel like there was much else to say, but it was one of those things that kept resurfacing in my mind. It’s like an itch that won’t go away until I scratch it.

I’ve studied and trained in the martial arts off and on over the years as well as being deeply involved with agile for ten years now, and I believe that there is an interesting story to be told by exploring both the differences and the parallels between martial arts and agile software development and the path towards agile mastery. Given this direction, I’ve decided to rebrand my blogging platform. I’m launching an Agile Shu Ha Ri blog and letting SoftwareResults fade away. It has served its purpose.

Please join me at AgileShuHaRi.net!

Technical Debt: An Avoidable Tragedy

August 6, 2014

Continuous attention to technical excellence and good design enhances agility. – ninth principle of the Agile Manifesto.

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:
  1. The developers can’t keep pace – defects are being reported faster than they can be fixed.
  2. Addressing all of these defects is taking time away getting the remaining feature set finalized.
  3. 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?
  4. 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…”)

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?