Corporate Mental Health

In the course of implementing Agile practices, an organisation is likely to come face to face with deficiencies in both IT and business operations. Shortcomings in specifications, in quality, in team capability, in technologies all quickly come to the fore. Agile practices allow us to not only identify these shortcomings, but to call them out in a fact-based manner.¹ Still, how people in an organisation respond when presented with these will determine how successfully it adopts Agile practices.

While in theory, decision-making in a business context is coldly rational, decisions made by people in business usually are not. Because they impact people, business decisions – especially where performance or results are concerned – can be highly emotional. With regard to adopting Agile practices, this creates an important consideration. While they lend themselves to tremendous transparency, that transparency can unintentionally create discomfort and embarrassment. One person's "liberation" is another person's "fear."

The reaction to this increased transparency is very much an organisational characteristic. In the November-December 2006 edition of World Business, James Bellini writes:

• Businesses behave like people… the nature of this behaviour gives us vital clues as to the condition of a company’s underlying psychological state and in so doing helps us identify those that will succeed and those doomed to fail. It also offers the means by which those confronting failure because of an ailing, dysfunctional psyche can be given a new direction, towards revival and profitability.²

Mr. Bellini makes the point that organisations can fail because they fool themselves into believing something to be true, no matter the facts. There is an important alert here for those wanting to inject Agile practices: organisational self-delusion can be an obstacle to injecting fact-based management. Clearly, we’ll struggle to inject facts if facts don’t have currency. More constructively, there is clearly a “healthy” approach to presenting facts, as opposed to an “unhealthy” approach of confronting with facts.

The business sponsor and implementers of an Agile “programme of change” must be able to honestly assess the following:

• How well do people understand and accept the problems the organisation faces today? Do they see, for example, a deficiency in scalability materially impacts bottom line profitability? Do they see long development cycle times as interfereing with customer responsiveness and, therefore, new business? Do they look for and recognize features in competitive products as disadvantage in the market? Or is the prevailing attitude that the company have its customers, and the competition have its customers, and it will just sort itself out in the end?
  
• To what extent do people tolerate and encourage risk, and to what extent can the organisation accept fast failures? The initial adoption of Agile involves a lot of experimentation, trial-and-error, learning-by-doing, and failure. Is the organisation risk-averse with a “shoot the messenger” culture when things don’t quite turn out as planned? Or is there a recognition of the benefit to continuous learning and “fast failures.”³ Specifically, is there an expectation that people are in "stretch roles" learning and honing their capabilities as individuals? Is there greater infrastructure - training, mentoring, coaching - to support this?
  
• Is there a culture of responsibility or a culture of blame? Exposing problems will make people react, one way or another. For example, many companies are burdened with highly manual processes. Staff changes through resignation or promotion disrupt these processes. Do people accept the natural turbulence of transition and look for constructive ways to create more durable solutions? Or do they simply pass around blame for work not done?
  
• Finally, with what discipline do we take project sponsorship decisions? That is, how disciplined is our project portfolio management? Can we accept a project’s actual cost, time and trajectory in the context of a business case, and take necessary action? Do we accept reporting the actual state of a project as an expression of mastery of our profession? Or are go/no-go decisions substantially rooted in non-business factors, the team's credibility intertwined wth a delivery commitment, and hope the fundamental strategy for a project to maintain course?

Further complicating matters, each of these are bi-directional. The manner in which we expose problems – confrontational or progressive – will contribute to the success of the programme of change. That is, there must be a constructive, as opposed to a destructive, language for change. The responsibility for creating this positive nomenclature lies with the instigator of change.

Collectively, this sounds "soft," and perhaps it is. But at the end of the day, management is still “getting things done through people.” Not money, not technology, but people. We understand intuitively that these things matter, whether we can measure them or not. “Soft” or otherwise, they are relevant to us as managers. And references abound.⁴

The first example comes from Ford Motor's recently initiated turnaround. A recent story in the Wall Street Journal pointed out that Alan Mullaley, CEO of Ford Motor, openly applauded a division head for owning up to poor performance in a senior staff meeting. Mr. Mullaly’s reasoning? You can’t solve problems if you don’t acknowledge them, and not enough people were acknowleding them when Mr. Mullaley arrived. Something to think about in this example, too: if this is what's happening at the most senior levels of the company, what makes us think it will be any different within a project team?

The second example is Scuderia Ferrari F1. In an interview with F1 Racing Magazine, Ross Brawn, the recently retired technical chief at Ferrari, described team decision-making as:

• "Every last detail is critical… You cannot be weak in the tangibles, like the design of the car, and you cannot be weak in the intangibles, like your … interpretation of the rules. Whatever you felt you could achieve you’ve then got ot go out and find another 10 per cent…. We all knew that we had to do it and we knew the other guys were doing it, so that if you were not doing it you would be letting the side down. It was great to be a part of that mind-set; a group where we were all giving absolutely everything."⁵

Albeit extreme, there is a lot to be gleaned from this as an instantiation of organisational psyche. The cultural norms, the expectations of the peer group, while soft, are unambiguous: push yourself to the limit to push the platform (e.g., the car) to the limit. Leaving the potential for competitive advantage on the table due to lack of effort was unacceptable.

