Is ITIL dead?

Why ITIL must adapt if it is to remain relevant in the Digital era

ITIL is dead! A contentious view? Almost certainly, and I don’t think I’d need to throw a stone too far in any direction before I hit somebody that fervently disagrees with me.  So why do I say this?  One word – Digital.

Don’t get me wrong, ITIL still has its place, and many, many organisations are still using it just fine, thank you very much. But the writing is on the wall.  Digital is here to stay, and slowly but surely (and in some cases very quickly!) we are beginning to witness a wholesale shift in enterprise technology strategy from traditional, legacy IT service delivery to a model that is embracing the Cloud (in all its guises), platform and device mobility, automation (everywhere!), and focus that places customer experience front and foremost on the list of priorities.

Whilst ITIL can and does still enable the delivery and support of these technology objectives, it is rapidly being considered ‘clunky’, and organisations are increasingly seeking to adopt more flexible operational governance that aligns more sensitively with the change cadence required, nay dictated, by such advances.

Digital technologies, by their very nature, tend to be fast moving and highly volatile. Development of these technologies predicates an equally fast moving service lifecycle to ensure that customer expectations are both met and maintained in a customer environment that now demands swift and constant improvement and innovation.

Agile is one part of the industry’s response to this challenge.

The recent proliferation of tools and techniques to support Agile delivery frameworks is an indicator of the steady rise in adoption of iterative work cadences, and the reality is that many traditional ITSM framework implementations simply aren’t geared up to support this approach.  In many cases, ITSM actively works to impede the delivery of change in an agile manner, and this creates a very real dilemma for IT service management leaders.

The crux of this dilemma is as follows:

  1. Many of the core ITIL processes have been designed to protect production operations from the impact of change, and manage any impact of that change accordingly
  2. Agile (and supporting frameworks) have, however, been designed to increase the velocity of change, and the flexibility by which it is prioritised

As every Change Manager will no doubt surely confirm, increasing the rate of change (potentially to daily or even hourly increments) can put major stresses on a process not necessarily designed to work at this pace. Equally, the concept of ‘trust’, so fundamental to the Agile methodology, may sound great in theory, but is not so alluring in practice when you’re the Head of IT Operations with SLAs to meet and audit controls to adhere to.

In the Waterfall world change, to a degree, works coherently with ITIL and the phased approach to delivery (design, build, test), gives service management functions the time and space to perform the necessary activity required to protect service.  In an Agile world, however, this paradigm is challenged, and what were very well structured, methodical, and well understood governance controls, suddenly become a blocker to the realisation of business value (at the pace with which the business wants to realise it). In some cases this can happen almost overnight, as businesses take the decision to cut to iterative software development methodologies in a big bang approach, often with scant regard for the impact on service management and operations functions.  Almost instantly we witness the clash of worlds (Old versus New).  And word to the wise my friends, the business is normally championing those in the New camp.

It is at this point that we hit the dilemma.  What takes priority – the rapid realisation of business value through the swift release of change, or the protection of production systems (and thus the customer experience) from potential availability or performance degradation as a result of change?

The answer depends heavily on the type of organisation and system/service being changed, but of course the real answer is that both are equally important.  The issue, however, is that Agile is considered new, revolutionary, and progressive (it isn’t really but that’s beside the point). ITIL, on the other hand, is considered by many to be overly bureaucratic and a constraint to the realisation of business value. And remember, perception is reality, especially when those doing the perceiving also happen to be holding the purse strings.

The result is that IT service leaders, in the face of a business strategy that promotes a fast pace of change that it is perceived to be constrained by service management control, quickly become guilty by association. An inability to respond quickly to this challenge will only compound the issue.  The next logical step from there is the disintermediation of IT altogether, as business change leaders look to more flexible ways to deliver value to their customers, unhindered by legacy constraint.

To avoid this scenario IT service leaders, and the processes that they adopt, must adapt. Long term proponents of existing models must wake up to this notion. This change train is most definitely coming and it’s not showing any signs of slowing down.  We have a lot of baggage to carry, so getting on the train will be hard, but it’s also absolutely necessary (I think I may have stretched that analogy a little thin).

Thus ITIL, whilst perhaps not dead per se, is certainly badly wounded and in desperate need of triage.

As Ralph Waldo Emerson is famously quoted as saying, nothing great was ever achieved without enthusiasm. Well now is the time to get enthusiastic, because if enough of the community are, perhaps ITIL might just survive after all.

