Skip to Content

Bringing in the Agile mindset to old-fashioned maintenance contracts

Sogeti Labs
October 26, 2016

I received a serious wake-up call just a couple of weeks ago

It started with me being given the responsibility for a team of maintenance engineers dealing with old-fashioned maintenance contracts. The team was located across India and the Netherlands and a majority of the applications they were dealing with were developed years ago and maintained using traditional waterfall models.

As a true-blue believer in Agile, I wanted to change from the traditional way of working towards a more agile mindset. That immediately gave rise to a host of problems as all the conditions for implementing agile were either absent or very difficult to implement. Anyhow, as the team and the customers started getting enthusiastic, we started implementing a number of agile practices at work. Given the global nature of our team, we paid particular attention to the technological requirements that would support such practices. We set up stand-up calls, made a backlog and planned sprints. Then we got to work…

…and that is when the troubles started. The stand-up call was dominated by the Dutch team members. The information shared was done in solely those 15 minutes of the stand-up call. And of course, the planned sprint became  a mini-waterfall and ended up combining all the bad things from both waterfall as well as agile. The team members started to blame each other for everything that was going wrong and the customer had no clue of what was going on.

In other words, it was a disaster and also, a perfect ground to learn lessons.

So how does one deal with maintenance contracts of such legacy applications,especially when the teams dealing with it are geographically distributed? There are situations where the customers are interested in reaping the benefits of agile and DevOps, even though the applications are at a stage of life where there is no continuous development anymore. In other words, the basic conditions for agile or DevOps are not there, development happens maybe once or twice a year and yet the customer requests benefits like faster time to market, dedicated teams and increased business value.

Fortunately, I have seen a few such cases in the past. Based on my experiences, here are a few broad steps/actions that can help optimize such situations:

  1. Putting in place the required infrastructure: If you want a multi-functional team in different locations to work on the same source code, you must put in place the infrastructure that allows this to happen. I am talking about things like environments in the cloud, automated testing and very good Video conference appliccationsThis is especially true when we are talking about teams distributed across different locations.This is the first step towards ensuring that agile practices can be properly implemented. The infrastructure in place must make sure that continuous contact is possible not just by phone but through an interface where people can see each other. The ‘agile mindset’ means not just calling in on scheduled times like daily standup but having the team work as one with every single person being responsible for adding value to the customers business.
  2. Paying attention to culture: Changing the culture of teams that have long been used to a waterfall model can be a huge challenge. Yet, this is one of the most critical factors for the success or failure of agile and DevOps in any organization.For instance, in the current team that I am handling, one of the most difficult challenges we faced was in making everyone feel part of the same team and feel comfortable talking to each other as well as raising alerts. We tackled this by sessions on the different cultures. And have contact with each other learning to know each other. Get away from the business.Another step we took was to directly involve the customer in our meetings and work. For teams that have been used to working under the waterfall model, where they take in a change request from the customer, work on it for months and finally put it in the production environment and wash their hands off it, this change can be tough to make. However, the agile mindset requires testing within a very short period of time, or even testing while developing it.  This requires a complete change of work culture along with very active participation from the customer. This again underscores the need for high-quality infrastructure not just internally but also between the team and the customer.Consolidating development work within dedicated teams As already mentioned, such maintenance projects do not involve a continuous flow of development work but rather a few such requests in a year. To deal with these sort of workflows, it is better to consolidate all the development work across multiple applications within single dedicated development teams.
  3. You need team members with a mix of different skills and talents: Once you have started implementing agile principles in your team, you need people who have knowledge of multiple applications and skill sets. The traditional maintenance work is not sufficient to form dedicated teams per applications. This is a larger challenge for the team! It requires proper hiring, training and planning.

Coming back to the wake-up call which started this post, I am glad to report that we are putting in place almost all of the points given above and are already seeing specific, measurable improvements in our work.

The points given above are in no way a comprehensive list but just a start towards implementing the agile mindset in such scenarios. The way you choose to tackle such issues in your team will definitely differ depending upon your particular circumstances. There is no one right way to move towards DevOps and agile and in fact, under DevOps making mistakes is not just allowed but celebrated! So one of the first things I did after our first few disastrous sprints was to set up a mini-celebration before we kick-started our transformation journey.

Just another reason why I love the agile and DevOps way of working!

About the author

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

    Comments

    Leave a Reply

    Your email address will not be published. Required fields are marked *