Brad Appleton’s series of posts on What Is Agility? bring up the right questions, but they don’t dive into the muck, like a BBQ eater in a white suit. Muck diving is right up my alley, as the stuff I find interesting is usually at the bottom of the pile.
There are several fundamental problems to be solved, but the most interesting, by which I mean really hard, problem is understanding what is the most important thing to do next.
In The Agility Cycle, Brad quotes a host of luminaries, including himself, in defining what that thing is. I like Gartner’s the best, and here I’ll have to quote Brad, as Gartner won’t let me read their original:
- Sense the need for change in the environment (includes the proactive initiation of change)
- Strategize the available options and develop alternatives
- Decide which path to take and commit to the approach
- Communicate internally and externally to everyone who needs to know
- Act to produce results and follow-through efficiently
1. Sensing the Need for Change in the Environment
Let’s start with “Sense the need for change in the environment”. Beware of management aphorisms that sound like something you’d hear at a Yoga workshop!
Not only is it hard to tell what the need for change is, it’s as hard to agree on it as it is to get two people to agree to toppings on a pizza. By the time your company has it’s second employee, you’re in trouble. When you get your second customer, it’s pretty much over.
Practically speaking, there are four avenues in which we business people “Sense the need for change in the environment”:
1. Strategic Pressure. “The future is in Cloud Computing on the i-Phone. Get me there in six months.” Most engineering organizations are willing to set fire to the old application and do a little resume polishing on the new one. Nothing like starting from scratch, unless you actually want to make money.
2. Competitive Pressure. “Your App needs to do foobar, just like that other app does.” Now that’s going to happen every day after you ship version 0.9. It’s unlikely that any one request requires real change, but maybe that sound you hear is an out of control semi, and it might be nice to change direction before slamming into the grill of the truck.
3. Customer Pressure. “I’m not loading any more of your crappy releases until the .2 version, at least.” Hey, you Windows XP users, you know who you are. And who I am.
4. Financial Pressure. Sales drop. New Account sales drop. The CFO takes away our CapEx budget. We have to reduce headcount [or "Free people to pursue other opportunities" as they say in Hollywood], reduce hours, reduce pay. Doesn’t take a highly developed set of Senses to know things have changed. But what do we do about it?
It’s relatively easy to deal with Strategic Pressure: unless the pressure is coming from your CEO’s who’s an ex-Marine Karate instructor with a Meth habit: slow down amigo, and study it. Engineering is a discipline where things take time. The worst thing we can do is change priorities faster than we can get them to market. Change needs to require a good case.
Market of any size don’t have windows that close in six months. More likely people will learn that Prolog wasn’t really all that valuable, or you could like without a MS-Bob plug-in. SOAs and the ASP business model have been around for ten years. Before you imagine yourself as the next “i-Fart” author, ask yourself, what percentage of the apps on the i-Phone have made over $100K in revenue?
Competitive Pressure and Customer Pressure are not the same. Competitive pressure shows up when your organization is losing business to a competitor. Real Customer Pressure is when you can’t live up to your value proposition without making changes. These two are the realm of Product Management.
The difference between a great product manager and all the rest is whether they can determine which customer or sales requests require change, versus the ones that go to triage and get prioritized with all the others. Signals that you might have to really change what you’re doing are when you get demands for 10x performance improvements, or to support workflows that just don’t fit. Patches (“now 30% faster!”) just aren’t going to make those requirements go away. Now you’re going to have to think about how to address a new market environment.
Finally, Financial Pressure is the easiest to sense, and the least likely to activate change. Financial Pressure tends to make organizations to freeze up. Whether the reason was lack of product competitiveness, global recession, or a controller with a cocaine problem, the result is the same competitive and customer pressure, fewer resources to deal with it, and (unless you’ve been investing in those employee meditation session) lower morale.
Two mistakes managers typically make: trying to use the same development process, and freezing CapEx.
Improving the development process is your way out of this mess, not something you can’t afford to do. That’s like the teenager who knows he’s going the wrong way, so he drives faster. And, if you have the cash (or if the government is giving it out like candy on Halloween), Capital Expenditure is the cheapest way to get onto a better process.
Lorne Cooper
Hi Lorne! I think you’re missing the boat on the meaning (and appication) of some of these “steps” in the agility cycle. The “Sense” step is about the various feedback loops we setup to validate our knowledge so far and identify problems. I was planning on diving into that in one of my later posts in the series, but examples of this are:
Iterations: An iteration is one feedback cycle we use, and one of the larger-grained ones. At the end of the iteration, we demonstrate the results to the customer and get feedback about what we did right/wrong and what to focus on next.
Stand-up Meetings: This is another feedback cycle to hear from the workers in the trenches what problems and impediments there are. This typically is setup to happen daily.
Continuous Integration: This is a feedback cycle that gives developers feedback on not just whether or not what they just coded works, but how well it does/doesn’t fit with what everyone else just implemented. It happens at least a couple times per day per developer (if they are practicing CI properly, and not just doing daily/nightly builds)
Test-Driven Development: This feedback cycle forces one to first validate their thinking about the test (even watching it fail first) before trying to write the code that passes it. As far as knowing what you’re supposed to be trying to do, this forces that to happen at the front of the programming task, in terms of understanding the requirements very precisely, and designing for testability. It also forces the granularity of this feedback cycle to be pretty darn small (often just hours, or less).
Pair Programming: This is the most fine-grained of all the feedback loops mentioned above. It gives that second pair of eyes whose purpose is not to try and co-author the code so much as to ask questions about the clarity, correctness, necessity of what the programmer is writing, and maintain the strategic direction of that effort.
Every single one of the above are feedback loops that are set-up to “sense” a problem/opportunity. Each one of them goes thru the agility cycle at its own level-of-scale. And each one of them requires being able to “make sense” of the problem/opportunity after you’ve sensed it.
That’s the second step of the agility cycle, the part I called “seeing the problem in the context of the whole”. Because, youre right, it’s not enough to just have have a regular knowledge-validation indicator of feedback that something needs to be addressed, you have to remember to “keep your eyes on the prize” when considering what the heck to do about it. That’s why we have to think strategically, about the end-goal before adding that unneeded abstraction or anticipating that not yet high-priority requirements, or solving that seeming urgent build-breaker with a band-aid that actually makes things harder for the next “consumer” downstream in the process.