Print Page   |   Sign In   |   Register
Service Management Forum Blog
Blog Home All Blogs
itSMF Australia Blog for Service Management Professionals

 

Search all posts for:   

 

Top tags: DevOps  itservicemanagement  itsmf  itsmfa  itsmfchair  professional  service management  Bulletin 

Of Biases and Blind Spots - The Known Unknowns

Posted By Michelle Crawford, Thursday, 6 April 2017
Updated: Monday, 10 April 2017

When I started writing the material for a series of talks I’m about to do, I latched onto Donald Rumsfeld’s old quote about ‘unknown unknowns’ that he delivered to a press briefing about weapons of mass destruction. You can find the full quote online, but he managed to raise the concept of knowledge having different states into the public consciousness.

Rumsfeld’s clumsy phrasing made it seem like some kind of an absurd excuse doled out to White House journalists hungry for proof of deception; but the concept became memetic, spreading through the internet and even referred to in the title of a 2013 biographical documentary—The Unknown Known.  Ironically, unknown knowns was the one state of knowledge he’d left out of his quoted explanation. Ironic, because the unknown knowns are also described in psychology terms as ‘façade’ - knowledge we have about ourselves that others don’t have.

It was when I dug deeper into the history of this quote that I found the connection to psychology. Two cognitive psychologists, Luft & Ingham, developed the Johari Window in 1955 as a tool for self-awareness. The subject describes themselves with attributes chosen from a list and then their peers choose words from the same list to describe the subject.

The responses are collated into four quadrants: attributes selected by both subject and peers are in the first quadrant as the Public Self (or known knowns); the second quadrant contains words chosen only by the subject—the Private Self (unknown knowns); and, the third has those attributes only the peers selected. This is the Blind Spot. This is where true self-awareness happens; and in a corporate setting, we can seek out that knowledge we don’t have by asking questions about the gaps we know we have. The final quadrant is where all the attributes that weren’t selected by anyone are all dumped.

After I’d followed this connection and wrote it into my presentation material, the Johari Window as a corporate knowledge tool has since come unbeckoned onto my radar on two occasions in different articles online and it also appears in the Gamestorming book that every good facilitator owns (check The Blind Side activity on pages 149-150). Confirmation bias at work! Let’s face it, confirmation bias, and a whole lot of other biases, affect our decision making at work. (Here’s a handy cheat sheet to all the biases and what they’re good for). We have blind spots, we have risks that no one has ever considered. That’s what makes a simple technique like the Johari Window so useful.

When you ask people to explore organisational knowledge in terms of those quadrants you can uncover rich opportunities for enabling flow for the known knowns, discover untapped resources and latent talents or needs, facilitate peer learning for the known unknowns, and unearth project risks you’d otherwise not planned for. Try it out before you kick off your next project.

Aprill Allen – itSMFA Board Member and Conference Director

This post has not been tagged.

Share |
PermalinkComments (0)
 

The DevOps movement and Microservices: Not as bad as you think, not as easy as you’ve heard

Posted By itSMF Australia Inc, Monday, 19 December 2016

DevOps is the latest Holy Grail within the IT industry.  Everywhere you turn there is a story online regarding how companies like Netflix, Spotify  or Amazon have done amazing things through the application of DevOps principles. 

A quick search on LinkedIn, Seek or Indeed returns hundreds of results for shiny, new, cool roles with my personal favourite being….

“We are looking for a Senior Systems Engineer who believes in the collaboration between the development world and operational practices.”

Translation:  “We need someone who will…you know…talk to the other technical people to make sure everyone is playing nice together and the business gets what it wants.”  This, apparently is a new concept within IT.

The rise in stories regarding successful application of DevOps principles in the market has also given rise to increased anxiety amongst traditional, ‘legacy’ operations teams.  With conceptual ideas such as ‘NoOps’ (An IT environment so automated that there is no need for a dedicated team to manage software in-house) getting more and more press it is no wonder that IT Operations teams are getting ulcers.

Business is feeling the pressure too.  Everywhere you turn businesses are told that they aren’t agile enough or fast enough.  You need to go faster!  Faster!  With less resources! And less cost!  And more value!  If you can’t be the Netflix/Amazon/Spotify of your industry, you are going to die a quick and painful death as these small, agile, super smart, DevOps aligned, no-process driven, latte-sipping, drum circle Millennial genius hiring start-ups fire past you.

