Nothing Happens in Zero Time

One of the benefits of Agile / best practices is integrity of completion: everything from requirements gathering to development to build to acceptance testing that needs to be done to drive a particular unit of business functionality to completion is encapsulated by it's definintion as a story. That is, we drive more finely grained units of business functionality to a state where that functionality can be utilized; that provides a boolean state of completion: 'tis done or not. This is diametrically opposed to the way in which functionality has been delivered since Eisenhower was president and Churchill was prime minister for the second time round: we have restructured business needs into technical silos of analysis, development, build, curse, test, negotiate and live-with-it. By doing so, we mortgage our future by borrowing against time-boxes in the hope that there will be sufficient bandwidth to complete inaccurately encapsulated and measured activity.

The benefits of the Agile approach are documented elsewhere, obviously the return on technology investment is much greater, as well as the transparency in knowing exactly where you are at any given time. Transparency is worth underscoring specifically because of the greater degree of fact (as opposed to opinion) there is in status reporting: requirements are in fact done or they're not done: "done" means they're ready to go live; "not done" means they're not ready to go live. There's no middle ground, no "I'm xx% complete," no mystery 6-week-window-at-the-end-of-the-project-in-which-we'll-marshal-test-and-deploy-and-hope. Above all, we rely far less hope. In and of itself this is a rich area of discussion which we'll continue to dissect, but it's important to acknowledge a subtle admission in all of this that must not go un-noticed: nothing happens in zero time.

When making work estimates we tend to assume that 100% of the effort required to get something done rests with developing (coding) software. In the process we overlook - and devalue - requirements gathering, unit testing, marshaling/building, integration, QA, UAT and releasing to production. To some extent, in the silo/waterfall world we collect requirements and assume the time / effort /cost to build code in support of two sets of functionality is marginally longer than the time / effort / cost to build just one. This isn't true as each requirements is more an "exception" than a "rule." Each introduces complexity to the business solution, each is code composed by different people which by it's nature presents different challenges. The point is, non-development-technical activity doesn't happen of it's own volition, and in many cases increases exponentially with an increase in the number of requirements piled-on, again as each requirement is really an aberration (introducing quirks, problems and issues) more than a uniform evolution of the platform.

In the same way, our "windows" for silo'd activity - separate time-boxes specifically for requirements gathering, build, a QA / UAT, etc. tend to be characterized by activity pile-on without refactoring the underlying time-box:

• In the abstract, ever notice how so many projects have a 6 week window at the end of the project for UAT? It's never 5 weeks or 7 weeks, it's 6. Teams tend to borrow against that 6 weeks all through requirements and development, over-mortgaging it to a point where when it's called - when the project is due - there's insufficient capital (time) to cover the positions. That's because we borrow on hope that we can cover our positions, not on fact.


• By way of specific example, in many projects, sometime during development somebody is going to migrate data; this data needs to be maintained. It often ends up a "ghost" task, sucking time away from people that they otherwise have allocated to complete (value-added) development. The same can often be said for deployment and / or environments: somebody has to own environments and own the process for putting software into production.

The point is that critical albeit non-development-specific activity ends up "piling on" during our different windows: the lead developer is now not just realizing the software but carrying a team, managing an environment and a deploy process, and keeping a data set clean. Subsequently, delivery defaults to a hero-based model during the days/hours leading-up to QA, UAT or production events. This, in turn, introduces a lot of delivery risk around that person's bandwidth: it completely collapses in the event of resignation or burn-out or if that person becomes a victim of the regional transportation authority (i.e., kisses a bus). Clearly it's horrific for the individual; what makes it a tragedy is that it's completely unnecessary business risk.

Consider the criticality of the underlying application and the cost of the risk being introduced by the hero-based model. Suppose failure of a software delivery means a commercial product doesn't get launched and revenue won't come in. Suppose further the burn rate on the development team is $200k / month and the monthly revenue is on the order of $10mm / month. The probability of delivery failure multiplied by the business impact of that failure (total costs incurred, lost revenue, etc.) becomes the maximum amount of insurance the business is providing to itself that it will complete development. From here, it isn't hard to construct a risk-reduction formula to identify the maximum the business is willing to invest to reduce the probability of failure. This is a time-sensitive calculation, so the sooner we're working this math the more likely a smaller increment in cost (people, resources, scope) will create a greater reduction in risk.

Put this in a spreadsheet for any project you have in-flight. Looking at the total commercial picture - business impact including IT commitment - consider two stakeholder perspectives:

• As the business decision maker, what would you want to know to take an informed decision at different points in the delivery lifecycle? There's less time to be responsive to changes in the business environment as the target delivery day approaches, and there's nothing worse than a negative change in the business environment that is self-inflicted.
• Then take the IT perspective and ask yourself (a) if it's better to personally guarantee success of the team - especially if you don't have the ability to execute that delivery - when you suspect it to be false or hollow, or (b) if it's better for you to be transparent on behalf of the entire team consistently through the delivery lifecycle.

If you want IT and business to be in partnership, you'd better be prepared to have this conversation, specifically in commercial terms. Those who will be politically embarassed by a failure to deliver - the product manager, the CEO, somebody who is measured on these results - will have the authority to take necessary action to rectify the problem provided they have sufficient time to do something about it. This means they've got to know - in terms they understand (e.g., business terms) - there's a problem in the first place. Fact-based management enables this.

Of course, there might be fear that being the bearer of bad news - e.g., that success isn't guaranteed, that there are risks - might reflect poorly on a manager. In fact, the opposite is true: calling out risk shows you're master of your domain because you're identifying and mitigating delivery risk. Hoping that things magically work themselves out exposes an inability to understand, appreciate and manage success; acknowledging the universe of activity and effort - and subsequently what could go wrong - shows clear understanding of the solution domain. I know the manager to whom I would entrust my investment decisions.

