Sure ways to fail #2 – Not knowing what the goal is

1 Reply

“If you don’t know where you going, any road will take you there” – The Cheshire Cat in Alice in Wonderland

The_Cheshire_Cat_by_JTwilight97This quote from Alice in Wonderland is very insightful and I have quoted it many times when talking about strategies and plans. In this case I want to use this as an illustration for a way an Agile project will surely fail. If you don’t know what the goal line is for a specific release or sprint, you have no means to understand how you are travelling and whether you are on the right track. I have seen many teams post great velocities in their first couple of sprints, but when asked whether they can achieve the release goal they have no idea. This is painful and leads to a lot of anxiety for the team and stakeholders.

How does this happen? I believe that this is due to the fact that in Agile we don’t want to spend too much time planning and estimating too much to the future and hence start kicking off projects really quickly. We do this with just the first one or two sprints worth of stories ready for implementation and then we keep grooming the backlog. This is great, but if you choose to do so, I think you need to spend a little bit of extra time to give the team a final goal. You don’t need to have all the stories for the release, after all we want to be flexible in Agile, but you should have some idea of the things you need to deliver. This can be stories, themes, epics, features or whatever you choose. At this stage you should do a quick estimation to provide the overall scope for the release and a goal line that the team can use in their burn-up graphs (read more on reporting here). You can then track changes to the goal line if epics require more stories than expected or if any new scope is introduced. This allows the team to have meaningful discussions with the product owner and the stakeholders about required changes to the release. If you don’t have such a goal line, you could get a shock surprise towards the end of your release and surprises are not something we want with Agile delivery.

The one caveat is if you work in a project that truly does not know what the scope is or the scope is undefined. What you can do in those cases is either work in a Kanban style or with an assumed target velocity. If you work in Kanban you only ever have to worry about the first few items in your backlog and set expectations with your stakeholders on how long they will take and then do the same for the next set of stories on a regular cadence. This requires a lot of trust between the team, product owner and stakeholders. Alternatively you can set yourself a certain target velocity and just work towards that and fill the velocity with stories that are getting groomed on an ongoing basis.

Employee Engagement – The magic potion?

Leave a reply

thumb-422558_1280I am sure by now most people understand that there is strong correlation between employee satisfaction and business results. If you need more convincing have a read of these two articles: Forbes & Research Paper

So how do you best go about measuring it?

On my current project I have decided to go with the following 4 questions:

  • I would recommend this account and my project as a good place to work
  • I have the tools and resources to do my role well
  • I rarely think about rolling off this account or project
  • My role makes good use of my skills and abilities

For those of you who have read Jez Humble’s “Lean Enterprise”, these questions will look familiar. I have adopted them to the project setting that I work within. We have just set out on a cultural transformation to become truly Agile and adopt DevOps in a large complex legacy environment. To me measuring the above will give me the best indicator that we are doing the right thing. Of course there will be other measures who determine the quality of the outcomes and the levels of automation among others, but changing the culture of an organisation is critical if your Agile and DevOps adoption is to be successful. I will report back throughout that journey to tell you what my experiences is with the above questions.

IT delivery is complex and it is not always clear what the right solution is. I found in the past that it is near impossible to create processes and tools that work by itself, you need to have the right mindset that people use the processes and tools with the right intent. It’s very frustrating when you implement great automation only to see a few months later that the solution has degraded. It is with hindsight that I understand that the solution is to not just implement process and tools but to instill the right culture and mindset for progression,
a culture where we blamelessly identify a way to avoid the same mistake again rather than looking for the person in fault,
a culture where we strive for automation and lean processes and are not concerned about the size of our teams or budgets,
a culture where you don’t have to protect your fiefdom and where you are happy to collaborate with others to solve problems no matter where the root cause lies.

I think we all in IT need to understand this dynamic between employee satisfaction and outcomes better, I for sure believe that I have come across a magic potion that I aim to bring to all my future projects.

What computer games can teach us about maturity models – Choose your own DevOps Adventure

2 Replies

To use maturity models or not is an eternal question that Agile and DevOps coaches struggle with. We all know that maturity models have some weaknesses, they can easily be gamed if they are used to incentivise and/or punish people, they are very prone to the Dunning-Kruger effect and often they are vague. Of course on the flipside, maturity models allow you to position yourself, your team or your company across a set of increasingly good practices and striving for the next level could be the required motivation to push ahead and implement the next improvement.