Well, there’s good news and bad news.  The good news is: You have time.  Your business is going to be just fine over the next 5 – 7 years.  There’s a large, very helpful community out there eager to help. A simple hashtag search for #DevOpsDays is all you need to start soaking in information. As long as you, don’t emerge with a Blockbuster Video or Kodak mindset, you’ll be fine. 

Keep in mind that that DevOps can’t survive WITHOUT good Agile, LEAN and IT Service Management principles in place.  That’s great news for many ‘legacy’ businesses because they already have these capabilities within which should, in theory make their journey towards DevOps nirvana faster and less painful. 

The bad news is, DevOps takes time. But don’t take my word for it, Click Here to hear it directly from Netflix themselves. The link will take you to the precise point in the video where Ruslan Meshenberg of Netflix describes the challenges of their 7 year journey.

DevOps doesn’t have an instruction manual.  It doesn’t have standardised guidance. It’s going to require a tremendous shift in mindset especially in the areas of experimentation and ‘failing comfortably’. If you are working within a legacy, fear based, blame culture DevOps will require a SIGNIFICANT amount of ‘hearts and  minds’ work.

Further to this, ‘Operations’ doesn’t just go away. It just looks different.  In THIS video (also queued up for your convenience) titled ‘What I Wish I Had Known Before Scaling Uber to 1000 Services’ Matt Ranney discusses real world issues with the application of DevOps principles inside the internet startup darling Uber. As an ITSM specialist, my favourite bullet point on the slide reads ‘Understand a Service in the Larger Context’.

DevOps, like the other frameworks, standards and practices that have come before it will not solve all of your problems.  It will not fix your dysfunctional work culture in and of itself. It is a collection of ideas that has been shown to work within a specific domain for specific company types.  Within it, are practices and ideas that may be repeatable and reusable for you and your business. How useful is largely dependent on your culture, your strategy and your understanding of what you mean to do in the market.  Without a clear understanding of that….DevOps is just another shiny anagram that looks good in the store window but may provide little value if you don’t really need it (yet).

Phillip Palmer

itSMFA Board Member

 

 

Tags:  DevOps  itservicemanagement  itsmf  itsmfa  itsmfchair  professional  service management 

Share |
PermalinkComments (0)
 

DevOps + ITSM - working together

Posted By itSMF Australia Inc, Thursday, 15 December 2016

The DevOps approach to program development is being adopted universally with enthusiasm and is reportedly achieving much success in meeting the demands of business for the rapid delivery of new or improved IT based services.  This success is seen to be due chiefly to (a) the willingness of software developers to accept radical changes to the way they work, (b) the use of cloud computing that can rapidly meet demands for more compute capacity, (c) the availability of tools for automating testing and (d) streamlining normal change and release management processes.

 

Whilst commendable results are being achieved by DevOps, their approach is challenging the conventional processes employed by service management in that (a) ITSM people are naturally reluctant to accept unorthodox changes to their traditional and accepted way of managing services and (b) some key services are being overlooked or even ignored.  These are mainly in the areas of Service Level, Availability, Capacity, Information Security and Continuity Management.  There will also be issues with early life support, which by the nature of the DevOps approach may be an ongoing requirement and which may require normal incident and problem management activities to be bypassed.  These challenges need to be investigated to confirm the above impressions and if real, to develop approaches that will result in a win-win situation where there is open communication and collaboration between the developers, operations and IT service management.

Many blogs, white papers etc. have been written on DevOps, explaining what it is and how it is achieving these results.  However few describe in any detail the actual methods that DevOps is using, thus making it difficult to arrive at practical ways for IT service management practitioners to work collaboratively with DevOps people, for mutual benefit.  It is suggested that strategies and policies are needed to provide clear direction as to how best to achieve both short and long-term objectives.  Also more research is needed into DevOps methods and lines of communication set up with DevOps practitioners and associated professional bodies to fully understand their operations and to develop guidelines for adapting current ITSM practices to the DevOps approach, such that the objectives of both are met within required timeframes. 

