Monthly Archives: January 2015

Working with SIs in a DevOps/Agile delivery model

1 Reply

In this blog post (another of my DevOps SI series), I want to explore the contractual aspects of working with SI (System Integrator). At the highest level there are three models that I have come across:

  • Fixed Price contract – Unfortunately these are not very flexible and usually require a level of detail to define the outcome, which is counterproductive for Agile engagements. It does however incentivise the SI to use best practices to reduce the cost of delivery.
  • Time and Material – This is the most flexible model that easily accommodates any scope changes. The challenge for this one is that the SI does not have an incentive to increase the level of automation because each manual step adds to the revenue the SI makes.
  • Gain Share – This is a great model if your SI is willing to share the gains and risks of your business model. While this is the ideal model, often it is not easy to agree on the contribution that the specific application makes to the overall business.

So what is my preferred model? Well let me start by saying that the contract itself will only ever be one aspect to consider, the overall partnership culture will likely make a bigger impact than the contract itself. I have worked with many different models and have made them work even when they were a hindrance for the Agile delivery approach. However, if I had to define a model that I consider most suitable (Ceteris Paribus – all other things being equal), I would agree on a time and materials contract to keep the flexibility. I would make it mandatory to do joint planning sessions so that both staff movements and release schedule are done in true partnership (it does not help if the SI has staffing issues the client is not aware of or the client makes any ramp-ups/ramp-downs the SI’s problem). I would agree on two scorecards that I would use to evaluate the partnership. One is a Delivery Scorecard, which shows the performance of delivery, things like: are we on track, have we delivered to our promises, is our delivery predictable. The second is an Operational Scorecard , which shows: the quality of delivery, the automation levels in place, the cycle times for key processes in the SDLC.

With these elements I feel that you can have a very fruitful partnership that truly brings together the best of both worlds.

How to support Multi-Speed IT with DevOps and Agile

5 Replies

These days a lot of organisations talk about Multi-Speed IT, so I thought I’d share my thoughts on this. I think the concept has been around for a while but now there is a nice label to associate this idea. Let’s start by looking at why Multi-Speed IT is important. The idea is best illustrated by a picture of two interlocking gears of different sizes and by using a simple example to explain the concept.

The smaller gear moves much faster than the larger one, but where the two gears interlock they gearsremain aligned to not stop the motion. But what does this mean in reality? Think about a banking app on your mobile. Your bank might update the app on a weekly basis with new functionality like reporting and/or improved user interface. That is a reasonable fast release cycle. The mainframe system that sits in the background and provides the mobile app with your account balance and transaction details does not have to change at the same speed. In fact it might only have to provide a new service for the mobile app once every quarter. Nonetheless the changes between those two systems need to align when new functionality is rolled out. However, it doesn’t mean both systems need to release at the same speed. In general, the customer facing systems are the fast applications (Systems of Engagement, Digital) and the slower ones are the Systems of Record or backend systems. The release cycles should take this into consideration.

So how do you get ready for the Multi-Speed IT Delivery Model?

  • Release Strategy (Agile) – Identify functionality that requires changes in multiple systems and ones that can be done in isolation. If you follow an Agile approach, you can align every n-th release for releasing functionality that is aligned while the releases in between can deliver isolated changes for the fast moving applications.
  • Application Architecture – Use versioned interface agreements so that you can decouple the gears (read applications) temporarily. This means you can release a new version of a backend system or a front-end system without impacting current functionality of the other. Once the other system catches up, new functionality becomes available across the system. This allows you to keep to your individual release schedule, which in turn means delivery is a lot less complex and interdependent. In the picture I used above, think of this as the clutch that temporarily disengages the gears.
  • Technical Practices and Tools (DevOps) – If the application architecture decoupling is the clutch, then the technical practices and tools are the grease. This is where DevOps comes into the picture. The whole idea of the Multi-Speed IT is to make the delivery of functionality less interdependent. On the flip side, you need to spend more effort on getting the right practices and tools in place to support this. For example you want to make sure that you can quickly test the different interface versions with automated testing, you need to have good version control to make sure you have in place the right components for each application, you also want to make sure you can manage your codeline very well through abstractions and branching where required. And the basics of configuration management, packaging and deployment will become even more important as you want to reduce the number of variables you have to deal with in your environments. You better remove those variables introduced through manual steps by having these processes completely automated.
  • Testing strategies – Given that you are now dealing with multiple versions of components being in the environment at the same time, you have to rethink your testing strategies. The rules of combinatorics make it very clear that it only takes a few different variables before it becomes unmanageable to test all permutations. So we need to think about different testing strategies that focus on valid permutations and risk profiles. After all, functionality that is not yet live requires less testing than the ones that will go live next.

