aliando agile IT service management, agile ITSM, Dana Stoll, agiles IT service management
aliando methods for agile IT service management, agile ITSM, Dana Stoll, agiles IT service management
aliando agile IT service management, agile ITSM, Dana Stoll, agiles IT service management
aliando methods for agile IT service management, agile ITSM, Dana Stoll, agiles IT service management
aliando methods for agile IT service management, agile ITSM, Dana Stoll, agiles IT service management

Making Strategy work

In his famous book “Mintzberg on Management” Henry Mintzberg states “Strategies need not be deliberate — they can also emerge, more or less. […] To manage strategy, then, is to craft thought and action, control and learning, stability and change. […] To manage strategy is in the first place mostly to manage stability, not change. (pp. 29-39)”. This has been written already in 1989. In 2004 John Roberts argues, that for volatile environment situations, the famous Chandler’s Dictum, that “structure follows strategy”, has to be reversed (“The modern Firm”, pp. 27-31).

This is important for us to understand how IT startegy emerges, and what is involved:

Thinking in cycles: Understanding agility in IT strategy

In volatile environment situations, strategy will have to be frequently adjusted as the organisation reacts to environmental factors like market conditions, user acceptance, trends and similar. These adjustments, which also include decisions on IT procedures and infrastructure, are the result of decisions and actions which stem from within the organisation. These decisions and actions depend on the structure of an organisation, which has already been put into place, as its members are subject to it. And thus, reversing Chandler’s Dictum, strategy follows structure.

Sounds freaky. But what are the consequences?

Here’s a list of thoughts. This is only valid for environment situations wich involve rapid change, where you usually want to apply agile techniques:

  • It does not make sense to plan and structure your Service architecture or operation platform too far in advance. This is even one of the most dangerous things to do. If you’re doing so, you will influence your perception of the services’ performance, user acceptance, because you’re viewing it through the goggles which you have created by your administative platform. This picture may have nothing to do with what the user or customer perceives, even though figures may show you that you are “right”. There is no right or wrong in perception. On neither side.

  • It also tells us that there is some sort of blurry threshold (I’ll call it “the Threshold”). Strategy seems to emerge as a program on one side, and it seems to be structurable in plans on the other side. This threshold marks the transition from agility to best practice. Deciding upon whether a component should be driven on the agile or the best practice side and setting a constraining corridor for orientation is, what a Strategy Session should be about.

  • It also means, you can start out with just any practice, as long as you’re willing to review it on a regular basis. Only if you can and will make adjustments based on unbiased observations, prioritising customer and user feedback over any other opinion. Even though some people will not like to hear this.

Can you give examples for the dangers of overdoing structure?

Sure. Here are a couple:

  • If you measure your freshly created service in terms of an availability management suite which has already been in place, you are more likely to estimate its performance as poor, the more components you already have which are running fine under best practice. For your mind will always unconsciously compare them.

  • If you are running products from agile development through change boards you will very likely reduce the release cycles far below what market requires. Yet you will perceive the release requirements as chaotic rush.
  • If your network infrastructure in place requires a lot of changes to be executed before a new server or connection can be taken online, you will probably cause more side cost than a feature is actually worth at this point in time. So you’re likely to estimate the return of investment of this service low, where it would possibly be decent if you’d have done it with properly scaled procedures and technology. This again will influence your future investments.

    This is also the reason when sizing the hardware or procedures of a service for too many users at the beginning, you will have one disastrous period of blame where you will get the impression, that the service is nothing but a waste of money. It wouldn’t be, if you’s have begun smaller. Our subconsciousness cannot eliminate these investments, as we perceive the money spent in terms of machine sizing, the number of team members, and many more factors, even if we present calculations where we eliminate those costs, like EBITDA.

  • If your decisions are based on a balanced scorecard system which is already in place, then you are most likely to underestimate anything which didn’t reach a state which you can properly measure it yet. However nowadays almost all champs stem from such conditions. However your organisational decision structure may already prefer cash cows.

  • In complex decision situations you are likely to compare any new feature with experiences you felt comfortable with from the past of your organisation rather than how the market is perceiving them. This is owing to the fact that your decisions reflect your organisation’s memory, which is completely natural. Cyclic development with rapid time to market however needs to have its bubbles, where you can decide independently. Experience is for creating proficiency, not some source of esoteric knowledge.

How can I decide on agile procedures or best practice?

There are several perspectives you can look upon your Service Universe which help you form your opinion:

  • vertically in terms of Services — This means you review your service in Terms of user functionality (or as a whole) if it has reached a stage where you could apply best practice. Indicators may be availabilty figures, user base, ease of applying changes, service lifetime, revenue streams and many more.

  • horizontally in terms of shared capabilities — There can also be layers or components of your Service Universe transitioning to best practice, which are shared among or used by many services. This is typically the case for hosting platforms, operating systems, standardised hardware, company wide shared libraries, communication infrastructure components, your company or hosting network, etc. These components possess high affinity to shift towards best practice. This will help ensure your overall quality of service, but can slow you down if you’re not careful.

Other perspectives can include: software release cycles, achieved service level definitions, revenue streams and many more.

What’s the implication on moving a Service to best practice?

This means that the prerequisites will have to be met for the service to be run under best practice. This will have an impact on release cycles, which will most likely be less frequent. There will be more overhead involved in deciding upon changes. I.e. to gain stability you trade in flexibility.

To put it blank: Whatever you throw over the threshold of best practice will have a high chance to clash with agile development methods.

What are techniques you usually use in agile practice, which you avoid in best practice?

In agile Service Management environments:

  • programmers will usually have administrative access to live servers
  • roll-outs can be decided upon without change advisory boards on an informal basis
  • service levels are being defined in terms of service aspects rather than quality figures
  • Service Owners will do many jobs which are usually done by Service Level Managers, Availability Managers, Capacity Managers and the like
  • comprehensive documentation is almost never available and thus a lot of knowledge will have to be in the minds of people.

How do Strategy Sessions interface with agile development methods?

Part of this is resembled by the review and retrospective meetings, so they are welcome occasions to link them to Strategy Sessions. I recommend to have them monthly at the introduction of a new service, and gradually reduce the number to quarterly sessions as your service becomes more stable.

What are important issues to talk about in Strategy Session?

  • The services’ stability in terms of availability, maintainability, utility, warranty and release cycles
  • decisions on components to transition to best practice.
  • prospective funds
  • upcoming major releases or changes to software or hardware and their impact on architecture or any other issue discussed above.
  • risk management, security and service continuity issues
  • 360 degree feed-back upon the mutual business relationship

A word on people?

I’ve seldom met people who work well on both sides of the Threshold. In fact, I know none. Either you’re hot for agility, or you’re hot for stability. When placing your personnel, make your pick wisely. Believe me, I know what I’m talking about.