Clearly, Scuderia Ferrari is an organisation that deals in facts, not excuses or justification. Somebody will ask as a matter of fact, and not accusation: did we perform every combination of performance and reliability test? Are we in compliance with the sporting rules of the FIA? You don’t want to be the person called out for not answering those questions to their fullest; the organisational psyche guides you to fully pursue these answers prior to facing the questions.

The bottom line: organsational “psyche” is a factor in our ability to change and respond. Ultimately, it impacts our fundamental ability to compete. Mr. Brawn: “'It’s very rare in modern F1 to come up with a dramatic new concept or idea that will give you a step change in performance. So you cannot give anything away.'”⁶ This is not accidental, but systematic, part of the landscape. It might initially read a defensive tactic, but it’s very much an offensive strategy. Thoroughness means we don’t leave anything on the table; aggressiveness means we find and maximize innovation. That makes an organisation able to accept the need for change, and implement that change. And that makes it more competitive.

¹I am indebted to David Pattinson on this point. In the course of an engagement some years ago, he very specifically made the point that we hadn’t established a basis of fact for an issue, and we risked escalating a problem to a client “as a matter of opinion and not as a matter of fact.”
²Bellini, James. “Disguises and denial” World Business, November-December 2006. There’s a lot of information in his article, it’s worth re-reading a few times to get the full extent of his messages.
³It’s worth mentioning that Gartner has called out “fast failures” as a principle for effective innovation: “Fail Fast for More Effecitve Innovation.” Gartner Research. 1 March 2006.
⁴Oddly, and hopefully coincidentally, both are automotive.
⁵Allen, James. “Ciao for Now, Ross.” F1 Racing, January 2007. There’s a full quote from Mr. Brawn that truly captures the essence of Ferrari’s F1 team. Go buy the magazine.
⁶Ibid.

An "Innovation Maturity Model?"

Our innovation model now has multiple practices within each of three dimensions. Collectively, it looks like this:

Agility
Requirements
Responsiveness
Collaboration
Delivery Assurance
Testing
Build
Source Code Management
Collective Code Ownership
Architecture

Community
Tools & Infrastructure
Community Management
Participation
Bar Lifting
Risk Tolerance

Governance
Continuous Sourcing
Metrics
Compliance
Investment
Commercials

We can make this model still more finely grained by identifying the ways in which each practice area is performed. For example, we can define different ways to fulfill the Governance practice of “commercials and contracts.” By sequencing in degree order the extent to which each method of execution enables innovation, we can create a simple innovation “maturity model.”

This is, clearly, going to be a bit involved, but it gives us useful information. The extent to which the different practices are performed will be a strong indicator of our organisation’s aptitude for innovation. In addition, having a “maturity flight” for each will highlight strengths and deficiencies in how we operate now. This, in turn, allows us to focus our efforts and investments specifically where it will make us more competitive.

In constructing progressions of practice in rank order by the extent to which they facilitate innovation, we start with a simple taxonomy of “innovation maturity.”

Level 3: Practices that are fully aligned with and engender innovation

Level 2: Practices that engender but do not maximize innovation

Level 1: Practices that are neutral or marginally enable innovation

Level -1: Practices that inhibit consistent innovation

Having a “Level -1” is useful from the point of view that there is value in calling out practices that inhibit innovation. A Level 3 might be thought of as a maximum degree of facilitation. Between are varying degrees to which things are done that engender innovation but are suboptimal in a purely “innovation” context. This is not to say that Level 3 should be the target: there may be economic or operational reality why an organization peaks at level 2 or 1. This is also not to say that there are not levels beyond 3, but for purposes of constructing an initial model, it is best to keep it simple. Bear in mind that this is simply a model that provides us a structured way to analyse what we’re doing now and suggest what we should be doing instead.

With a taxonomy, and a series of practices, we should be able to construct a “maturity flight” for each practice, sequencing activity in degree order to which each engenders innovation.

For example, the “maturity flight” of the Compliance dimension of Governance might look like this:

Level 3: Compliance rules are automated and implemented as gatekeeper events in daily activity (e.g., through build) and feed a compliance dashboard

Level 2: Key success factors for solution completeness (security, performance, reliability) implemented as a battery of repeatable test suites

Level 1: Multi-disciplinary compliance working group formed with delivery leaders to articulate “solution completeness” in plain terms

Level -1: After-the-fact audit and review intended to find errors as opposed to guide solutions; rules set by non-delivery staff; rules exist in documentation

Similarly, within Community, the Participation flight might look like this:

Level 3: Programmes established to recognize and enable participation (e.g., a 10% scheme, internally funded conferences)

Level 2: Communities fo Practices form; practice membership recognized by HR as a soft “matrix” organization; soft budget allocated

Level 1: Collaboration tools and space passively advertised; demand-based “at-will” participation

Level -1: Teams work in isolation; collaboration is a function of individual networking

And so on, for all practices.

By doing this for every practice area, it becomes possible for us to:

Identify specifically the deficiencies and obstacles to our ability to innovate,

Map the affinity that we have for innovation.

Track our progress as we improve our ability to innovate.

Of course, with as many as 19 practice areas identified, this is going to produce a lot of data.As we have an index and a categorization for each, we can consolidate our scores and get an overall assessment of our Agility, Community and Governance practices.

