Secrets of Modern IT Management

As technologies and methodologies have advanced, a lot of things have changed. So it’s natural that in the revolution of new processes and methodologies in the IT industry, also leadership and management models must be developed in order to be able to meet new challenges. I will briefly discuss about probably two best-known methodologies, ITSM/ITIL® and DevOps, and also correct some misunderstandings.

“Choose your side: ITSM/ITIL or DevOps?”

Headlines like that seem to become more and more common in today’s IT Industry, where organizations are struggling with ever-growing demands; Just On Time –deliveries, resourcing, predicting the future & markets, social media’s opinions, end-user requirements, and of course the need for profitable business.. And then a faceless consultant steps onboard and promises to solve all the problems with yet another “-ism”. While some time ago the “ism” was ITIL, nowadays it’s often DevOps with a touch of some other Agile –derivated method like Kanban or V-model.

Now, who do you believe? Does a highly structured methodology like ITSM/ITIL solve your problems or is it DevOps that releases your internal beast and assures your products and services are top-notch quality?

While some time ago the “ism” was ITIL, nowadays it’s often DevOps with a touch of some other Agile –derivated method like Kanban or V-model.

Correcting common ITIL and DevOps –related Misconceptions

In my latest blog text I wrote about common Misconceptions people have about Cloud Services, so I can continue writing about misconceptions, this time about the ITIL vs. DevOps –combat.. ..which really should not exist in the first place.

ITIL is set of guidelines, the best practices. It’s highly process-oriented approach on organizing the IT Services, including life cycle phases from Service Strategy to Continual Service Improvement. ITIL has somewhat gained reputation as a bureaucratic giant with enormous requirements for documentation while every function should have a lot of resources available for 24/7.

Partly the reputation is deserved, but largely it’s also about misunderstanding the paradigm: ITIL is about a set of guidelines. It’s like a toolbox where you choose the best and most suitable practices – not the whole nine yards. You don’t need to implement all the aspects of ITIL available in order to call your Services “being aligned” with ITIL.

On the other hand, whereas ITIL is missing the essential software development methodologies, DevOps comes in.

DevOps concentrates in software development and delivery process emphasizing on filling the silos between the development and operational phase.

DevOps emphasizes modern sw developmental actions such as continuous integration, testing, deployment and in a way blows new spirit to the old’n’ good sw development industry. DevOps introduces a new kind of culture where the need for collaboration and teamwork is highly appreciated. At the same time DevOps requires a bit different approach to leadership.

I’ve already written about the loopholes and demerits of DevOps here, so I won’t repeat myself.

So, what’s it gonna be: ITSM/ITIL or DevOps?

In case you didn’t quite get it, there is no idea in putting these two against each other, because for the most part they are solving different issues!

I suggest taking the best from the two approaches. ITIL is still today – by far – the best set of guidelines for running the IT operations, but I can recommend DevOps especially from the SW development point of view without forgetting DevOps’ main idea of covering the silos between the development and operations’ phases.

I suggest taking the best from the two approaches.

Attention! Lead your troops General!

How should DevOps –team’s management be organized? Some people say employees shouldn’t be controlled in any way but they should be given a 100% freedom to do their job, while others are on the opinion that the working hours shall be measured and more or less control is needed in order to get the results.

While there are a number of great posts written about managing a DevOps “teams”, for example here and here, there’s remarkably less articles addressing the challenge of leadership, leading the people in the holistic perspective.

 

The majority of executives today probably share the opinion, that when it comes to leading a specialist organization in the IT industry, a traditional  line-organizational management model is dead, because it doesn’t provide adequate set of tools to support leadership in modern IT environment. Those modern, self-guided teams are on the other hand eagerly saying they don’t need to be managed. Don’t listen to them, they don’t know what they are saying!

More than ever, in the era of Agile SW development there’s a pressing need for (good) leadership! A distinguished DevOps team can be working effectively without any outside guidance as long as someone is paying their salaries and bonuses. But bear in mind that a hundred sprints with huge amount of new features in the software don’t necessarily provide anything useful.

Those modern, self-guided teams are on the other hand eagerly saying they don’t need to be managed. Don’t listen to them, they don’t know what they are saying!

Leading and orchestrating the big picture of SW development is crucial for organization’s success. Can you cut it or is your organization going downfall?

1st level issues

