Minimising risk through Agile service lifecycle
Although many organisations realised how important it is to adopt agile ways of working, and what the benefits of business agility are, it is still very challenging to gather all business requirements and insights from user research to inform better decisions. Usually, in this phase, many of us rush as we want to deliver value […]
How to start Agile Transformation
Transitioning to agile ways of working is not easy. The transition may take a long time and the results may not be visible straight away because changing people’s mindset and culture doesn’t happen overnight. It is important to realise the benefits of Agile transformation and the reasons for it. Many teams start adopting agile ways […]
Agile: Beyond the buzzwords
This section of the Agile series is going to run through some of the most common buzzwords and potential pitfalls we see on a regular basis when we look at agile ways of working. The core values are simple but it can get complicated when terminology overrules principles. When we see teams who do regular […]
Agility, moving beyond agile methodologies for business goals
This is the second blog of our agile series by Iwona Winiarska, for part one click here. Many organisations need to keep up with the changing environment: shifting business priorities, changing technology solutions or more demanding user needs. As a result, they need to change their old ways of working to become more nimble, adaptive […]
Defining ‘Agile’ with Iwona Winiarska
This is the first in a series of Agile business blogs by Iwona Winiarska, a renowned Agile Delivery Manager and Coach who we were delighted to welcome onboard at Automation Logic in January 2019. An agile approach is an alternative to other project management methodologies such as Waterfall used for delivering projects and building products […]
Leadership Team Development at AL with Georg Fasching
At AL we regularly post blogs discussing our passion for growing and maintaining a great Company culture, living our values and keeping our people and our clients at the heart of all we do. In fact our two founders described their views just recently when being interviewed about what it meant to them to place […]
Lance Armstrong on DevOps
What lesson does Lance Armstrong teach the DevOps Community? Cheat to win…
In cloud service provisioning and management, we’ve all been shown a shiny vision of the future from the likes of Netflix, Twitter and Facebook, where services are provisioned in an instant then continuously tested, upgraded and healed. Sometimes it’s like watching the unstoppable US Postal Team (the “Blue Train”) in the early 2000’s. We strive to emulate them, and struggle to keep up. How do they do it? Well, it turns out they cheat.
Cheat is perhaps a bit strong, but they certainly side-step a lot of problems that the rest of us have to deal with, and by ‘us’ I mean those that have been running IT operations in enterprises older than 10 years. Yes, I’m talking legacy here, legacy and other mill stones like regulation, auditing and compliance. Try winning the tour on a Raleigh Chopper where you are stopped every 10k and someone checks that your bike is still legal. EPO anyone?
Well with the exception of coffee, most of the drugs I enjoy are performance hindering, so if blood doping is out of the question, what you can you do? Fortunately all is not lost, and there are several actions you can take to stay with the peleton.
1. Tools: Change your bike
Sorry Lance, but it IS about the bike, at least partially.
You can’t implement this new, faster, more agile style of delivery with antiquated tooling. I often stress that there is too much focus on tools at the expense of process and culture, and whilst I still believe that, tooling can’t be ignored completely. Tools change what is possible in terms of process and can reinforce both good and bad culture, so if your tools aren’t empowering you to effect the change you want, swap them out. Note I’m talking about your service provisioning and management tools here, not the underlying technology of the service themselves (dealing with that kind of legacy is something for another post).
2. Getting Started: Pick your race.
Your first race shouldn’t be Le Tour, you’ll blow up on the Alp D’huez. Leverage a key principle of DevOps for smaller and more frequent releases to gradually build your team’s capability. Even within an agile methodolgy, keep your first few sprints short and not too ambitious, after all, you’ll be getting used to your new bike. Set a sprint goal for something that’s not too technically challenging, yet delivers clear value, is measurable and demonstrable back to the business. Building your team’s confidence with early successes is crucial, you’ll soon find your cadence naturally increases.
3. Data Driven: Adopt a scientific method.
Gone are the days of cigarettes and cognac for lunch, every cycle team now measures everything going on with both bike and rider with a view to making the team go faster and so should you. It’s often a bit of chore to begin with but collecting data on your agile delivery process is an essential discipline which will quickly delivery rewards. You’ll be able to spot blockages and measure the effects of trying something different, all will help increase your delivery speed. If it isn’t measured, it doesn’t get better.
4. Accelerate: Get a coach.
The best athletes get there by learning from and working with the best coaches. Those that have been there and done it, often many times over, and whose only goal now is to pass on their hard earned knowledge from their years on the professional circuit.
Here at Automation Logic we have unparalleled experience in applying this emerging field within very large enterprises. Even if you know where you want to go, we can get you there faster and straighter. We know the racing line, and we know where the potholes are! We’ll help you build a team, train them and keep your tools at optimum performance. Perhaps most importantly, we’ll help you adapt agile principles so they work for you and your specific situation (legacy, regulation etc.). Often the most important decision you’ll make is where to allow exceptions to agile principles so they work in large organisations.
Good luck, cheat to win!
With Agile and DevOps there is no Hiding Place for the Incompetent.
This is one of the hardest issues to tackle and I am not sure I have an answer.
I coined a phrase after the particular engagement that brought me down to earth with a bump, the phrase is ‘ volume and frequency don’t make competence’
In all organisations there are people who voice an opinion, some speak loudly and some speak often. Some of these types are good and some not so. Some people have real expertise but for some reason don’t want to come forward.
I have come to realise that the proof is in the pudding.
Again Agile and DevOps can be your friends here. If you are working closely with the business to define, develop and deliver something in a small team there is no hiding place. The business owner will be interacting on a daily basis with everyone in the team and the real experts, the people with the ability to lead and the people with the ability to solve complex problems will come to the fore. Similarly, the day to day dynamic of the project will also expose those that are the true “team players” – those for whom the overall success of the project is of far greater importance than any personal kudos or reward. Rooting out those only in it for themselves becomes of even greater importance in an Agile and DevOps world.
In huge organisations I am not sure it will ever be possible to really appreciate the true experts, the ones you can rely on to deliver. I therefore look forward to more enterprises adopting Agile and DevOps, creating smaller teams within teams so that eventually the best will bubble to the top. With Agile and DevOps there is no Hiding Place for the Incompetent.
Bimodal IT: and other Snakeoil
I presented my critique of Bimodal IT at DevOps days this week, it was a fun talk to give with some great questions from the audience; all in all a very well run event. This post is summary of that talk.
tldr; Bimodal IT has an initial allure due to its simplicity but it fails to deliver on its two main aims: lowering risk for critical systems and securing innovation for new digital services. As if that wasn’t bad enough, its cultural poison.
For those not familiar with the main thrust of Gartner’s “Bimodal IT”:
“Bimodal IT is the practise of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and non-linear, emphasizing agility and speed”
So your Mode 1 services have been around for a while, they are mission critical, and they contain the important data that is of central importance to your organisation (your customer data, your trading platforms, yours systems of record). Meanwhile your Mode 2 services are new, they can break (it’s a beta!) but they are redefining how you engage with your customers and you need to get them out there fast, before you competition does.
The Problem with “Protected” Innovation
Let’s start with innovation. Bimodal IT is supposed to give your agile teams the free hand it needs to create the new products and services that your business needs to deliver if its even going to have the luxury of managing the legacy software of tomorrow.
But in our experience this type of ‘protected’ innovation lasts about as long as a vase of flowers, you get an initial blooming, and then death. Why? Because your innovation isn’t taking place in an ecosystem that allows it to take root.
What do I mean by ecosystem here? Well, how many services within any large organisation operate in complete isolation? I would hazard, none. They all have dependencies or in some way interact with other services as part of their normal operation. And where do all these related services reside? They are much more likely to be in our “Mode 1” environment simply because, if your an organisation is anything other than a startup, you’ll have *way* more services that display Mode 1 characteristics than you’ll have new, “Mode 2” services. Furthermore, age also makes it even more like that these existing “Mode 1” services will contain the critical data that you need to get to give your new “Mode 2” service a chance of becoming a real innovation in the marketplace and not just an app that puts hats on cats*
To be fair to Gartner, their Bimodal approach does allow for some limited data exchange between the two modes, but if we’ve decided that we aren’t going to tackle fully modernising these “Mode 1” services (because we’re focused on stability) but we are going to couple them to our new digital services, then the evolution of everything along the value chain will slow down to the pace that can be supported by the slowest component, our “Mode 1” service. The assumption here is that we need everything to move at the same pace and I’ve had many an argument where I’ve been told there will be no problem with the “Mode 1” dependency because we’ll ‘stick an API in front of it’, but the point here is that we’re operating in an environment of high uncertainty, so we have no idea what we’ll even want from an API to a dependant service at this point, we need to iterate the API as well.
So we just hitched up our supercar to a supertanker. We just killed innovation.
Risk Vs. Change
Oh well, at least we did our utmost to safeguard our existing critical services, by not compromising the processes that protect them right? Not really, sorry.
If we fail to keep an open mind and explore some, admittedly sometimes counter-intuitive, ideas around risk vs. change, we are missing out on opportunities to better protect our critical services.
The central (false) assumption around risk with Bimodal IT is that more change means more risk, but there is strong evidence that more change can and actually does lower risk.
How? Well regular change of an IT system generally means that the content of any one change will be smaller. And a small change will tend to have less risk associated with it than a large one. Another way of looking at it is that a small change will tend to have a smaller ‘blast radius’ in the event that the changes goes bad, as well as a lower mean time to recovery (MTTR), a common measure of how quickly you can roll-back or otherwise fix a failure.
Smaller blast radius, faster MTTR combined with the fact that a team which performs changes regularly will get better at it (further reducing the chance of error), means that smaller, frequent changes actually LOWERS risk, not increases it.
Jez Humble has done a lot of great thinking and research on this and I’d highly recommend any of his writing.
So, I hope that’s enough to get you thinking that Bimodal IT may not hold as much promise as a strategy as you might initially think. In my next post I’ll try and put the final nail in the Bimodal coffin by relaying some of our experiences on the cultural impacts of Bimodal IT.
As a technical strategy, it’s snakeoil, but as a way to organise your teams, it really is poison...
* there are some great apps that do this though 🙂
Want to see the slides I used at DevOps Days? Here you go..
Want to work with us?
If you'd like to find out more about joining our growing team of engineers, consultants, strategists and evangelists for automation, please get in touch with a member of our team.Get in touch