What do you think? Leave a reply below or contact me by email.

2020: The Digital Employee Experience

As organisations adopt new ways of working and technology to increase their competitiveness, the employee experience – the interaction between an organisation and its people – is radically changing. So what might the employee experience be like in 2020? Here are some ideas…

Agile loyalty: The ability of an organisation to respond effectively to rapidly changing market conditions is a key source of advantage in today’s global economy. For example the sharing platforms created by digital disruptors like Airbnb or Uber have helped lower supplier costs and increased customer choice.

Arguably this sharing platform capability could be developed further to create other forms of competitive advantage such as enabling collaborative or even competing organisations to share their human resources on-demand. In 2020 an employee may be expected and supported by their parent organisation to work in different areas of the same sector as a form of short-term resource exchange that delivers mutual benefit for all participating organisations.

Traditional and digital integration: In B2C markets today there is a strong focus on integrating the traditional and digital experience of a brand to create seamless, insightful customer offerings anywhere, anytime. The adoption of Bluetooth beacons in stores to personalise the physical shopping experience as a complement to digital channels is an example of this omnichannel approach.

For such integration to be commercially successful the employee experience needs to blend offline and online work tools together effectively. The use of smart devices like tablets by shop floor employees to access stock information instantly to support the sales process demonstrates the positive impact of such change. Yet as digital technologies mature, such integration is likely to accelerate further – for example van manufacturers are now prototyping drone-equipped delivery vehicles. In 2020, an employee may need to have the skills to work successfully with a range of old and new technologies integrated together for customer benefit.  

The trust economy: The digital employee experience is fundamentally changing the intrinsic relationship – the bond or trust – between an organisation and its employees. Driven by disruptive factors such as the globalisation of the labour market and proliferation of social media, the need to have aligned cultural values between these stakeholders is critical to realising the advantages of employee self empowerment and agility.  

Today, many organisations are making the public move from a corporate social responsibility approach to the combined goals of social, environment and economic sustainability – a shared set of values with their employees. In 2020, such trust may be essential to the employee experience with an organisation communicating daily updates to its people about its performance against its sustainability goals to help intrinsically motivate their performance.

If you would like more information about how digital employee experience design can benefit your organisation please contact the Sopra Steria Digital Practice.

Putting the ‘soft’ into software: lessons from Agile Cymru 2016

I had the opportunity to attend the 2-day Agile Cymru 2016 conference in Cardiff, which I grabbed with both hands. I was lucky enough to have co-presented here with Margaret Morgan in 2015, and was keen to experience the workshops and speakers on offer, which promised to be an eclectic mix.

The Agile Cymru conference attracts speakers from all disciplines and countries, and it was a particular treat to hear the keynote speakers on both days: Dr Kitrina Douglas and Stevyn Colgan.

Dr Douglas is an independent researcher who specialises in identity development, physical activity and mental health; this interest has grown out of her experience as a successful amateur and professional tournament golfer. She has won the European Championships, the English Open Championships and was a member of the first winning European Solheim Cup team.

Stevyn Colgan is an ex-policeman, author, artist, songwriter and public speaker; he has written TV scripts for Dr. Who and is a visiting lecturer at several UK universities.

 Dr Douglas spoke about the importance of the acknowledgement of alternative narratives to any given ‘dominant narrative’ (personal or cultural). The stories that we accept and tell ourselves and each other about who we are can limit our potential for happiness and fulfilment. For example, the narrative “I have to be the best, so I must sacrifice my time to practice and more practice”, is not the only narrative of champions. Her research, involving many conversations with sports men and women, has demonstrated that other stories can also be told, for example “I enjoy my golf and love the opportunities it gives me to travel”,(amongst many others). Interestingly, our actions, behaviours and stories shape the way the brain develops.

 Stevyn Colgan spoke about his experience as a policeman who sought to change the way in which policing is approached. He spent his time looking for ways to prevent crimes rather than to maximise the number of his arrests. As a policeman on the beat, this included talking to people to find out why some areas were more prone to crime than others, and arranging a dog show on a troublesome estate in order to bring the young and the old into contact.

The ‘commit a crime > get arrested > go to court > get sentenced’ narrative is creatively and effectively challenged by the idea of prevention by addressing circumstances and other factors.

But what has all this got to do with agile software and systems delivery?

My answer is this:

One of the things that agile seeks to do is to maintain the essential connection between business value and product delivery through the creation of high performing teams who deliver iteratively and continuously for as long (or as short) as needed. Adaptation and responsiveness to change is essential. Dr. Douglas and Stevyn Colgan are strongly favouring individuals and interactions over processes and tools (as per the Agile Manifesto), and are demonstrating with real results the benefit of so doing. This is directly related to creating and delivering software, and reminds us to ask continually about the value and purpose of what we are building.

The transformation of our working lives through the application of agile principles in software development is taking us deeper into areas of personal and team development.

This is borne out by the high proportion of ‘soft’ skill presentations and workshops at Agile Cymru 2016, where sessions such as “A manager’s guide to working with self organising teams”, “Empathy from agility”, “How to grow beautiful teams”, “Empowering people through play” sit alongside sessions like “Strategy Deployment for the Agile Enterprise”, “How deep are your tests?”  and Joseph Pelrine’s “Psychological aspects of estimating” (a scientific study of the interaction between system data and human behaviour).

References to specific tools or technologies are minimal. The chief areas of focus are: how to maximise team/personal empowerment and how to ‘scale agile’. These reflect the kinds of shifts that agile principles require of businesses in order that systems and software can deliver most value, most quickly.

I have to give a mention to Adrian Panucci, Matt Roadknight and Eben Halford, who delivered the most interesting, creative and insightful session of the conference. They addressed the challenge of ‘Dealing with Evolutionary Change’ head-on. In short, successful organisational change involves everyone at some point moving out of their comfort zone, across an edge, and into a new reality. This experience was cleverly facilitated for the participants, and allowed us to get a deeper insight into the personal and cultural edges we need to work together to move through to create new ways of working.

This focus on the ‘soft’ aspect of software delivery is changing the conversations and interactions we have at work every day. This, to me, represents the essence of agile and I am excited to see where the journey takes us from here.

All visuals above attributed to Fran O’Hara

Have you reached your digital tipping point?

Here at Sopra Steria we have been talking to our clients about their plans for digital for several years. We’ve seen them move from mild curiosity, through active experimentation towards full-scale transformation activity.

Given the diverse nature of our customer base, spanning public and private sectors and the many and varied organisations that comprise those vertical markets, you’d expect each and every one of their experiences to have been different. You’d be right, too! But you might also be surprised at the similarities across businesses of all shapes and sizes as they evolve to greater levels of digital maturity.

Certainly, many organisations over the past few years have focused their early digital efforts on enhancing the customer experience. Driven by an ongoing consumer-driven demand for better services, across an ever-lengthening list of channels and devices, companies have recruited creative agencies, consultants and advisory partners to help to introduce compelling new user experiences, in order to retain both relevance and customers in an environment of swirling change.

Many of these organisations have had some outstanding results. However, many others have found themselves frustrated at an inability to transition their successful experiments, whether working in-house or with partners, across to their mainstream delivery portfolios. Knowing that businesses need to ‘keep the lights on’ whilst also transforming their culture in order to be more responsive, more agile and altogether more digital is proving to be the real challenge of the day.

This is where Sopra Steria makes a massive difference, as it helps its clients recognise this digital ‘tipping point’ and, more importantly, move beyond it!

Years of experience delivering and assuring large scale business and IT transformation programmes for our clients, combined with UX leadership, agile expertise and a growing network of emerging and established tech partners, puts Sopra Steria in the ideal position to work with clients to identify and select early digital wins in order to inject them, via a proven digital integration layer, into in-flight business and IT transformation programmes.

The ability to demonstrate the innovation required to retain market position, attract new customers and transform not only the infrastructure of the organisation but its culture is the key challenge our clients face today and the key reason they are turning to Sopra Steria as their digital partner of choice. View our interactive cityscape to see how such organisations are digitally transforming.

Supporting transformation: my thoughts from Scrum Day London 2016

As an advocate for the use of Scrum and in need of some Scrum Juice, I went with Sopra Steria colleagues Steve Forbes and John McNeill to the Scrum Day London 2016 – an event held by Scrum.Org where Ken Schwaber, co-creator of Scrum, was giving the keynote speech, and the day’s theme was “Business Agility through Professional Scrum.”

The story of the day for me was that while Scrum is popular, seen as necessary and is adopted by many, Scrum success as represented by teams delivering working software into Production every Sprint or Iteration (i.e. every one to four weeks) continues to be a challenge. Very few teams are able to report success against this measure – in fact, I was the only person in the room with a raised hand when Ken asked the question “How many of you release software every Sprint?”