In so doing, we have a composite picture of where we’re at relative to where we’d like to be relative to an “ideal state.” Again, we have to use this judiciously: this is not intended as a certification or a mandate. It is an indicator that, properly applied, should allow us to better ask and answer: to what extent does our organisation really do the things that lend themselves to innovation? We cannot expect innovation from an environment that is not conducive to it. This degree of insight goes a long way to avoiding a futile “innovation mandate.”

Aligning for Innovation

It’s worth looking more closely at each of the factors that enable innovation within an organisation: Agility, Community and Governance. Each of these means something specific. If we identify practices within each that affect our aptitude for innovation, we have something more concrete than “IT Governance, Community and Agility contribute to our ability to innovate.”

By taking a structured approach to critically examine how work is performed, we get unvarnished insight into how we do things today.
In so doing, we are more likely to align organisational objectives – efficiency through re-use, creativity from collaboration – with day-to-day work. This gives us an indication of the extent to which we have an aptitude for innovation. As a result, a focus on innovation is less of a hope-based initiative, and more of a fact-based exercise.

That said, if we are to critically look at things we do to facilitate – or, for that matter, stifle – innovation, we first must understand in greater detail the elements of Agility, Community and Governance.

Practices that Create Community

An innovation culture requires a Community that extends beyond any individual's immediate team or department visibility. The dimensions of forming Community include the following:

1. Tools and infrastructure create an intuitive platform for robust exchange of rich content in structured ways


2. Participation and individual contribution to this community is recognized, facilitated and rewarded through HR and corporate policy


3. Community management links participants, bridges groups and manages content


4. Global resource management gives people across the organisation participation and therefore visibility into different projects and opportunities


5. The organisation develops a culture that values and rewards continuous learning and fast failures.

Practices that create a Static Cost of Change

We also recognise that the cost of change – that is, the extent to which we are able to accommodate change with minimum disruption – is a contributing factor to our ability to produce and consume ideas and code.
Traditional ways of working have an exponential cost of change: design decisions, taken in early stages of a project, have long horizons. It becomes increasingly expensive to change course as we get further into a project as code is highly coupled to this set of decisions.

Agile practices have been shown to yield a more static cost of change. Decision horizons are shorter because decisions – requirements, architecture, code – are much more independent. Agile practices include the following:

1. Requirements are decoupled, with needs captured as independent, complete and valuable statements of business functionality


2. Continuous planning, estimation and execution happen in fixed iterations of 1 to 3 weeks, with the measure of time serving as the project “currency”


3. There is a deployable, functional deliverable at the conclusion of each iteration; integrity of completion is stressed in favour of feature pile-on


4. Teams establish a cadence – daily, weekly, monthly, quarterly – of frequent, low-ceremony, highly-focused communication events


5. A continuous cycle of requirements analysis, development, integration and test prevents a team from mortgaging its future, borrowing blindly against a future time-box to accommodate change


6. The business partner is engaged in business terms, not IT terms, and is involved in day-to-day decisions and activities


7. Simplicity of design and well-defined services are preferred over big up-front design or coarsely- or finely- grained functions.


8. Robust testing – in the form of programmer-written unit tests and QA-written functional tests – in conjunction with continuous integration, makes “development complete” less a matter of opinion, and more a matter of fact.


9. Teams report status and forecast completion in unambiguous terms to all project stakeholders

For purposes of critically analysing our day-to-day practices we will look at these a bit differently, but for now this list allows us to understand in context how we deliver – and how we would like to deliver – IT solutions.

Practices of IT Governance

Finally, innovations must not be a matter of opinion, but a matter of fact: do they deliver value for money, and are they delivered to a complete set of expectations. To be able to ask and answer those questions in a context of innovations, we must look at the following:

1. There needs to be a continuous sourcing model so that teams can exploit and contribute to emergent and rapidly evolving code and ideas in the Community


2. The economic impact of the Innovation Network on individual projects and the organization is assessed and publicised with indicators, metrics and measures


3. There must be a discipline of compliance – legal, technical and economic – of all IP released to the Community; this discipline must be non-invasive


4. The development of solutions from raw, unfinished ideas in the Community is facilitated by an investment framework


5. Traditional ways of working to the letter of a contract and suffering under the weight of rigid change controls must give way to commercial contracts that facilitate constant assessment of project variables – quality, time, resources and scope – in pursuit of meeting evolving business.

This is not to say that these practices are mandatory for innovation and we don’t look to these as elements of compliance or certification of an “innovative enterprise.” We do, however, recognise that these are things that systematically and synergistically incite innovation: if we have strong Community, a high degree of responsiveness and mature Governance we will be more inclined to innovate than if we have a weak community, long-term decision lock-in, and limited means by which to oversight IT results and activity.

The Aptitude to Innovate

Growth is back in business; it is the business imperative. Growth is fueled by innovation. And business leadership is looking to IT for innovation.

That’s good for IT. Think about where we’ve come as an industry:

10 years ago, IT was part of the business.

8 years ago, IT was going to reinvent the business.

5 years ago, the business wanted to get rid of IT.

3 years ago, the business accepted IT as a tolerated nuisance, but it kept it on a tight leash.