Clearly there are different reasons behind different kinds of maturity models. For a self-assessment and to set a roadmap, a traditional maturity model like the Accenture DevOps maturity model is what it takes to get these done. There are many others available on the internet, so feel free to choose the one you like best.

At one of my recent clients we performed many maturity assessments across a wide variety of teams, technologies and applications. Of course such large scope means that we did not spend a lot of time with each team to assess the maturity and not surprisingly the result was that we got very different levels of response. We heard things like “Of course we do Continuous Integration, we have Jenkins installed and it runs every Saturday”, had this team not mentioned the second part of the sentence we would have probably ticked the Continuous Integration box on the maturity sheet.

A few months later we were back in the same situation and needed to find a way to help teams self-assess their maturity in an environment where a lot of DevOps concepts are not well known and different vendors and client teams are involved which means the actual maturity rating becomes somewhat political. I was worrying about this for a while and then one night while playing on my PC, inspiration hit me – I remembered the good old Civilisation game and the technology tree:

techtree_original

Now if I could come up with a technology tree just like this for DevOps I might be able to use this with teams to document the practices they have in place and what it takes to get the next practice enabled. Enter the DevOps technology dependency tree (sample below):

CD Technical Dependencies Tree

In this tree for each leaf we created a definition and related metrics and now each team could go off and use this tree to chart where they are and how they progress. This way each team chooses their own DevOps adventure. We also marked capabilities that the company needed to provide so that each team could leverage common practices that are strategically aligned (like a common test automation framework or deployment framework). This tree has been hugely successful at this specific client and we continue to update it whenever we find a better representation and believe new practices should be represented.

Who would have thought that playing hours of computer games would come in handy one day…

One on Ones or “Get to Know Your Team”

2 Replies

adviceAfter blogging about advice for individual contributors and performance rating preparation, I will spend the next few months blogging about good practices for supervisors. This is close to my heart as I fully subscribe to what a former boss once told me: “There is no point complaining about our work culture, start with your part of the organisation and make it a great place to work. The further you get up the ladder and the more people you influence the more you can influence the work culture for the better”. I think this is a fantastic point of view and over the next few months I will share with you what I think makes a good supervisor and how certain supervisor behaviours can
help make your company a great place to work for their direct reports. Hopefully these posts will reach many supervisors and help them to be more effective while improving the team’s performance and satisfaction.

Here is a quick overview of the upcoming blog posts:
1. One on Ones (this post)
2. Feedback (TBD)
3. Coaching (TBD)
4. Delegation (TBD)
5. Principles for success (TBD)
6. Pitfalls for supervisors (TBD)

All these posts are heavily influenced by my friends over at www.manager-tools.com. Go check them out for more details on how to be great supervisor.

Okay, let’s get into One on Ones. In my view this is one of the most important practices for a supervisor. Having a good relationship with the people in your team is very important. One-on-ones give you the chance to get to know your team, to learn about them as an individual and to help them get better on a regular basis. This regular touch point will also mean that you will have a better chance to identify when something is not right, perhaps a problem at home or at work that impacts the individual. Because you speak to them one on one, you will be better able to recognise if their behaviour changes or if they start talking differently about work. Take an interest in the person you are working with, it will pay back many times during your career. People don’t leave companies, people leave supervisors. Reflect on this and understand how important your relationship is.

The purpose of the one-on-one is to get to know your team better and to build strong relationships with the individuals in the team. It is NOT a status meeting but yes you will often talk about work, after all this is what you both have in common, but the one-on-ones you spend investing in the relationship will be the ones that really count. Remember that the focus is on your direct report and what they want to talk about, not on you and what you would like to tell them. This can be difficult at times and hence the format should start with the individual, which will force you to focus on their concerns first.

The format is 30 min every week – 10 min for your direct report, 10 min for you, 10 min for coaching/feedback or in general looking forward to what is happening next. In reality you will spend most one-on-ones with your direct report’s topic and your section and won’t get to the coaching/feedback part.

So how do you do it: Schedule a weekly 30 minutes meeting with each of your direct reports. Make it recurring so that it is always in your calendar. Take notes during the meeting. These
notes will come in handy between meetings to follow up on action items and they can also become helpful when it is performance evaluation time as a record of their achievements and the feedback you have given. I sometimes struggle to focus on the non-work aspects, so for me it is a conscious effort to make small talk. I use a feedback form to take notes, which also acts as a reminder in these sessions to focus on the individual and not the work. I also write reminders for myself to focus on listening over talking. It does help! (If you are interested reach out to me directly and I will send you my form). Make sure you remember your direct report’s family names and any other personal details they share. The agenda should always start with your direct report given a chance to talk about whatever they want to talk about. You get the second half of the one-on-one and if your direct report runs over time, that’s okay. It’s important that you make this time regularly. Don’t cancel it regularly and don’t move it around too often – this sends a clear message of the priority of these meetings if you don’t make the time for them. Show them that these one-on-ones are important to you.

