The Stuff from Pink That Made Us Think

With the 2017 HDI conference just around the corner, we wanted to document and share some of the key takeaways we brought away after the 2017 Pink Elephant conference last February. As with many of the 2016 and 2017 IT service management (ITSM) conferences, there was so much more being talked about than your traditional ITSM, ITIL, and service desk fare. With Lean, Agile, and DevOps spanning two Pink 17 tracks along with two Pink Elephant staples – leadership and organizational change management.

The following sections offer quick sound bites from some of the sessions related to these topics. And, in reading them, bear in mind a J. Paul Getty quote offered up by Pink Elephant’s President,David Ratcliffe:

“In times of rapid change, experience could be your worst enemy.”

Plus, don’t expect any topic definitions in this blog – that’s what Google is for.

Learn how ChangeGear supports DevOps and ITIL Change Management

1. Lean

Pink Elephant legend (we believe that this is now his job title), Troy DuMoulin, presented on “What IT Managers Need to Know About Lean Management.” Explaining that Lean is all about:

Increasing customer value

Eliminating waste

Management as facilitator

Involvement of all employees

Continual improvement

Summarized as: “Preserving value with less work.” And with customer value at the center of everything:

However, we shouldn’t forget that Agile can be applied elsewhere – Google “Agile ITSM” and “Agile service desk” for a start.

Although Dave van Herpen offered a timely warning about Agile in real life:

And, with Lean and Agile seen as the parents of DevOps (along with ITSM), it leads us nicely onto …

3. DevOps

What is there to be said, or written, about DevOps that already hasn’t been repeated in countless media articles, blogs, and DevOps 101 presentations? (Well, other than much-needed real-world DevOps stories told from the IT Ops perspective).

At Pink 17, Rob England (the IT Skeptic) offered something above and beyond the norm – a five-stage model for how organizations adopt DevOps. It’s great to finally hear talk at ITSM events of not only the destination but also how best to get there.

All we need now is for Rob to write a paper for those not fortunate enough to be in his session.

As to the value of DevOps, and especially for those still thinking of it as a passing fad, Dave van Herpen offered up this highly-sharable summary:

I wonder if we will hear a lot more about DevOps at HDI?

Time to Get All People-y

David Ratcliffe offered an interesting list of why people fail to perform:

They don’t know what they should be doing

They work on the wrong things

They don’t know why they’re doing it

They don’t know what is most important

They don’t work effectively as a team

They don’t know how to do what they’re supposed to do

Most of which are undoubtedly the result of poor leadership/organizational change management – providing a great segue into the next two topics.

4. Leadership

David Ratcliffe (yes, him again) used a single slide to effectively differentiate between “management” and “leadership” – two words that are unfortunately often used interchangeably (and much to the detriment of leadership):

LEAN guru Mike Orzen looked at leadership through a different lens, presenting on the kind of leaders we need for DevOps, and the key qualities/attributes:

Respect – with this working two ways for leaders: “to have due regard for the feelings, wishes, rights, or traditions of others” and “a feeling of deep admiration for someone elicited by their abilities, qualities, or achievements.”

Humility – in that “Knowledge requires learning, learning requires humility” (unknown source) plus the definitions of humility for leaders that include the acceptance of one’s limitations and the ability to recognize the intrinsic self-worth of others.

Self-Development – that leaders need to start with a vision, then start to develop themselves, and only then start to develop others. Importantly understanding that “People focus on those things their boss talks about most frequently and models consistently” (Mike Orzen).

Reflection – with leaders needing to understand that “We don’t learn from experience, we learn from reflecting on experience” (John Dewey).

You have to say that, wherever the application of leadership, the differentiation between management and leadership has to be a key starting point.

1.“Establish a sense of urgency – such that people start telling each other ‘Let’s go, we need to change things!’

2.Create a guiding coalition – a group powerful enough to guide large changes influences others to accept change, and one that works well together.

3.Develop a vision and strategy – the guiding team develops the right vision and strategy for the change effort.

4.Communicate the change vision (and, communicate it over and over again) – People begin to buy in to the change and this shows in their behavior.

5.Empower broad-based action – such that more people feel able to act, and do act, on the vision.

6.Create short-term wins – momentum builds as people try to fulfill the vision, while fewer and fewer resist change.

7.Consolidate gains and produce more change – people remain energized and motivated to push change forward until the vision is fulfilled/fully realized.

8.Anchor new approaches in the culture – new and winning behavior continues despite the pull of tradition, turnover of change leaders, etc.”

Peter offered a long list of “dos” but in some ways the “don’ts” are the things we need to be warier of, which include not:

Trying to micro-manage everything

Putting minor changes through bureaucratic processes

Forgetting the agreed degree of exposure to risk

Focusing solely on the IT

Forgetting the people

Overcomplicating things

Ignoring the aftereffects of failed changes on people

Neglecting the costs of transition

Succumbing to inertia

Pretending that there will be no losers.

Learning from Failure

Finally, while not a headline topic at Pink 17, it was great to see something that we wish we saw more of at other ITSM conferences – people talking about failure. After all, we’re meant to learn more from failure than we do from success.

Pink Elephant consultant, Jack Probst, used one of his conference sessions to question whether learning from failure is possible. Talking about failure as a learning process. That failures are only useful if we learn from them. And to learn from “intelligent failures” that permit learning.

Which sets us up nicely for the HDI conference in May, where hopefully we’ll hear about industry failures – and what we should learn from them – as well as the successes. And hopefully we will see you there too.

Previous Article

Microservices, DevOps, and ITSM for an Antifragile Business

Microservices are a software architecture that creates antifragile systems by breaking monolithic applicati...

Next Article

The Continued Importance of ITIL Change Management in Light of DevOps

If you work in the IT Service Management industry, and even if you don't, the late-February Amazon Web Serv...