To be asked to be providers of innovation is to be invited back to the top table as business leaders. That’s a good problem to have.

But it’s not an easy problem to solve. Because innovation is neither a managed business function nor an explicit programme of work, it defies traditional management solutions. You can’t manage innovation as you manage sales. A culture of innovation also requires new ways of working, as most organizational structures and norms simply stifle it. Unfortunately, there are also few models or patterns for introducing and inciting innovation. No surprise, then, that 3 out of 4 CEOs think they lack both organizational process and leadership to engender business innovation.¹

The open source phenomenon provides us with one reference model: global communities of people collaborating on common problems to create robust, useful and re-usable solutions to problems. But in a commercial context, the open source model is a point of reference, not a reference implementation: adopting network organization structures is disruptive and potentially disastrous, and these types of structures are orthogonal to corporate cultures and reward systems.

Innovation is not invention. It isn’t the “eureka” moment, or the creation of new products and services out of R&D. It’s the consistent, rapid and deliberate maturation of what we have and do today. It’s evolution, as opposed to revolution. Think Ferrari evolving the F1-2000 platform to win 5 consecutive driver and constructor championships as opposed to BMW.Williams revolutionizing the FW22/3/4/5/6 over the same period (remember the tusks?) only to win the odd Grands Prix.

To be creating and just as importantly consuming innovative solutions in our day to day requires more than simply standing-up a repository for ideas, code and artifacts, and e-mailing a URL soliciting contributions and use. Developing a penchant for innovation requires that we focus on three things: having a static cost of change, building Community, and having a mature IT Governance capability.

Each workgroup, each team, must have a static – as opposed to exponential – cost of change. Traditional ways of working create long decision horizons: decisions made during architecture and design become hard to reverse in coding, testing and deployment. Highly coupled requirements create highly coupled code. Development is opaque. Collectively, this creates a cost of change that grows exponentially. Because everything is so highly coupled, it is difficult to ferret out clever solutions or integrate new ideas without significant disruption. By comparison, Agile practices create short decision horizons. Requirements are independent statements of need, code is decoupled, tested and always in a state of build-readiness. We have transparency in development. This creates a static cost of change, and makes it easy for ideas to be harvested and consumed. Agile practices, then, allow for a consistent supply and demand of ideas and solutions.

Organization – particularly hierarchy – can obfuscate needs and opportunities. To drive out and consume innovation, people must also be part of a Community larger than their immediate work teams or departments. This isn’t endless committee meetings or matrix organization, this is a slow but deliberate process of grafting a network organization model into a company. This is supported by infrastructure and tools, and by aligning Community participation with individual (career) and team (delivery success) goals. This gives us the ability to communicate and collaborate as an organization, across boundaries.

Finally, we need to call out the value of innovation, and define the context and completeness of each. Solutions must be shown to deliver business value, otherwise they’re just interesting ideas that may not be worth investment at this time. They must also be complete in scope, lest the rush toward adopting an idea create a legal, performance or quality problem that creates more harm than good. There must also be an instilled behavior of consistent sourcing, looking outside an immediate team for ideas and contribution. A mature governance capability gives us the ability to oversight and leverage innovation.

Given the increasing rate of change in business, there is an urgency to harvest and capitalize on ideas and IP. Bringing it about is not a top-down exercise in "managing innovation" as much as it’s a corporate competency and cultural phenomenon. Bringing this about happens in stages, and forming an “innovation network” is itself a process of organizational maturation. By deliberately developing capability in Agile process discipline, developing Community and maturing IT Governance, we create an aptitude for innovation and the ecosystem to perpetuate it.

¹ Business Innovation is a Rising IT priority, but is Not Yet Matched by Action, Gartner Research, 10 December 2006.

It might make the car go faster, but does it make the car more competitive?

Frank Williams, the legendary principal of WilliamsF1Team, has a single question he asks of any proposed change or innovation: “Does it make the car go faster.” This is intuitively appealing, especially for Formula1 teams which are in the business of winning races. We can similarly define a “litmus test” for business decisions: does any given project, initiative or decision make more money for the business?

While it’s great to have an over-riding sense of priority, this isn’t sufficient. We can engineer a car that will sit on pole and lead the race, but if the engine melts or the suspension buckles or the wings fall off after 20 laps, being fast simply isn’t enough. In Formula 1, reliability is just as important as speed for winning races. And the results reflect this: in the November 2006 issue, F1 Racing magazine published an analysis of race results between 2000 and 2006.¹ They concluded that Kimi Räikkönen lost two F1 driver’s championships because of reliability problems of his Mclaren-Mercedes; all other things being equal, in 2003 and again in 2005, mechanical retirements cost Kimi a championship. Clearly, going fast is important, but going fast while meeting requirements for quality is another.

The “it makes the car go faster” question is the classic “they get results” statement in consuming business services or solutions. Simply making the car “go faster” at best assumes things are in compliance with expectations (regulatory, quality, security, etc.), at worst dismisses if not outright ignores the importance of these issues relative simply to achieving bottom-line results. In F1, it is important to say that teams are not in the business of “speed,” but of “winning races.” This latter definition is far more inclusive, providing more comprehensive consideration for what it takes to succeed given operating realities.

