My fellow team leaders and I have been challenged with coming up with a new Operating Model for Information Technology within our organisation. My hope is to take this opportunity to move us into a Dev Ops model for delivering systems and software to the business.

Our entire business is undergoing a change of ownership, with our new parent continuing to acquire new companies. The job of integrating similar roles and functions from each new business unit will pose challenges for every team in the business, but IT will likely have to play a large role in making this a smooth process.

My focus with this series of articles is on IT and how we can prepare for the upcoming work. We cannot tell in advance what the make-up in other companies will look like, nor how their methodology delivers functionality to their businesses. The goal here is to outline a target operating model that we can implement in my company that will serve as the template for the group as a whole.

IT is likely to have a large number of integration and systems migration projects, along with launching many new applications, both internally developed and from third parties. I believe that by moving to a Dev Ops model we will better be able to cope with the level of change.

The goals we want to achieve are to be able to deliver high quality software and systems quickly, at high speed, using reuse to achieve cost savings at a group level.

In this article I’ll list some of the problems I think we need to address. Subsequent articles will deal with each issue in more detail.

Problems

We face a range of problems in our development process that is hampering our ability to release code quickly and frequently.

What should I work on next?

Our teams have many projects in flight at the same time. These can be at different stages of development, anywhere from idea conception to testing or ready for release. Juggling these priorities can cause issues for teams. Does Dev Ops provide any solutions?

Where was I?

With so many different projects, context switching becomes a big problem. Every time you change the task or project you are working on, you waste energy and time.

I’ll deal with these two issues of prioritisation and context switching in Focused Teams.

You can’t do that on Dev

Often it is difficult to run scenarios on development environments because it has drifted too much from production. Particularly getting a database that matches production can be problematic. Are there any strategies in Dev Ops to help? We’ll discuss that in Refreshing Data.

Our systems are down

Production support issues regularly need to be referred to the developers that wrote the code. This has a knock-on affect on the ability of the development team to produce new features. Developers can be selfish, wanting to keep writing new code. I‘ll discuss the change in culture required to think of Production Support as the key priority.

How awesome is my code?

Value stream mapping is an exercise that can be used to find bottlenecks in the software development life cycle. Feedback from downstream work units is one of the key measurements that we should look at. I discuss this approach further in an article called Feedback.

How soon can you get this into production?

Lead time is a critical measure for any development team. How long will it take to agree requirements, develop, test and release software? Dev Ops is supposed to have a huge impact on lead time.

Did you test everything?

Manual testing is time consuming, error prone, and let’s face it, painful to do. Test automation of acceptance tests is one of the biggest contributors to a successful Dev Ops team.