In this installment (part 4) I intend to elaborate upon the second step of the software agility cycle: See the Problem in the Context of the "Whole" ...
Here the "whole" means both seeing and understanding the "big picture" and how any near-term/local changes we might make can impact or compromise the needs of everyone else in the value-chain. So how do we do this?
The basic way is to take a Systems Thinking approach within the (desired) context of a Learning Organization (particularly double-loop learning). That's a lot of fancy jargon without some very specific advice. There are a half a gazillion different ways to do that (see ValueBasedManagement.net for a bunch of 'em), so let's get a bit more concrete about some of the specific methods or means of doing this ...
In Lean terms, this would correspond to seeing the whole value-stream and optimizing the flow of operational value throughout the value-stream. Lean offers the technique of Value-stream mapping to help us see the problem/opportunity in the strategic context of the business.
From a Theory of Constraints (TOC) perspective, this would be akin to "the goal" of optimizing the throughput of value-delivery. TOC provides a whole host of Thinking Processes for us to figure out what to change, what to change to, and how to cause the change. The TOC Thinking processes are one specific set of tools for making strategic sense of the problem/opportunity with a focus on the end-goal.
There is also something called the Cynefin Framework (pronounced kun-ev’in) by Dave Snowden and his collaborators at IBM (see articles & resources at www.cognitive-edge.com). The Cynefin framework is a model used to describe problems, situations and systems. The model provides a taxonomy that guides what sort of explanations and/or solutions may apply. Basically you have to decide which of four categories your problem falls under: Simple, Complicated, Complex or Chaotic. There are pretty straightforward definitions for each of these in the framework so it's not too hard to take a stab at doing this. Then, each category has a recommended approach to use for strategizing:
- Sense-Categorize-Respond to discover "best practice" (for Simple issues)
- Sense-Analyze-Respond to discover "good practice" (for Complicated issues)
- Probe-Sense-Respond to discover "emergent practice" (for Complex issues)
- Act-Sense-Respond to discover "novel practice" (for Chaotic issues)
What are some of the more concrete ways agile methods use to "keep their eyes on the prize" in terms of focusing on strategic value to the business and seieng the whole problem (so as not to "suboptimize")?
- Using an onsite-customer (or customer-proxy) to maintain focus on business goals/priorities and always have the team working on the most highly valued features in the current iteration.
- Applying the LRM principle or the YAGNI philosophy when tempted to anticipate a feature or add additional flexibility/capability to a design.
- Applying the DRY principle and/or refactoring to make designs be simple and sufficient
- Using TDD to specify a requirement as a test, and then writing just enough code to pass the test (and using Acceptance TDD at the story/feature-level)
- Having the "navigator" in a pairing session focus the "driver" on strategic goals.
No comments:
Post a Comment