Just as the FIA is increasing regulation, businesses are subjected to both increasing regulation and expectation (e.g., “is consumer data is secure”). This will affect our business “litmus test:” we can do things that drive revenue or increase profitability, but at what cost to our competitiveness relative to the business environment in which we operate? For example, we can produce a new consumer website to drive revenue, but if there’s a 90% chance of identity theft resulting from its use, the solution is a failure. Similarly, we can cut salaries 10%, but if turnover jumps to 50%, we will have a long-term cost problem. To be competitive, then, in business, just as in F1, we must have a more complete definition of “competitiveness” than simply, “does it make us more money.”

Carrying on with the F1 example, suppose that the FIA changes regulations so that engines must be more “green,” or consume less energy. Should this happen, the question “does it make the car go faster” must be considered with not just reliability but emission constraints, giving us a multi-dimensional problem. Success in this environment is far more difficult than simply “going really fast.”

It is important that we use the word “constraints” as opposed to “considerations” to describe the environment. “Constraints” promotes the value of one dimension over others, in this case “speed” over “reliability” and “emissions.” Emissions and reliability can only lose the race for us (e.g., by being in clear violation of sporting regulations and being disqualified, or by retiring from the race due to insufficient tolerance to stress), whereas speed can win the race for us by putting us, and keeping us, at the front of the grid.

The business imperative, then, regardless of what it means to have a “complete solution” remains the same: we’re in business to make money, not to comply with regulations. However, we respect the fact that we must comply with the regulations, expectations and constraints of the business environment and we place value in our capability to manage in the complete definition of our environment. We therefore want simple yet consistent models through which we can expose, analyze, and improve that which we do such that we maximize results given constraints of our operating environment.

This is why IT governance is such an important capability: it gives us greater mastery over our selves, our environment and how we interact with our environment. To that end, the equivalent question we must ask is “does it make the car more competitive.” This is less appealing as it lacks the precision, exactness and simplicity of “does it make the car go faster.” It also makes our objective a bit more vague, with “regulation” and “expectation” soft qualifiers that introduce opinion into our assessments of “compliance with expectations.” But it is a more accurate definition of success.

And therein lies the governance gap. We’re not especially good at governance now. For one thing, our bias is toward the appearance of results (delivering something under budget, getting something in production, steering systems through transactional acceptance, etc.) over solution completeness. For another, day after day we deal with the self-inflicted wounds of security violations, spiraling maintenance costs, production failures, and so forth. The intensity of the competitive environment – both regulatory and expectation – is only going to increase. We need greater mastery over not just what but how we do such that we’re aware of and developing our capabilities, and actually delivering, complete solutions.

An improved governance capability has the following characteristics:

• We balance our results orientation with a genuine concern for the means by which those results are achieved.
  
• We embrace a governance model that gives a comprehensive definition of “complete solution” the peer status – but not disproportionate priority – relative to “bottom line results.”
  
• We have the capability to answer both “effectiveness” and “completeness” questions such that governance is far more a matter of fact than opinion.
  
• We do the things necessary so that the team can put itself and the car (e.g., the business) on the limit without self-inflicting failure in the form of disqualification or inadequacy.
  
• We recognize that our ability to govern, as well as our ability to execute, are each maturing aspects of our collective capability; we execute to both as means by which to continuously improve and, therefore, maximize profitability given a changing operating environment.

By so doing, we constantly improve our execution and awareness of our execution, and sharpen our focus in pursuit of what matters most: not running the fastest race we can, but winning the race.

And that’s why we’re in business.


¹ The race results analysis appears in the “Looking Back in Anger” column of the Pitpass section of the November 2006 edition of F1 Racing magazine. F1 Racing consistently presents as complete a picture of an industry as you’ll find anywhere, including driver, engineering, supplier, regulatory and management dimensions. They communicate in a matter-of-fact writing style supplemented with unbelievable photographic images. If you have even a passing interest in F1, read a few editions and abstract the lessons learned, you’ll find a take-away for your business or industry.

The Leading Indicator of IT Relevance

An article in the 16-22 edition of BRW magazine by David James entitled “Listen and Earn” reports on research by Mark Ritson, an associate professor at the Melbourne Business School. His research shows a high degree of correlation (70%+) between customer loyalty and revenue growth. Specifically, the more positive customers are about a company or product to would-be customers, the greater the growth; similarly, the more negative they are, the lower the growth. It is, according to Dr. Ritson, twice as accurate as the next best measure.¹

This is unambiguous guidance for business executives and managers, especially relevant at a time when growth is the business imperative.² We can apply the same rule and draw similarly powerful conclusions for IT.

Whilst businesses are growing, IT budgets aren’t keeping pace. Gartner Research reports that on average, IT budgets lag revenue growth by about 61%; it’s as high as 63% in financial services.² Just as the bottom line number lags, so do the satisfaction indicators: Gartner goes on to report that 60% of CEOs see IT as an inhibitor of business imperatives², and Forrester Research reports the same number of business sponsors of IT projects are dissatisfied with fitness or timeliness of solutions delivered.³

