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:
- Tools and infrastructure create an intuitive platform for robust exchange of rich content in structured ways
- Participation and individual contribution to this community is recognized, facilitated and rewarded through HR and corporate policy
- Community management links participants, bridges groups and manages content
- Global resource management gives people across the organisation participation and therefore visibility into different projects and opportunities
- 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:
- Requirements are decoupled, with needs captured as independent, complete and valuable statements of business functionality
- Continuous planning, estimation and execution happen in fixed iterations of 1 to 3 weeks, with the measure of time serving as the project “currency”
- There is a deployable, functional deliverable at the conclusion of each iteration; integrity of completion is stressed in favour of feature pile-on
- Teams establish a cadence – daily, weekly, monthly, quarterly – of frequent, low-ceremony, highly-focused communication events
- 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
- The business partner is engaged in business terms, not IT terms, and is involved in day-to-day decisions and activities
- Simplicity of design and well-defined services are preferred over big up-front design or coarsely- or finely- grained functions.
- 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.
- 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:
- 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
- The economic impact of the Innovation Network on individual projects and the organization is assessed and publicised with indicators, metrics and measures
- There must be a discipline of compliance – legal, technical and economic – of all IP released to the Community; this discipline must be non-invasive
- The development of solutions from raw, unfinished ideas in the Community is facilitated by an investment framework
- 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.
Labels: Innovation
¶ 1:19 AM
