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.