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
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:
© Pink Elephant, 2017
The second bullet on Troy’s Lean-explanation list is very relevant to ITSM and service desk operations, with Troy sharing a great list of common areas of IT waste:
- “Multiple service desks all with their own tools and separate processes
- Massive amounts of wasted server capacity due to a lack of capacity and demand management
- Redundant and duplicate IT management tools being purchased by various IT departments in the same organization
- Multiple change management processes due to political boundaries
- A willingness to solve the same incidents 1000s of times without looking at the root of the problem
- Supplier contracts expiring without knowledge until an incident occurs
- Losing track of tens of thousands of dollars of IT assets due to poor tracking controls and inventory processes
- The loss of massive amounts of business productivity due to incident tickets which disappear into the IT back office black hole until someone shouts loudly enough
- A willingness to supply multiple/duplicate versions of the same services.”
In summary, there’s a lot for IT organizations to benefit from with Lean – whether as Lean IT or as part of a wider DevOps approach.
Troy offered a great slide for articulating the benefits of Agile over traditional software development methods:
© Pink Elephant, 2017
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 …
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.
© Two Hills Ltd
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.
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):
© Pink Elephant, 2017
With the key capabilities for IT leaders outlined as:
- Commitment to knowledge and learning
- Understanding and clarifying objectives
- Prioritization and re-prioritization
- Empowering others
- Ability to communicate
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.
5. Organizational Change Management
Pink Elephant consultant, Peter Hubbard, spoke on “The 4 Ps of Successful Organizational Change: People, People, People, People!”, sharing the top ten reasons for resistance to change:
© Pink Elephant, 2017
And promoting J.P. Kotter’s “8-Step Process for Leading Change” as a key tool in helping to overcome them:
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.