If we interpret IT budgets as IT's revenue, it comes as no surprise that they’re lagging: business dissatisfaction with IT will reduce the enthusiasm to spend. Budget size is not the goal of IT; it is, however, an indicator of how relevant IT is to the business. If it is to move away from being perceived as a “tolerated nuisance” of doing business in this day and age, IT must be a driver of breakaway solutions, the things that create substantial market advantage or process efficiency for the business. IT won’t drive these unless solution satisfaction comes into alignment, bringing with it an increase in confidence in the capability of IT.

To have this information, we need the data. Fortunately, collecting custsat data need not be invasive or high ceremony: an 8 to 10 question survey consistently proctored (e.g., quarterly) will provide sufficient, frequent data. And, experience shows that what gets measured is what gets managed, meaning there is quick impact: although making the data visible early on causes some heartache, the numbers tend to trend upward because of their visibility.

This, then, makes the case for having customer satisfaction as a component of IT governance, not only because it is integral to answering the second governance question, “are solutions being delivered in accordance with expectations,” but specifically because it is a forward-looking indicator of IT’s relevance to the business.



¹ I highly recommend reading the full article in the 16-22 November issue of BRW magazine, it’s worth the AU$3.30.
² Gartner has produced a number of research reports in this area, including “IT Spending Lags Behind Revenue Growth in Most Industries” in August 2006 and “What’s on the Minds of CEOs and the Implications for IT” on 17 January 2005
³ From Forrester’s 2005 United States Technology User Benchmark Study.

The Governance Gap

The demand (and need) for IT governance is increasing faster than the discipline is maturing. Core to the problem is that there is no concensus as to what is meant by "governance" in an IT context. If anything, there is outright confusion, evidenced by the polyglot of consulting and services and the number of project management products being positioned as governance "solutions." This, in turn, means there are few coherant approaches (let alone solutions) to satisfy the need.

In and of itself this isn't a problem: that governance needs to be highly tailored to an IT organisation is simply an indication of practice immaturity. But there is a significant downside: practice immaturity means an absence of best practices and a high rate of solution mis-fit. This can be seen in many current IT governance structures. Often little more than large, cumbersome reporting exercises grafted on top of operations, they relying on poorly-modeled data-gathering mechanisms that inadequately interrogate what's actually happening on the ground. Instead of providing "windows on operations," they're CYA exercises that create arms-length relationships between field decision-makers and directors. At their worst, they're inhibitors to productivity and sew seeds of mistrust.

For starters, IT governance needs a clear definition. Fundamentally, IT governance is a results-oriented exercise that can be summed up in one question: what is being achieved, given operating realities (commercial, regulatory, risk, etc.)?

This is a more active than passive definition. Governance is, in fact, an active, engaged, results-oriented discipline. Some would argue that governance is more accurately defined as providing "guidance" to people throughout an organization as to how decisions should be taken and work should be done, but this is an incomplete definition. If it were meant as "guidance" it would be called "guidance." With governance comes responsibility: if bad corporate stewardship can result in criminal penalty, it is, indeed, a results oriented practice. That the obligation of "good governance" carries with it the need to know "how work is being performed" is simply an expansion - but not replacement - of the definition of governance. To wit: SOX requires the CEO and CFO to certify that financial reports reflect reality; that is, the bottom line is what they assert it to be. That the "how" is important to this act of executive certification is an extension of that basic performance-oriented question. IT governance is no different.

The über-question - what has been achieved given operating realities - breaks down into two distinct dimensions:

1. Are we getting value for money? That is, are we maximizing return on our techcnology investment? This allows us to assess the effectiveness of our decisions.
2. Are solutions being delivered in accordance with expectations? That is, are execution and delivery in compliance with corporate policy, be it security, quality, design, etc. This allows us to assess the completeness of our decisions and results.

The first dimension is results-orientated. It's important to note that it's not concerned with the question "are we meeting plan" but "are we getting bang for the buck." IT has traditionally asked this question after-the-fact, measuring results of operations / projects / programmes post-flight, as in-flight reporting is often little more than reporting to plan (and laden with opinion). Post-flight, however, is no longer sufficient: while corporate revenues are rising, cost containment is embedded into corporate culture; a recent report showed IT budgets lagging revenue growth by more than 60%. There really is a need to do more with less, and to do so on a large, organization-wide basis. In addition, the operating environment changes quarterly, monthly, weekly, daily; as a result "meeting plan" can be more destructive than helpful. Finally, it is important to assess which IT investements will yield the greatest business impact going forward. This means the "results" question needs to be asked on an ongoing basis and framed in a portfolio context.

The second dimension is process-oriented, concerned with whether results achieved are consistent with organisational objectives and expectations (that is, are decisions being made with a full scope of consideration.) This dimension - so often the focus of "governance" and so often ignored or outright chided ("what difference does it make how it's done, just that it's done?") - carries equal status to the results question. The "how" question has been the source of the bureaucratic burden of little operational value, the breakdown in the governance programme requiring that monthly "compliance reports" are filled out by teams, rife with survey-borne opinions more than operational fact. The reality is, "how" stuff is done is just as important as "what" is done. If SOX is evidence that this can't be left to trust in accounting and finance, it is not a stretch to say that it can't be left to trust in IT operations, either. Clearly, IT solutions that are vulnerable to security violation or are long-term financial drags on the balance sheet due to architectural flaws are serious matters: jobs are on the line for this stuff. As the stakes are higher - e.g., as the threshold for internal investment into IT projects is increasingly high and under closer scrutiny, as the cost of failing to safeguard information is similarly high, etc. - this can't be ignored.