The key is believed to be the willingness of both parties to communicate, cooperate and work together collaboratively.  Anyone involved in ITSM and/or DevOps activities who are experiencing any difficulties in these areas are urged to communicate these to us, to assist in developing guidelines that address any such issues.  Please send to info@itsmf.org.au

Brian Jennings

itSMFA Board Member

Tags:  DevOps  itservicemanagement  itsmf  itsmfa  itsmfchair  professional  service management 

Share |
PermalinkComments (0)
 

ITIL and DevOps, they actually work well together...

Posted By itSMF Australia Inc, Tuesday, 13 December 2016

ITIL and DevOps, they actually work well together... I think the hype surrounding the launch of newly discovered frameworks sometimes comes at a cost of having to compare it to something else to try to sell its value. In this case I’ve heard much discussion of why DevOps is better than ITIL and how ITIL won’t be required anymore.

I’ve heard this message particularly loudly from the software sales companies. My view on this has been broadcast a few months ago where I challenged the notion that ITIL is dead because of DevOps. Clearly at the end of the discussion ITIL was agreed to be well alive and still needed. My conversations over the last numbers of months with senior IT managers confirms my views that ITIL is still needed, desperately by some!! What pleasantly surprised me about DevOps and ITIL working together is the high degree of synergies between the two frameworks. Where ITIL doesn’t have the degree of fidelity in terms of Development activities, DevOps picks up. Where DevOps doesn’t look at some of the process and governance guidance, ITIL does. Personally I think this is the case in a number of the frameworks that are currently out there, be it AGILE or IT4IT or others.

We are after the same outcome if we are practising in this space, smarter, better, cheaper, quicker, more efficient, more controlled etc. Take the time to dig into the frameworks and look for the complimentary similarities and see how things can work together before judging one over the other. So in terms of DevOps vs ITIL, I think we should forget trying to stand each other off and embrace the value each framework brings, especially if they are combined together! Remember folks.. we didn’t evolve from monkeys by not working with each other and I personally rely on this philosophy as part of my personal and professional life. Truly great results are achieved when we leave our ego’s at the door and embrace each others differences and unique skills or insights.

Again in this case I would highly recommend that we look more deeply into the value both frame works can bring especially when they are used together. The links below are worth considering as is the whitepaper available from Axelos. Stay tuned to the itSMF Australia as we prepare to bring you more information and more presentation on complementary frameworks such as DevOps, AGILE, Agile Prince2 and many more. Can DevOps and ITIL co-exist – A story of two IT service philosophies Trust me: The DevOps Movement fits perfectly with ITSM DevOps vs ITIL ITIL vs DevOps DevOps and ITIL Friends or Enemies Maximize the synergies between ITIL® and DevOps

Justin Gasparre

itSMFA Board Member

Tags:  DevOps  itservicemanagement  itsmf  itsmfa  itsmfchair  professional  service management 

Share |
PermalinkComments (0)
 

DevOps and Service Transformation

Posted By itSMF Australia Inc, Wednesday, 7 December 2016
Updated: Wednesday, 7 December 2016

Up to now I had regarded DevOps as something that lived primarily in the Applications Development environment and could never figure out why the ITIL folks were getting all excited about it – in both positive and negative ways. The sessions I went to at the itSMF Conferences, the people I talked to and what I had read on the topic gave me the impression that it was all about getting application releases into production quicker and more efficiently.

Great !!!

But I was wrong ….

When the Chairman of itSMF Australia challenged the Board to write a blog of 500 words on DevOps I actually had to do some reading and research of my own (prodded by some excellent references supplied by Brad) and try to understand what DevOps might mean to me and my organisation.

Interesting enough the two planets were actually aligned because my organisation is constantly looking at ways to improve the way we deliver services to our customers.I certainly have some firm views, based on over 30 years of IT service delivery plus the wisdom and guidance of the ITIL framework.

So what could DevOps add that I hadn’t already thought of?

The article that did it for me was written by John Custy and it was titled “How to enhance IT support with DevOps (Part 1)” – and I didn’t need Part 2 because I got one of those light bulb moments when I got to the bit about CALMS.