The fact is, technology exists for teams to be able to release into Live every 5 minutes (or even less).

The issue appears to be that Scrum and Agile require a change in organisational thinking and support that is hard for many to implement, and in a way that allows the innovations a Scrum Team offers to be realised.

We heard first from Gunther Verheyen, co-developer of the Scaled Professional Scrum Framework, who laid out the map of the journey from a ‘waterfall’ type structure (and mind set) to one that supports Scrum. Gunther has a vision:

‘Management’ is not a collection of people exerting hierarchical powers. It is an emergent, networked structure of co-managers. Removing Impediments. Optimising a product’s value. Updating the organisation’s OS.

… and you can  view his presentation online.

Karen Bowes, Head of HR & Sustainability at Capital One gave an impressive and honest insight into how Capital One was adopting Scrum not just in software delivery, but throughout its management structure. We were reminded by Ken Schwaber that Scrum requires courage, and courage was used by Capital One to great effect: they realised that there is always ‘noise’ and conflict when new practices and change are introduced and accepted this as a fundamental part of deep transformation. The focus of their management and strategising was consciously shifted from detailed micro-planning and control to providing support for Scrum teams and the removal of impediments to Scrum team success. Not an easy journey, but one that has already reaped rich rewards for Capital One.

Ken Schwaber’s new initiative is to propose a ‘Scrum Studio’ approach, which effectively places a Scrum team (or group of teams) in a special location within an organisation, with all the support structures it needs, and allow it to get on with its job. In this way, the hope is that the impediments to successful Scrum uptake are removed and organisations can then further adopt Scrum practice at a pace they can manage if and when they see a benefit in doing so.

Whatever the future for Scrum and Agile, it is going to take motivated, influential and courageous individuals to lead and support the kind of transformations that business is being challenged to undergo.

It was a privilege to meet some of them at Scrum Day London. Do let me know your thoughts – leave a reply below, or contact me by email.

Agile transformation, its unanticipated impact on management and how to understand it

Many organisations are still developing software using lists of requirements with teams working in silos, and only producing occasional releases. However there is a better way simply called ‘Agile’, this is not a prescriptive approach and is certainly not just for developers.

Agile can significantly improve delivery of business value however it’s defined in your situation. And Agile is certainly a prerequisite of any digital transformation.

Adoption of Agile is now mainstream superseding traditional methods, however poor implementations of Agile due to a lack of understanding are very common. One particular aspect that is often misunderstood is the impact that Agile has on the organisation as a whole. Unfortunately Agile is often viewed as just another development method, however the transformation only really succeeds if management is transformed too: ‘Agile management’. Indeed this may be where the greatest value is added.

  • Higher management is aware that it needs to be Agile in order to be more responsive to customers and other stakeholders. They also want improved productivity and reliability
  • Developers understand that it’s more effective to develop quality software than spend time maintaining that resulting from poor quality. And working together rather than waiting for hand-overs from colleagues in other silos

It’s those in the middle who are responsible for managing development who need to be engaged. Not merely with Powerpoint presentations, and possibly Agile games, to explain how the developers will be working in future, but as a valuable part of the transformation otherwise the major benefits of the Agile transformation will be lost. They need to work differently in order to move from the ‘Iron triangle’ of cost, time & scope and upfront long term planning and budgeting to smaller batches, variable scope and frequent re-planning. Agile Portfolio management can add significant value to the business by becoming far more dynamic.

A new way of thinking is required that is appropriate to the complex world of software rather than the (merely) complicated world of construction and manufacturing. Unfortunately it has taken many years for this understanding to be accepted in the IT world. The traditional controls may seem obvious however in a complex situation they can often have the opposite effect to that intended. This  transformation may well entail roles being changed to match the future needs, not just for the development team but management too.

The introduction of Agile puts a floodlight on current practices revealing concerns that would otherwise only manifest themselves much later and at much greater cost. This will prove to be frustrating but these concerns plus the opportunities and the discontinuities between traditional management and newly Agile developers need to be accepted and dealt with as early as possible in order to reduce risks and unnecessary expenditure.

Therefore a culture change is required with teams looking at options to find the best ways forward. And, as each organisation is unique, metrics specific to the organisation are required. This will enable progress to be measured and the way forward to be validated regularly.