Formalized governance is coming to IT. If it is imposed from the outside, IT will suffer under the weight of measurement and collection mis-fit, relegating IT to the role of "passenger" in the organization for many years to come. IT has the opportunity to incubate and rapidly professionalize a governance capability, aligning governance with execution through fact-based management that communicates performance not in an IT context, but in a business context. If successful, it will transform IT from being passenger to driver of organizational objectives.

Management Trends in Financial Services Application Development

IT in Financial Services is maturing into a business-value measured and driven capability. To meet demands for both rapid business innovation and high quality, it is moving toward highly disciplined, low ceremony processes that give responsibility and ownership as well as enable maximum performance, from highly capable people.

Application development in the more volatile parts of Financial Services is typically characterized as being "on fire" more than it is considered a "centre of excellence." This is accepted as m.o. largely because in these parts of the business, IT has simply ceeded control to the business operations, such as the trading desks of securities firms. Traders, being belligerant, noisy and aggressive, typically call the shots with IT. No doubt, they bring business urgency: millions of dollars (if not more) are on the line with each passing second. However, having ceeded control, IT only manages to the moment, not to an overall capability to manage business urgency. This means a lot of mistakes and rework, subsequently inefficiency and cost, precicely in the parts of the business that would benefit the most from disciplined responsiveness.

Financial Services IT increasingly recognizes that a lot of it's inability to respond is self-inflicted. The drive toward Continuous Integration is an example: how much time is wasted and how much delay is introduced by doing a build by hand, something that's done once a week (if not more frequently) in support of a production or QA release? Build can be transparent, and just about as close to something happening in zero time as you can get in IT. Because it brings a benefit of tremendous quality improvement for relatively little cost of implementing the practices and the tools (CruiseControl being free), there has recently been a signifcant groundswell of adoption in Financial Services development to automated build.

There's three specific management-oriented trends that suggest the ad-hoc, purely reactive activities are giving way to a more controlled, consistent way of working.

An emphasis on structuring, capturing and managing requirements is the first trend. Teams writing trading applications typically have little discipline in requirements definition and management. Priority decisions are off the cuff, meaning a lot of information isn't captured and expectations are simply not met. There is a growing trend toward structurally simple, highly accessible, easily managable and ubiquitously understandable expression of software requirements. This provides a durable communication channel between the business and IT as to what needs to be done, it survives business shocks of priority change and staff turnover, and it does so in a lightweight, non-ceremonial, non-cumbersome way. To that end, a common language and structure for requirements expression - the Story - is beginning to take root, specifically because it effectively communicates the essentials: the role, need, justification and acceptance criteria driving a requirement from a business, not a technical, perspective. That Stories can be managed with open-source repositories such as XPlanner, and that these scale from the team to a global level, make professionalizing requirements capture a low-disruption and high-value-added change.

The pursuit of uniform operational transparency is the second trend. It's increasingly less acceptable to have management by "I feel good about this" and increasingly more important to express the course, speed and direction of a project in a fact-based manner. Short delivery windows (e.g., iterative delivery) coupled with clear business requirements (the prior point) provide a controlled responsiveness to change. Together, what's in, what's not, what's priority and what's bumped are unambiguously communicated; in addition, team performance - of targets exceeded or missed, of capacity in excess or short supply - are factual, exposed and nearly indisputable. Particularly in the most volatile of business environments they provide accuracy of what's actually happening on the ground, both professionalizing delivery management and preventing a team from devolving into a free-for-all. Ultimately, the combination provides a great deal more information as to what everybody is doing for the business. They also uniquely and uniformly scale-up to a programme or a department, giving global status reporting that exposes hotspots and happystates well in advance of delivery dates. This approach to management provides unparalleled transparency: there is true uniformity across and within a large programme of work because it doesn't allow substitution of opinion ("we're about xx% done") for fact ("xx% of requirements are QA complete.") While it takes longer to onboard, the trend toward iterative delivery and status reporting at both project and programme levels is becoming established in Financial Services IT.

Greater rigor in identifying, recruiting and retaining best-and-brightest is the third trend. Financial services companies including investment banks, insurance companies and funds managers are all posting record numbers. Simultaneously, venture capital and angel money are back and bigger than ever, and the overall IT economy is healthier and more structurally sound than it was in the late unpleasantness (2001-2003). This is creating tremendous pressure on IT organizations to recruit and retain the high-performance people who thrive in dense-and-dynamic environments. To this end, financial services companies are increasingly scrutinizing the ways in which they hire, looking to ways to identify not just good executors, but people who (a) understand how to satisfy the requirements of the business doman and, (b) know how to maintain operational discipline so that they're not over-run by the business domain. This requires more than just good coders, analysts and managers; it requires people with high degrees of situational awareness and professionalism. Finding the right people is more than just technical and personality questions, a company must be seen to be a destination employer to attract them, build the screening processes to identify them, and maintain the environment to retain them. The feedback from IT to HR is already affecting recruiting practices, and it will continue to drive it in this direction as demand increases.