In a previous life the acronym meant the Computer Aided Livestock Marketing System (I’ll let you guess what organisation I was working for at the time) but in this context it’s a framework defined by Damon Edwards and John Willis that means:

So why the light bulb moment?

Remember I mentioned earlier that I had some views on the way we could improve service delivery in my organisation?

Well let’s just say the light bulb went on because pretty much the things I thought needed changing aligned very closely with CALMS. Read on while I go through them and think about your organisation along the way.

Culture – I talked about changing the way people think about services and customers, getting out of the loop of “we’ve always done it that way”, working more collaboratively, becoming service focussed rather than technology, getting into a matrixed model and out of the delivery silos. CALMS talks about shifting from silos to constant communication, focussing on results, not just activities and understanding the behaviours of the teams. A pretty close match I think.

Automation – It’s reducing but we still process lots of paper based forms, emails and many of our processes need manual intervention. We have lots of knowledge that would be useful to share that could be done much better and we could use Problem Management and the information we gain from Incident management better. CALMS talks about all this and more, including the need for support teams to help with testing and closer integration with development and deployment activities.

Lean – many of our processes work and have done so for years but we are so busy we haven’t had much time to look at them and see if they could be simplified and/or improved. There is also a natural aversion to admitting failure and hence learning from it. CALMS says we should eliminate waste, always improve and view failure bas a normal part of learning that should be shared.

Metrics – I think that generating some basic metrics quickly highlights which teams are performing well and which ones need help – and ditto within the teams if you go that far. I’m not an advocate of a large number of metrics because I think it leads to analysis paralysis but some basics that tie into the goals and objectives of the team can be very useful. CALMS talks about the time to recover from failure, repeated issues, meeting targets and costs but the overall goal is to keep track of things that matter.

Sharing – knowledge is power and sadly some people don’t share as much as they should because they think it gives them an edge over other people in their team or elsewhere in the organisation. The toolset can be partly blamed but I think the people themselves need to recognise that sharing can make the whole organisation more powerful. CALMS talks about understanding goals, sharing knowledge, communication and toolsets and ultimately wether the rest of the organisation understand what we are doing.

Did the lightbulb go on for you? Can you see the relevance in your organisation?

And finally as Mitchi Tyson taught me – the best most efficient process in the world is useless unless people actually use it. I think that by looking at the things above you stand a better chance of success whether you follow ITIL or DevOps (or both).

Harry Powell

itSMFA Board Member

Tags:  Bulletin  DevOps  itservicemanagement  itsmf  itsmfa  itsmfchair  professional  service management 

Share |
PermalinkComments (0)
 

Friends for Life: DevOps and Service Management

Posted By itSMF Australia Inc, Monday, 5 December 2016

The DevOps movement is gaining traction in our industry. It is people centric and culture driven. It strives for fast delivery, customer satisfaction and excellence. Much of the DevOps movement is built on the foundations of sound Service Management such as recording incidents, managing changes, standardizing releases and managing knowledge; just to name a few.

DevOps brings new blood from software engineering and reinforces Service Management’s focus on delivering value. It has a strong focus on culture, learning, automation and the removal of waste from processes. Together, traditional Service Management and DevOps build a bold future and they answer the big question faced by the IT department: How do we deliver more value to our customers in a fast changing environment?

The Service Management community want to boldly share fresh perspectives as our members engage with DevOps at all levels, highlighting the value of all ideas that enhance service delivered to customers. We will build bridges and deliver our mission statement connecting members and maturing service.

I have asked our board members to embark on a personal journey and engage with DevOps and the DevOps community. In the spirit of Agile we are organizing a number of sprints to learn, engage and deliver fresh perspectives. Your Board will commence our first sprint this week by informing ourselves and reflecting on what we are learning by writing a series of short blog posts. We will share these with the community, measure, learn and respond with new connections for our members. We invite you all to join us.

We hope that you join our journey, that you benefit from the results and that together we drive more value for the organizations we serve.

Bradley Busch

Chair, itSMF Australia

 

Tags:  Bulletin  DevOps  itservicemanagement  itsmf  itsmfa  itsmfchair  professional  service management 

Share |
PermalinkComments (0)
 
Association Management Software Powered by YourMembership  ::  Legal