Frequently asked questions:
Q:What if my direct report just keeps talking and I don’t get the chance to tell him
the things I need to tell him?
A: Don’t sweat it, let him have the time. You are his supervisor after all so you can always grab him another time during the day to talk to him about what you want.

Q: My direct treats the one-on-ones as a status meeting and does not share anything
personal?
A: That’s okay, give it some time. Over time he might get more comfortable in these meetings and will start becoming more informal. If not, then this is still a meeting that improves your relationship and shows that you are there to listen.

Q: I am not in the same city as my direct report or I am travelling intermittingly?
A: You can definitely do this over the phone or even better over video conference.

Continue reading more about my advice to improve your performance and the performance of your team:
20 principles for a successful start to a career

Agile Reporting at the enterprise level (Part 2) – Measuring Productivity

4 Replies

productivityThose of you who know me personally, know that nothing can get me on my soapbox quicker than a discussion on measuring productivity. Just over the last week I have been asked three times how to measure this in Agile. I was surprised to notice that I had not yet put my thoughts on paper (well in a blog post). This is well overdue so here I share my thoughts.

Let’s start with the most obvious: Productivity measures output and not outcome. The business cares about outcomes first and outputs second, after all there is no point creating Betamax cassettes more productively than a competitor if everyone buys VHS. Understandably it is difficult to measure the outcome of software delivery so we end up talking about productivity. Having swallowed this pill and being unable to give all but anecdotal guidance on how to measure outcomes, let’s look at productivity measurements.

How not to do it! The worst possible way that I can think of is to do it literally based on output. Think of widgets or java classes or lines of code. If you measure this output you are at best not measuring something meaningful and at worst encouraging bad behaviour. Teams that focus on creating an elegant and easy to maintain solution with reusable components will look less productive than the ones just copying things or creating new components all the time. This is bad. And think of the introduction of technology patterns like stylesheets, all of a sudden for a redesign you only have to update a stylesheet and not all 100 web pages. On paper this would look like a huge productivity loss, updating 1 stylessheet over updating 100 pages in a similar timeframe. Innovative productivity improvements will not get accurately reflected by this kind of measure and teams will not look for innovative ways as much given they are measured on something different . Arguably function points are similar, but I have never dealt with them so I will reserve judgement on this until I have firsthand experience.

How to make it even worse! Yes, widget or line of code based measurements are bad, but it can get even worse. If we have done measurements on this we do not incentivise teams to look for reuse or componentisation of code, and we are also in danger of destroying their sense of teamwork by measuring what each team member contributes. “How many lines of code have you written today?” I have worked with many teams where the best coder writes very little code and that is because he is helping everyone else around him. The team is more productive by him doing this than by him writing lots of code himself. He multiplies his strength rather than linearly growing the team’s productivity by doing more himself.

Okay, you might say that this is all well and good, but what should we do? We clearly need some kind of measurement. I completely agree. Here is what I have used and I think this is a decent starting point:

Measure three different things:

  • Delivered Functionality – You can do this by either measuring how many user stories or story points you deliver. If you are not working in Agile, you can use requirements or use cases or scenarios. Anything that actually relates to what the user gets from the system. This is closest to measuring outcome and hence the most appropriate measure. Of course these items come in all different sizes and you’d be hard pressed to strictly compare two data points but the trending should be helpful. If you did some normalisations of story points (another great topic for a soapbox) then that will give some comparability.
  • Waste – While it is hard to measure productivity and outcomes, it is quite easy to measure the opposite: waste! Of course you should contextually decide which elements of waste you measure and I would be careful with composites unless you can translate this to money (e.g. all the waste adds to 3MUSD, not, we have a waste index of 3.6). Composites of such diverse elements such as defects, manual steps, process delays and handovers are difficult to understand. If you cannot translate these to dollars, just choose 2 or 3 main waste factors and measure them. Once they are good find the next one to measure and track.
  • Cycle time – This is the metric that I would consider above all others to be meaningful. How long does it take to get a good idea implemented in production? You should have the broadest definition that you can measure and then break it down into the sub-components to understand where your bottlenecks are and optimise those. Many of these will be impacted by the levels of automation you have implemented and the level of lean process optimisation you have done.