Of late, there has been a metrics trend that swept through IT organizations. This has turned out to be not so much a current trend as much as an echo of the future, a foreshadowing of things to come. There's still demand for performance, output and compliance metrics in IT, but the realization is that the call for metrics can't be answered until items 1 and 2 come to fruition. Once portable, consistent and durable requirements capture and fact-based project management have a firm footing, IT will be ready to address metrics again. Reliable metrics will still require integrity of completion (i.e., that every piece of code is certified to functional and technical tests prior to being called complete), but improved analytics and project management will lead the introduction of business-oriented metrics to IT.

The bottom line: Financial Services IT is moving toward low-ceremony, disciplined processes that give autonomy to enable maximum performance from highly capable people. Strength in fundamentals will ultimately allow IT to both measure performance and drive results in business impact terms.

The Pile-On Index

When faced with extreme uncertainty in a problem – where perhaps the only certainty is that the solution will end up bigger than it appears to be today – it’s tempting for a team or its management to be aggressive with workload, to take on stretch goals with the intent of “getting ahead” or “getting on top of the problem.” Because situational uncertainty creates insecurity, the various stakeholders – executives, managers and executors – will seek out certainty of situational control. Just as there will be those who seek control, there will be those willing to feign control.

This is not leadership, and in fact it’s a management anti-pattern. Committing to a solution too soon, or being a “serial committer” of several solution paths over the life of a project, is at best a waste of time and energy, at worst poor stewardship: it often leads to instability (e.g., team burn-out, staff turnover), high operating costs, poor performance, and no results. It is also bad management: when faced with a high degree of problem uncertainty, it will be impossible to know how much progress is actually being made toward creating a solution. Aggressive pursuit of completion is, therefore, pointless.

This can be called out by indexing the degree to which work “piles-on” a project. This can be expressed as the sum of work in hangover (that is, work that is signed-up for but not completed in the time-box) plus the expansion of scope over the same time period (new requirements or depth of understanding which increases work estimates.) “Pile-on” has a compounding effect: teams have memory; with each passing iteration of goals not achieved and discovery of new work, the team appears to never get “on top of” the problem. The project appears to be under-achieving and therefore losing more ground to an ever-expanding solution definition.

We can get a sense for the effect of this by plotting a “pile-on” index.

Consider a team working in a highly volatile domain, such as an R&D exercise. In these situations it is difficult to establish a well-defined initial shared vision between business and IT, and scope management is difficult as requirements will enter, exit and re-enter the solution domain in very short periods of time. The solution is therefore something of a “moving target.” In this situation, if the team:

• commits above its capacity to delivery (e.g., sets stretch goals)


• delivers to capacity (hits none of its stretch goals)


• experiences scope expansion iteration-on-iteration

It will more rapidly exhibit “work pile-on.”

In this example, while scope is expanding and creating a “scope deficit,” over-committing amplifies the degree to which work is “piling-on” the team. Instead of working at a sustainable pace to better understand the problem domain, the team (by team decision or mandate) is self-inflicting a greater degree of hopelessness. Going in mad pursuit of a “solution” when there is no clear understanding of the “problem” in the first place has the opposite effect of its intent: not only does the team not “turn the corner,” the project gives every appearance of sliding further and further into an abyss.

This is also where team memory comes into play: the final data point, showing up-tick (the last data point), is not itself representative of the corner being turned: a single point is not a trend, the project trendline is still negative. Until that flattens out, work is still trending toward greater “pile-on.”

This index appears to hold outside of this example. Consider two other scenarios:

• Deferred Discovery: a team defers requirements discovery to be completed during the first few iterations of delivery, but commits and executes within its capacity. This might be a situation where scope is more important than time or cost – additional requirements are known to be coming (and are hopefully factored into the release and project plans), cadence and predictability are more important to project success.


• Aggressive: a team working in a requirements domain that is decreasing, making commitments that reflect capacity but delivering slightly ahead of requirements. This might be a situation where the delivery date is more important than scope – in this case, all parties agree to clearly focus on the highest value requirements. Shared vision and scope management are more important to project success.

Using data from representative projects, we can plot the “pile-on” index of all three situations.

The plotlines in the second graph show a relatively neutral “pile-on” index for the aggressive and Deferred Discovery scenarios: both are working to relatively predictable paths. The Aggressive team, trending slightly ahead, is a positive working environment where it is able to track to an early completion. The Deferred Discovery team, working at a predictable pace, may re-define its project time-box (by adding one or two more iterations) to fulfill scope. Both situations are manageable and predictable and demonstrate teams are in control of their solutions. By comparison, the “futility” path (copied from above) shows no mastery of a solution domain, and in fact shows inability to manage in uncertain circumstances.

While working toward an uncertain (and expanding) domain can be frustrating, that frustration is magnified when stretch goals are set or imposed and not met. Feigning control in a situation of tremendous uncertainty creates more harm than good. The better management practice is for a team to acknowledge the situational uncertainty and collectively and incrementally develop a better understanding of both problem and solution. This minimizes frustration and maximizes the energy, creativity and raw bandwidth applied to drive out a solution.

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.