To be able to even remotely manage your Orchestra, the following essential 1st level issues must be addressed:

  • What’s in the pipeline (or backlog if you wish)?
  • What’s currently under development?
  • Will the upcoming new features correspond the requirements agreed on with a customer (no matter internal or external customer)?
  • Do the outcomes of your SW development (both released and those still in the backlog or under development) match the organization’s strategic goals? (Assuming there ARE strategic goals defined, of course!)

Now that your things are basically going as planned, you can move on to the next level in management issues. Even though they are 2nd level issues, they are very important. Ignore the possible problems on level 2 and they will become 1st level problems in a way or another.

Ignore the possible problems on level 2 and they will become 1st level problems in a way or another.

2nd level issues

  • Outside the clear SW development issues you have of course other issues to be taken care of, i.e.
    • Resourcing
      • Are you certain people are in their appropriate positions? Need to make any changes?
    •  Sales
      • Are your sales personnel getting deals closed – short or longer term?
    • Hr
      • What’s the rotation speed of your personnel in your organization? Is there constantly coming new people in while those who have stayed longer are leaving? Should you do something about it and if not, why not?
      • Benefits and salaries: are you competitive against your fellow competitors?
    • Business
      • Is your business profitable or are you creating loss?
    • Customer satisfaction
      • Do your customers keep coming back to you or are they changing the supplier?
    • Legal issues
      • Are your legal & compliance issues in order?

The list goes on and on, but the message is clear: leave 2nd and lower levels unnoticed and they will eventually become 1st level problems.

Things listed above are only the tip of an iceberg, but I wanted to shake the buzzed thoughts that a modern SW Development running Agile methods only needs very little management if at all. That’s one of the risks in a well-welded DevOps team; it becomes too self-assertive and slowly ceases to consider the surrounding reality.

More than ever, there’s need for brilliant leadership and management! If someone is challenging my thesis about this, I’ll be glad to participate in the debate.

 

Pictures are from Pixabay.

ITIL® is a Registered Trade Mark of AXELOS Limited.

DevOps – what and why?

Let’s talk about software and service design, development/engineering and maintaining.

Traditionally, software development has meant a team who first designs the software, then they give the specification to another team who does the hands-on programming and testing the software. These phases have been thought of being the ”project” state and the project manager has been doing his/her job using a waterfall project management approach: design – develop – release.

After releasing the software there’s usually been a supply team who takes care of the software and pretty much makes use of ITIL®’s Service Operations best practices. It’s also notable that the past waterfall-styled projects have often been pretty big in terms of the project scope.

Think about this: Wouldn’t it be good if your product or service would be developed in a controlled way, piece by piece and you could be certain your production and development do the things together, hand in hand?

Silos

Traditional moffice-875695_640odel of software project development has been widely critized for causing silos. Silos are the infamous grey area where responsibilities are unclear, often ending up in the situation where somebody didn’t do anything, because he/she/they thought that someone else did something and finally nobody did nothing.

In practice this means that a) when the Design team has finished the specifications, they don’t care about helping developers get into the speed, but they just hand out the specs pages and think their job is done. Then b) developers do the programming according to the specs and c) throw the release to the services team for support & maintenance. And then after a while there will be a new version ready for release and to be maintained.

Silos are the infamous grey area where responsibilities are unclear, often ending up in the situation where somebody didn’t do anything, because he/she/they thought that someone else did something and finally nobody did nothing.

Problems with silos

What if the specs are somehow inadequate? Coders code and the result is something else than it should have been? What if the production environment where the software is supposed to be run and maintained differs greatly from the test environment where the product was developed? Whose responsibility is to make sure these kind of issues won’t get in the way?

ITIL has addressed this dilemma at least a little bit. There are notions that Service Operations should be involved early in the process. For example in ITIL’s Service Transition life cycle, in transition planning and support there’s a question if the plans have been agreed and authorized by all relevant parties (customers, users, operations, and support staff)? The idea is clearly to get all the relevant parties – including naturally Service Operations people – involved early enough in the new/changing services.

But according to my experience ITIL doesn’t cover all the possible silos there are. I was once discussing with a Canadian guy who was the responsible for the project management department  in a big German-based transportation & logistics company and he told me he hates ITIL because in his opinion ITIL didn’t do anything good but was cannibalising the software projects.

I believe that’s true up to some point. Even though ITIL is not a project management method, it lacks a credible way of linking the project management and service management.

He told me he hates ITIL because in his opinion ITIL didn’t do anything good but was cannibalising the software projects.