To summarise Agile is the most appropriate way to handle most software situations, culture change needs to be a significant part of the Agile transformation and it requires a methodical but flexible customised approach. The change to Agile is not a one-off change but a journey to where the customer will be.

Were you aware of the impact that an Agile transformation has on management? Leave a reply below, or contact me by email.

The Testing Pyramid

Agile has totally changed the focus of testing and introduced automation to support its development practices. I have been involved with software development teams for nearly thirty years. Over that time I have seen many different methods and practices come and go but testing has remained focused around manual testing. That is until Agile software development arrived.

An Agile iterative approach to software development means you have to test all your software all the time. Ensuring what you have just built has not broken a previous written piece of functionality. Agile automates testing at all layers of the application. This approach to testing is fast overtaking the traditional manual approach. Automated tests that previously existed were focused on testing the front end, the most volatile part of the application. They were also written after the application was built therefore not giving the short feedback loop we use in Agile software development. The Testing Pyramid puts a different testing emphasis on each of the application layers and focuses efforts at the beginning of the development cycle rather than at the end.

The Testing Pyramid

Looking around the web you will see various implementations of the Testing Pyramid with different names for the levels and implementing different types of tests. The one I use is the basic three level pyramid – Unit Tests, Service Tests and UI Tests. As with any pyramid, each level builds on the solidity of the level below it.

From technical view point one can look at these three levels as small, medium and large. Small tests are discreet unit tests that use mocks and stubs to collaborate with other objects and are typically written in one of the xUnit frameworks. Service level tests are the medium sized tests and interface with one other system, typically a database or a data bus. Large tests, UI tests collaborate with many sub-system parts they support the end-to-end scenarios.

Personally I look at the levels in a functional way:

  • UI Tests: Does the software work as expected by the end user?
  • Service Tests: Does the software meet the acceptance criteria on the user story?
  • Unit Tests: As a developer does the software work as I expect?

Unit Tests

Unit tests are the foundation of the Testing Pyramid. This is where the bulk of tests are written using one of the xUnit frameworks – for example, JUnit when developing in Java. They ask the question “Are we building the product right?”. When writing software I like to take a Test Driven Development (TDD) approach. TDD is a design approach to development where tests are written first and code written to support the test. There are a number of benefits to taking this approach:

  • High test coverage of the written code
  • Encourages the use of Object Orientated Analysis and Design (OOAD) techniques
  • Allows you to move forward with confidence knowing the functionality works
  • Debugging is minimised because a test takes you straight to the problem
  • Developers take more responsibility for the quality of their code
  • Because it is written to support specific tests, the code works by design not by coincidence or accident

Service Tests

I see Service Tests as supporting the acceptance criteria on the user story. They ask the question “Are we building the right product?”. When writing these tests, I like to take advantage of the Given/When/Then BDD format of the acceptance criteria and use one of the BDD test frameworks, typically Cucumber. I only adopt specification by example that is use real world examples in the acceptance criteria. This approach gives a number of benefits;

  • Assurance that all stakeholders and delivery team members understand what needs to be delivered through greater collaboration
  • The avoidance of re-work through precise specifications and therefore higher productivity

UI Tests

The User Interface is the most volatile part of the application and should not contain any business logic. For these reasons the least emphasis on automated testing should be here. That does not mean there is no testing, I like to automate key user journeys through the system using one of the UI testing frameworks e.g. WebDriver. UI testing demonstrates that all subsystems are talking to each other.

I use manual testing for the look and feel, checking the UI acts as expected and exploratory testing to find those hidden nuances.

Test Delivery

Unit tests and Service tests should be delivered in the iteration by the delivery team. As part of their development practices developers write Unit tests when building the functional code. Ideally a test first, TDD approach should be used.

My conclusion?

The Testing Pyramid inverts the traditional approach to testing. The focus is at the beginning of the development process with the developer taking responsibility for quality of their code. This is a very different way at looking at the problem from the traditional approach where code is handed over to the tester and they are assumed responsible for the code.

The early identification of defects gives two major business benefits;

  • Issues are discovered early in the development process reducing the cost of defect fixing associated with late discovery
  • Issues are identified and resolved early therefore negating the need to postpone the production release through late identification of issues

References

http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid

http://martinfowler.com/bliki/TestPyramid.html

http://www.agilecoachjournal.com/index.php/2014-01-28/testing-2/the-agile-testing-pyramid/