This comes back to the initial intent of this posting. In the above example of piled-on technical tasks of data management and environments issues, there's no specific visibility into what's needs to be done because non-development activity are ghost tasks. In addition to everything else, this creates tremendous tension in the business-IT relationship: "When will you be done" can't be answered authoritatively because there's no authoritative catalogue of what needs to be done and what purpose each serves in delivering business value. Similarly, time spent pursuing things outside of coding drive the business to wonder, "Just what do you spend all your time doing?"

These are diffused with fact-based management; fact-based management inherantly requires acknowledgement that nothing happens in zero time.

Responsiveness is more than Efficiency

Being efficient - eliminating waste - does not inherantly make one more effective in responding to changes in the business environment. It certainly engenders responsiveness: since I have a more precise sense of where I'm at, I can more precisely determine what and when I can implement a reaction. But there's a difference in (a) being able to respond and (b) being aware of the need to respond and formulating an appropriate response. The latter part - awareness and solution shaping - allows an organisation to effectively capitalize on operational responsiveness.

To be responsive to our environment, we need a high degree of "situational awareness." This means we need to be very aggressive in looking outward, developing an opportunity radar and knowing how to read / interpret / shape / prioritize what it tells us. Efficiency is, by definition, inward looking: all well and good making those Model Ts for pennies until you determine that the market doesn't want to buy Model Ts any more.

To mature our situational awareness, we need to focus on business requirements management. (Of course, arguably we're not generally very good at managing requirements, but for now, let's focus on our aspiration.) There's an ideal state of Agile maturity where requirements are captured as expressions of business functionality that provide value, with each requirement globally stored and prioritized (and re-assessed) in near-real-time. If we have transparency of operations and integrity of completion supplementing well-formed and prioritized requirements, we're not only looking outward but we have aligned the entire organisation - not just development, not just IT - in so doing.

This uniformity is important. It doesn't take much to make a development team hyper-efficient, at least relative to it's peers in just about any silo'd organisation. This is every bit as much disruptive (if not moreso) than having an inefficient delivery organisation, only now you create a queue of unused functionality: feedback loops lose timeliness, organisational memory is malformed or lost as people move or simply leave. This, in turn, simply relocates the organisational (stationary) inerta and organisational waste by creating a stockpile of largely unused capital assets.

In sum, a hyper-efficient development capability buys nothing if you don't have the business capability to properly consume it: it's not sustainable, it's disruptive, it's wasteful. It's also potentially damaging: being hyper-efficient without situational awareness makes you an over-caffinated, high-strung, hypersensitive development shop with a massive inferiority complex in a destructive relationship with your customer/business partner.

So efficiency is a goal, but let's not lose the wood for the trees. How requirements are shaped, communicated and prioritsed provides IT a critical external view that operational efficiency alone does not. Effective requirements management enables you to do more than just respond, it matures your situational awareness, letting you to take informed decisions about what and how to respond. It also brings the business and IT into the same structure of execution, creating alignment and partnership (as opposed to a subservient relationship of one to the other) in a social system of peers. That, in turn, engenders organisational cadence.

Fact-Based Management

We should be able to draw a line from delivery execution - development, implementation, infrastructure, operations - through project, programme and department level reporting. We can only do this if work being performed is properly encapsulated, trace-able and prioritized, and if the state of work (complete or incomplete) is substantially a statement of fact, as opposed to opinion.

This latter point is critical. In fact-based management, we tighten the relationship between execution and tracking by emphasizing integrity of completion. While there is still the chance of reporting the state of work as complete when in fact it is not, the probability of doing so is much lower.

In software development integrity of completion is achieved through automated testing, continuous integration, pairing and collaboration. Combined with iterative tracking, we achieve a high degree of transparency. These core practices are synergistic and reinforcing. The lack of attention to one reduces the synergistic benefits.

Fact-based planning - bringing the 4 core variables (time, people/resources, features and quality) into balance - aligns strategy with reality. It is both more transparent and highly adaptive; by definition it engenders responsiveness to changes in the business environment. This has the dual benefit of:

• reducing organizational inertia of long-running, long-return investments for which sunk costs are substituted for business case compliance; and


• reducing the uncertainty principle in business - by knowing to a greater degree of accuracy where we're at, we can take better, more confident decisions about where we're going.

The management anti-patterns - that is, when execution and management are unaligned - become similarly obvious:

• We do not engage in opinion-based planning. Asserting that things will be completed by a certain date through an exercise of top-down planning doesn't give sufficient respect to the domain and the changes it can (and most likely will) introduce. It also tends to ignore the fact that nothing happens in zero time. While this might qualify as a form of prayer, it is not management.


• We do not forego the practices that create integrity of completion in pursuit of declaring something completed. Asserting that something is "done" without subjecting it to the scruitiny of review in combination with technical and requirements testing framework mortgages the future, increasing the liklihood that we create a brownfield that will have to be remediated at a later date.

In sum, aligning execution with management creates an environment where there are no passengers in delivery. All parties own, are aligned with, and are driving to the plan, and all parties benefit from transparency.

And we don't go in mad pursuit of cramming 10 lbs of stuff into a 5 lb bag.

The Agile Manager.Init()

agile (lowercase-a)
adjective
1. Being responsive to changes in the business environment.

Agile (capital-A)
proper noun
1. An umbrella term for a collection of related methodologies including Scrum, Crystal, and Extreme Programming
2. The disciplined execution of a set of best practices in software development.

I'm creating this blog to encourage discussion of management practices that engender or inhibit responsiveness to changes in the business environment. The content will be substantially from an IT perspective, with the realization that the business environment neither begins nor ends with IT.