And that’s what the DevOps is bringing on: better co-operation between the different parties involved!

Definitions of DevOps

There are probably as many definitions about DevOps as there are organisations involved with it. But the following AgileAdmin’s definition of DevOps is the best I’ve seen: ”DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.”

To simply put, the idea is to enforce and empower co-operation and participation between the different parties.

The IT industry is evolving and changing rapidly. There’s an ever-growing need to improve products’ time-to-market, so there’s no space for silo-focused thinking any longer. Designing, developing, operations and retiring the product must happen as quickly and smoothly as possible. That’s where DevOps enters into the game.

There’s an ever-growing need to improve products’ time-to-market, so there’s no space for silo-focused thinking any longer.

It’s also worth noticing, that there’s a big difference between the Agile methods and more traditional project management methods. In the Agile world the idea is to build the product or service piece by piece, little by little. When following the Agile method it’s not clearly known what the final product or service will be or how it will look. Development is done in small steps and there won’t be too many new features implemented at the same time. Developmental phases, so-called “sprints” are usually measured by days and in some cases even in hours.

In the more traditional software development there’s usually a fixed specification which describes how the product or service will look like when finished. There’s usually a somewhat-fixed budget to cover all the expenses of the project. The project itself can be gigantic and the time frame can be anything from months to years.

Responsibilities in DevOps

Let’s face it: in the old world there was a number of people supporting and maintaining the systems. In the new DevOps world there’s no need for so many pairs of hands, because the idea is to automate processes as much as possible. DevOps should steer the operations of products and services to the new normal were the manual routine work is no longer needed in a large scale.

There are also many things in development phase that have been previously made manually and will be automatised. Theagileadmin.com says the following: ”In the DevOps world there’s been an explosion of tools in release (jenkins, travis, teamcity), configuration management (puppet, chef, ansible, cfengine), orchestration (zookeeper, noah, mesos), monitoring, virtualization and containerization (AWS, OpenStack, vagrant, docker) and many more. While, as with Agile, it’s incorrect to say a tool is “a DevOps tool” in the sense that it will magically bring you DevOps, there are certainly specific tools being developed with the express goal of facilitating the above principles, methods, and practices, and a holistic understanding of DevOps should incorporate this layer.”

So DevOps combines a number of different tools under the DevOps umbrella.

In my opinion it’s absolutely great that many boring prone-to-error routine-tasks will be handled automatically by a bunch of tools. But it would be a lie to claim there wouldn’t be any impact on the number of personnel involved in the developing phase. Of course it does! There will be less demand for i.e. people doing module- and performance testing, (manual) configuration management and so on. Many things like application performance monitoring and continuous integration have been automated to a greater extent etc.

I have pretty often come across a claim that ”now they (developers and operations people) have more time to focus on developing and continual improvement activities”. While this is of course true to some people, there are and will be people who simply don’t have any meaningful tasks to do any more. That’s the way it goes.

In my opinion it’s absolutely great that many boring prone-to-error routine-tasks will be handled automatically by a bunch of tools. But it would be a lie to claim there wouldn’t be any impact on the number of personnel involved in the developing phase.

Then there are also (bad) examples on how Dev(elopers) have been forced to take over the responsibilities of Op(eration)s people. That leads to a bad situation. Mr. Jeff Knupp has addressed this problematic in his writing very clearly.

He discusses about the Totem Pole and he expresses an idea that there’s a hierarchy of usefulness of technology roles in an organization and that Developer is at the top, followed by sysadmin and DBA. QA teams, “operations” people, release coordinators and the like are at the bottom of the totem pole. He states that each role can do the job of all roles below it if necessary.”

Forcing developers do all kinds of tasks leads to the situation where developers get frustrated and they cannot show or use their best abilities. So even though I completely understand that in a startup company people end up doing almost everything, I totally agree with Jeff Knupp that not every company is a start-up and that whenever possible “let developers write code!”.

office-875693_640

 

I personally really, truly like the idea to bring people to work closer together. It surely helps tackling silos away, improves transparency and most probably shortens development-cycles and thus shortens time-to-market of a product or service. I believe in DevOps in that sense and I’m sure when correctly utilized, DevOps can keep its promise.

 

But then again, if you think of introducing DevOps in your organization because of cost optimization, be sure not make the mistakes Jeff Knupp addressed.

 

Pictures are from Pixabay.

ITIL® is a Registered Trade Mark of AXELOS Limited.