The above points cover the technical aspects but to get there you will also have to solve some of the organisational challenges. Let me just highlight 3 of them here:

  • Partnership with delivery partners – It will be important to choose your partners wisely. Perhaps it helps to think of your partner ecosystem in three categories: Innovators (the ones who work with you in innovative spaces and with new technologies), Workhorses (the ones who support your core business applications that continue to change) and Commodities (the ones who run legacy applications that don’t require much new functionality and attention). It should be clear that you need to treat them differently in regards to contracts and incentives. I will blog later about the best way to incentivise your workhorses, the area that I see most challenges in.
  • Application Portfolio Management – Of course to find the right partner you first need to understand what your needs are. Look across your application portfolio and determine where your applications sit across the following dimensions: Importance to business, exposure to customers, frequency of change, and volume of change. Based on this you can find the right partner to optimise the outcome for each application.
  • Governance – Last but not least governance in very important. In a multi-speed IT world you will need flexible governance. One size fits all will not be good enough. You will need light-weight system driven governance for your high-speed applications and you can probably afford a more powerpoint/excel driven manual governance for your slower changing applications. If you can run status reports of live systems (like Jira, RTC or TFS) for your fast applications you are another step closer to mastering the multi-speed IT world.

The winding road to DevOps maturity

Leave a reply

curving road

I have noticed a trend in the evolution of teams when it comes to DevOps maturity over the years, which I now call the winding road of maturity. Recently I was using a DevOps model to describe the progress overtime, which I’ve designed a while ago and realised that with the advent of cloud based DevOps I have to update my model. So I thought I’d share my observations and see what other people think. Surprisingly this pattern is seen in a lot of different work environments: Deployment Automation, Test Automation and many others. I will use the deployment automation scenario here but believe me it applies in many other technical aspects as well.

 

Here is my current model, which I have shared with many clients and colleagues over time:

Curve 3Stage 1: “Do it All Manually” – We do everything manually each time. We do all the steps in our checklist for deployments or test or whatever it is that we consider to be our daily job. Not a lot of optimisation at this stage and it feels all very heavy-handed.
Stage 2: “Do the Necessary Manually” – Over time we realise that there are many steps that we can skip if we do a quick impact assessment and based on that assessment only execute the steps that are required (e.g. not redeploying unchanged components or not executing tests for functionality that has not changed). We are now in a world where each deployment looks different based on our assessments – this is difficult if there is a high turnover of resources or if transitioning to newbies as they wouldn’t have the skills/knowledge to do reliable assessments.
Stage 3: “Automate the one way” – Then we discover automation. However, automation of the impact assessments is more complicated than automating one common process, so we go back to running all steps each time. This reduces the effort for deployments but might impact the actual duration.
Stage 4: “Optimise for performance” – Once we have mastered automation we start to look for ways to optimise this. We find ways of identifying only the steps that are required for each activity and dynamically create the automation playbook that gets executed. Now we have reduced effort and are continuing to reduce overall duration as well. We are an optimising organisation based on reliable automation.
1. Stage “Do it All Manually” –