This is by no means perfect. You can game these metrics just like many others and sometimes external factors influence the measurement, but I strongly believe that if you improve on these three measures you will be more productive.

There is one more thing to mention as a caveat. You need to measure exhaustively and in an automated fashion. The more you rely on just a subset of work and the more you manually track activities the less accurate these measures will be. This also means that you need to measure things that don’t lead to functionality being delivered, like paying down technical debt, analysing new requests for functionality that does not implement or defect triage. There is plenty of opportunity to optimise in this space – Paying technical debt down quicker, validating feature requests quicker, reducing feedback cycles to reduce triage times of defects.

For other posts of the Agile reporting series look here: Agile Reporting at the enterprise level – where to look? (Part 1 – Status reporting)

Here is a related TED talk about productivity and the impact of too many rules and metrics by Yves Morieux from BCG

Waterfall or Agile – Reflections on Winston Royce’s original paper

7 Replies

If you are like me, at some stage you learned about the Waterfall methodology. Often the source of the waterfall methodology is attributed to Winston Royce and his paper: “Managing the Development of Large Software Systems”. Recently I have heard many people speak about this paper and imply that it has been misunderstood by the general audience. Rather than prescribing Waterfall it was actually recommending an iterative (or shall we call it Agile?) approach. I just had to read it myself to see what is behind these speculations.

I think there is some truth to both interpretations. I will highlight four points of interest and provide a summary afterwards:

  • Fundamentals of Software Development –
    I like the way he starts by saying that fundamentally all value in softwareroyce 2
    delivery comes from a) analysis and b) coding. Everything else (documentation,
    testing, etc.) is required to manage the process and customers would ideally
    not pay for those activities and most developers would prefer not to do them.
    This is such a nice and simple way to describe the problem. It speaks to the
    developer in me.
  • Problems with Waterfall Delivery – He then goes on to describe how the Waterfall model isroyce waterfall fundamentally flawed and how in reality the stage containment is never successful. This pictures and the caption is what most Agile folks use as evidence: “Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps.” So I think he again identifies the problem correctly based on his experience with delivery at NASA.
  • Importance of Documentation – Now he starts to describe his solution to the waterfall problem in five steps. I will spare you the details, but one important point he raises is documentation. To quote his paper “How much documentation? My own view is quite a lot, certainly more than most programmers, analysts or program designers are willing to do…” He basically uses documentation to drive the software delivery process and has some elaborate ideas on how to use documentation correctly. A lot of which makes complete sense in a waterfall delivery method.
  • Overall solution – At the end of the paper he provides his updated model and I have to sayroyce 3 it looks quite complicated. To be honest many of the other delivery frameworks like DAD or SAFe look similarly complicated and we should not discount it just for that reason. I did not try to fully understand the model, but it is basically a waterfall delivery with a few Agile ideas sprinkled in: Early customer involvement, having two iterations of the software to get it right and a focus on good testing.

Summary – Overall I think Winston identifies the problems and starts to think in an Agile direction (okay Agile didn’t exist then, but you know what I mean). I think his
approach is still closer to the Waterfall methodology we all know but he is going in the right direction of iterations and customer involvement. As such, I think his paper is neither the starting point of the Waterfall model nor the starting point of an Agile methodology. I think a software archaeologist would see this as an inbetween model that came before its time.

DevOps in Scaled Agile Models – Which one is best?

3 Replies

DevOps in ScaledAgileI have already written about the importance of DevOps practices (or for that matter Agile technical practices) for Agile adoption and I don’t think there are many people arguing for the contrary. Ultimately, you want those two things to go hand in hand to maximise the outcome for your organisation. In this post I want to have a closer look at popular scaling frameworks to see whether these models explicitly or implicitly include DevOps. One could of course argue that the Agile models should really focus on just the Agile methodology and associated processes and practices. However, given that often the technical side is the inhibitor of achieving the benefits of Agile, I think DevOps should be reflected in these models to remind everyone that Software is being created first and foremost by developers.

Let’s look at a few of the more well known models:

SAFE (Scaled Agile Framework) – This one is probably the easiest as it has DevOps being called out in the big picture. I would however consider two aspects of SAFe as relevant for the wider discussion, the DevOps team and the System Team. While the DevOps team talks about the aspects that have to do with deployment into production and the automation of the process, the System Team focuses more on the development side activities like Continuous Integration and Test automation. For me there is a problem here as it feels a lot like the DevOps team is the Operations team and the System Team is the Build team. I’d rather have them in one System/DevOps team with joint responsibilities. If you consider both of them as just concepts in the model and you have them working closely together then I feel you start getting somewhere. This is how I do this on my projects.

DAD (Disciplined Agile Delivery) – In DAD, DevOps is weaved into the fabric of the methodology but not as nicely spelled out as I would like. DAD is a lot more focused on the processes (perhaps an inheritance from RUP as both are influenced/created by IBM folks). There is however a blog post by “creator” Scott Ambler that draws all the elements together. I still feel that a bit more focus on the technical aspects of delivery in the construction phase would have been better. That being said, there are few good references if you go down to the detailed level. The Integrator role has an explicit responsibility to integrate all aspects of the solution and the Produce a Potentially Consumable Solution and Improve Quality processes call out many technical practices related to DevOps.

LESS (Large Scale Scrum) – In LESS DevOps is not explicitly called out, but is well covered under Technical Excellence. Here it talks about all the important practices and principles and the descriptions for each of them is really good. LESS has a lot less focus on telling you exactly how to put these practices in place, so it will be up to you to define which team or who in your team should be responsible for this (or in true Agile fashion perhaps it is everyone…).

In conclusion, I have to say that I like the idea of combining the explicit structure of SAFE with the principles and ideas of LESS to create my own meta-framework. I will certainly use both as reference going forward.

What do you think? Is it important to reflect DevOps techniques in a Scaled Agile Model? And if so, which one is your favourite representation?

8 DevOps Principles that will Improve Your Speed to Market

Leave a reply

I recently got asked about the principles that I follow for DevOps adoptions, so I thought I’d write down my list of principles and what they mean to me:

  • Test Early & Often – This principle is probably the simplest one. Test as early as you can and as often as you can. In my ideal world we find more and more defects closer to the developer by a) running tests more frequently enabled by test automation, b) providing integration points (real or mocked) as early as possible and c) minimising the variables between environments. With all this in place the proportion of defects outside of the development cycle should reduce significantly.
  • Improve Continuously – This principle is the most important and hardest to do. No implementation of DevOps practices is ever complete. You will always learn new things about your technology and solution and without being vigilant about it, deterioration will set in. Of course the corollary to this is that you need to measure what you care about, otherwise all improvements will be unfocused and you will be unable to measure the improvements. You should measure metrics that best represent the areas of concern for you, like cycle time, automation level, defect rates etc.
  • Automate Everything – Easier said than done, this is the one most people associate with DevOps. It is the automation of all processes required to deliver software to production or any other environment. For me this goes further than that, it means automating your status reporting, integrating the tools in your ecosystem and getting everyone involved to focus on things that computers cannot (yet) do.
  • Cohesive Teams – Too often I have been in projects where the silo mentality was the biggest hindrance of progress, be it between delivery partner and client, between development and test teams or between development and operations. Not working together and not having aligned goals/measures of success is going to make the technical problems look like child’s play. Focus on getting the teams aligned early on in your process so that everyone is moving in the same direction.
  • Deliver Small Increments – Complexity and interdependence are the things that make your cycle time longer than required. The more complex and interdependent a piece of software is, the more difficult it is to test and to identify the root cause of any problem. Look for ways to make the chunks of functionality smaller. This will be difficult in the beginning but the more mature you get, the easier this becomes. It will be a multiplying effect that reduces your time to market further.
  • Outside-In Development – One of the most fascinating pieces of research I have seen is by Walker Royce about the success of different delivery approaches. He shows that delays are often caused by integration defects that are identified too late. They are identified late because that’s the first time you can test time in an integrated environment. Once you find them you might have to change the inner logic of your systems to accommodate the required changes to the interface. Now imagine doing it the other way around, you test your interfaces first and once they are stable you build out the inner workings. This reduces the need of rework significantly. This principle holds for integration between systems or for modules within the same application and there are many tools and patterns that support outside-in development.
  • Experiment Frequently – Last but not least you need to experiment. Try different things, use new tools and patterns and keep learning. It’s the same for your business, by using DevOps you can safely try new things out with your customers (think of A/B testing), but you should do the same internally for your development organisation. Be curious!

If you follow these 8 principles I am sure you are on the right track to improve your speed to market.

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.