Friday, 22 January 2010

An Agile Enterprise

What is an Agile enterprise?  How would you recognise one, if you walked in through it's front door?

When we at Cornwell discuss the agile enterprise, we all have an instinctive feel for the Agile enterprise.  The Agile enterprise should respond quickly to changes in it's circumstances, from whatever direction, whether from customers, legislators, suppliers, partners.  It should always be moving forward, at every level.  Every operation, every process, every service, every employee, should all be focussed on value for the customer.  But what enables some enterprises to be agile, and survive and thrive, while others struggle and fail?

Is it about having the right processes?  Is it being able to change processes quickly?  Is it recruiting the right people?  Is it the training you give the people?  Is it devolving responsibility?  Is it setting the right direction? Is it corporate values?  Is it having contingency plans?

Are humans not inherently agile - is agility not a summation of what raised us above the other species, our ability to adapt, to innovate?  Looking at the Winter Olympics, maybe its like skiing?  In skiing, the quickest route down the mountain is straight down the fall line; taking turns just slows you down, the fastest skiers do less but take the right line. The more you try to do, the slower you go, which for some skiers of a certain age and ability is comforting.  So, is it the case that the more we manage people, the more we stop them being agile, and the worse they, and our enterprises, perform?  "Just let me get on with my job!"

But large enterprises, such as governments and multinationals, don't run themselves - they need organising, they need to comply with the law and regulation. Any change, whether setting up the enterprise, or setting up a new team, needs management to lead, to give direction, to drive the change through.  Even in a steady state, take away management and organisation, and chaos erupts, sooner or later.  Today, enterprises are in a contant state of change.  Managers are having to manage multiple, diverse intiatives.  There isn't the managerial time, or resource, for micro management. Light touch is a necessity, the current reality.  Successful enterprises have to empower, delegate,

Going back to the questions I asked at the top of the blog, I suspect the answer is "all of the above".  I can't find a lot of robust scientific analysis of agility in the corporate domain - help, please?  For our enterprises to perform well, our people need to perform well.  People, individually and collectively, perform best when faced with a clearly defined challenge, with the resources and tools necessary to rise to the challenge.
So is our challenge in making our enterprises Agile the challenge of giving our people Agile challenges, and giving them Agile resources?
Posted by at 18:54

4 comments:

  1. RJ RobinsonMay 18, 2010 11:15 AM
    In my experience a crucial precondition for achieving agility is a certain level of maturity. Agility presupposes the presence of quite a wide range of highly standardised core mechanisms of which the agile operations can take advantage.

    The classic example, familiar from IT development (whence agility sprang, of course) is test automation. Without this the development team is unlikely to be able check its day’s labours swiftly enough to move on confidently the next day. But test automation itself can only be adopted by an organisation that already has standardised test classes, a well established test process, a clear understanding of the basic mechanisms of test scripting, and so on. Without all of these (and much more), test automation will fall flat on its face – becoming either ineffectual or rigid – and quickly start to turn agility into paralysis.

    Of course, in a vey small, simple project or activity, the preconditions for agility are very limited. But in a more complex situation, such as BAU operations or a large-scale programme, agility can be achieved, but only ensuring that a full ‘agile environment’ is also in place. The elements of this environment can themselves be agile, but they certainly must be present and specifically geared to allowing other areas to take them completely for granted – it is, after all, the most basic basis of agility that the would-be agile activity can either omit or take for granted that everything in their environment.

    Hence one of the key tasks – perhaps the single most important – when implementing agile methods is to investigate what the organisation’s ways of working can offer to the agile area – and what they demand from it too.
    ReplyDelete
  2. Jim CuthbertMay 19, 2010 02:34 AM
    Your comments reflect one of our central findings, that agile is not an easy option. You have to get a lot of stuff right to do agile software at an enterprise scale. To present a good Agile software service to the business, the swan has to be paddling very hard. The benefits of agile come from reduced risk of failure and better, and earlier outcomes/benefits.

    Nevertheless, I will return to the hypothesis of this particular blog, that people are agile, and we should try not to inhibit their agility by imposing rigid structures, giving them more obstacles to work around. Again, easier said than done. The banks have proved to our great expense, that empowered management without appropriate constraining values, and clear direction, can/will lead to undesired outcomes.

    Any Agile change programme is faced with starting from here (rather than "I wouldn't start from here"). It is not reasonable to expect a fully formed agile ready organisation. Part of the early analysis as you suggest must include a readiness review of people, processes, and culture - standard change management practice, not to be neglected in agile. Any plan of action must be designed to accommodate the state of the organisation, not just in IT, but in the main business, to understand the decision making and management/delegation models in target areas of the business.
    ReplyDelete
  3. RJ RobinsonMay 19, 2010 03:30 AM
    Hi Jim

    I could not agree more, especially about the difficulty of putting Agile across to the business. Some years ago I implemented DSDM (then the preferred flavour of Agile) at Churchill Insurance. As far as the core processes were concerned, there was no great difficulty, but the business was a problem for two key reasons.

    The first was allowing their representatives on the project enough authority to approve of what was going on on the spot (e.g., prototypes, changes, reprioritisations, etc.), without constantly referring to senor management. The second was getting the required effort from their representatives – they were necessarily very experienced and valuable people (who else would you empower?) but that was precisely what made them hard to backfill in their day jobs. So they needed to spend about three days a week on the change project, but also five (usually very long) days on their BAU work.

    So although the business was keen on an Agile approach, they could not participate effectively. It was a long struggle – only partially successful – to deal with this problem.
    ReplyDelete
  4. Jim CuthbertMay 27, 2010 06:45 AM
    Another comment that I saw recently occurs to me.
    Al Goerner of ValTech said in a presentation (http://www.slideshare.net/stephenellliott/agile-e-business-valtech-agile-edge-london-march-2010-al-goerner, slide 2), "An Agile team in an non-Agile environment will not long survive. Development Agility & Business Agility go Hand in Hand."
    The evidence to support this observation comes from the number of organisations who have attempted to adopt Agile development, done the first couple of pilots, then run out of steam, and eventually given up.
    Unless there is a parallel cultural/management shift in the host organisation, Agile cannot fight perpetually the odds. The pilot projects must be accompanied by an engagement with the management to manage IT and change using Agile values, and practices.
    ReplyDelete

Subscribe to: Post Comments (Atom)