Here is where my story usually ended and I would have said that this is an optimising end-state and that we don’t really move around another curve again. However, I believe that Cloud-based DevOps goes one step further requiring me to update my model accordingly:
Curve 5In this new model we do everything each time again. Let me explain. In the scenario of deployment automation, rather than only making the required incremental changes to an environment we completely instantiate the environment (infrastructure as code). In the scenario of test automation, we create several environments in parallel and run tests in parallel to reduce time rather than basing a subset of tests on an impact assessments. We can afford this luxury now because we have reached a new barrier in my model, which I call the Cloud Barrier.

This update to my model was long overdue to be honest and it just comes to show that when you work with a model for a long time you don’t realise when it is out-dated and you just try to make it fit with reality. Well hopefully my updated model helps to chart out your organisational journey as well. It is possible to short-cut the winding road to maturity but as is the case with cycling up a mountain a short-cut will be much steeper and will require some extra effort. See you on the top of the mountain!

Picture: Hairpin Curve – Wikimedia
License: Creative commons

Manifesto-Mania – thoughts on the Half-Arsed Agile and the Anti-Agile manifesto

2 Replies

I came across the following two websites recently:

http://www.halfarsedagilemanifesto.org/

http://antiagilemanifesto.com/

And as is so often the case, when you have to smile about it, it hits too close to home. So I wanted to provide my perspective on these.

Let’s start with the Anti Agile manifesto (http://antiagilemanifesto.com/) – this one is just plainly ignoring the fact that Agile operates in a different cadence and requires a different structure to achieve it’s outcome. However many organisations do follow some of the points mentioned in this manifesto, where stand-ups turn into status meetings and stories are full use cases. Clearly someone who had to suffer from a bad Agile project put pen to paper here – take this as a sniff test if your Agile project is really agile. It is not if this manifesto is true for you.

The Half-Arsed manifesto (http://www.halfarsedagilemanifesto.org/) is different as it provides the challenges that many project teams are exposed to. It’s the tension between local optimisation of teams and organisation wide requirements. Let’s explore this a bit more in detail.

We have heard about new ways of developing software by
paying consultants and reading Gartner reports. Through
this we have been told to value:

Point taken – the Agile space is full of consultants, but hey so is every other space in IT. Let’s move to the next:

Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact

It is important to acknowledge that unfortunately in large organisations you do have mandatory tools and processes. Some of this you should challenge as an Agile team to get a better outcome (e.g. being allowed to use walls to post things even though it might not be “pretty”). Others are required for the sake of the organisation and should be respected. Imagine you are a senior product owner and each team is using a different tool to manage their sprints. You get pictures, excel sheets, links, etc. from your teams to understand their progress, remember this stakeholder is actually paying for your team and is making decisions about the direction of the company, don’t you want him to spend time doing that rather than digging through lots of different data sources? The term resources is terrible, I don’t think we should call people resource – full stop.

Working software over comprehensive documentation
as long as that software is comprehensively documented

I think this is nitpicking. it really comes down to what comprehensively means. In my view Agile teams need to create all the documentation that is required to use and maintain the software. Documentation that is not required in Agile projects is transition documentation that is required to get someone else to do work (e.g. detailed technical designs), they don’t provide value if the team sits together and/or talks every day.

Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control

Oh dear – this one clearly speaks to me. As someone working for a systems integrator I do depend on contracts and change control. I always aim to find a better solution, but there are commercial realities and this point is just try. Let’s find the most creative way to solve our problem while still having the required commercial framework in place.

Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely

Honestly, I am struggling with this one. Isn’t all of SCRUM based on a plan for how to manage change? And isn’t SCRUM about rigorously following the few mandatory ceremonies (at least until your are experienced enough to know why you are breaking the rules).

That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.

Yes – I am working in the enterprise world. And while everything here is a bit harder, I enjoy the challenge and bit by bit we can hopefully change the environment together. If we only accept the purest of Agile forms, we are making the perfect the enemy of the better. Don’t tell people that they are not Agile, help them get a bit better and a bit more agile.