DevOpsGuys offers services to the UK Public Sector via the latest G-Cloud 8 Framework Agreement

4th August 2016

DevOpsGuys today announced that its range of services will be available to public sector clients via the latest Crown Commercial Service (CCS) G-Cloud 8 Framework Agreement. This will allow DevOpsGuys to supply a wide range of Infrastructure-as-a-Service and specialist cloud services through the Digital Marketplace.

These services can be used by organisations across the UK public sector including central government, local government, health, education, devolved administrations, emergency services, defence and not-for-profit organisations.

CCS’s value for money, commercial procurement solutions are fully EU compliant, saving customers’ time and money. All G-Cloud 8 suppliers have been carefully evaluated during the tender process and pre-agreed terms and conditions offer customers sound contractual safeguards.

DevOpsGuys now offer the following seven services through the G-Cloud 8 Framework Agreement:

About DevOpsGuys

DevOpsGuys are experts in delivering practical engineering & consultancy solutions to transform and accelerate the way that organisations deliver software. We believe that DevOps offers a new operating model for IT departments to deliver software at speed.

DevOpsGuys has a large team of experienced consultants operating from offices in London and Cardiff and provides services to enterprises and public sector organisations in the UK and overseas.

DevOpsGuys has assisted public sector organisations including the Department for Environment Food & Rural Affairs, the Driver and Vehicle Licensing Agency, the Ministry of Justice and Companies House. We have also worked closely with Government Digital Services (GDS) to deliver services and solutions which enable digital teams building government services to meet the “Digital by Default” service standard.

Crwon Commercial Service

#DevOps – the Intern Perspective Part 1

Greg Sharpe is a second year student studying Computer Science at Aberyswyth University and has just started his year long internship at DevOpsGuys. This is the first of a series of posts that talks about his DevOps journey.

When I first started my internship I knew basically nothing about Web Automation and Website Deployment in general but, after being here only a few weeks I have already started to begin to deploy websites for many different projects in AWS.

I can honestly say that there is no way that I would of learnt not only the skills needed by this fast paced career but about the new up and coming technologies involved in deploying these sites without DevOpsGuys.

It’s a great opportunity for anyone to gain great experience as I was taught everything I needed to know straight away and given the support needed to do so. Not only is it a great place to work, but the people there are always happy to help with what I’m working on and I’m really looking forward to working with DevOpsGuys in the coming future as I’m made to feel important and a big part of the team.

“…it was not until working at DevOpsGuys that I really understood how and why it was so important to use version control software”.

Some of the many technologies I’ve have been working with are Terraform, Ansible and Git. Although I have used git before, it was not until working at DevOpsGuys that I really understood how and why it was so important to use version control software and after only a few weeks I can say I’m become more and more confident in Git and can use it on a daily basis without problems.

As for Ansible and Terraform, I had no experience working with these tools prior to joining the team at DevOpsGuys and was a little daunted by the thought of using them. But, after some training sessions with some of the senior engineers, I soon started to understand how both these technologies worked and how to implement them.

I am now onto my third week at DevOpsGuys and have already started deploying the infrastructure for the new site. I have found this not only a great experience to gain knowledge about how Terraform and Ansible work but have also found it enjoyable mainly due to the fact that everyone is so helpful and always available to answer answer any questions I have.

Within my first week, I researched a lot of different options within AWS EC2 Cloud and started with manually creating services from Nginx to Jenkins servers.

I found building these services manually a great inside to how they work and then through the use of Ansible and Terraform I was able to create services in minutes.At first this meant writing a lot of code but when you only have to type in one command to create a complete website, I found that unbelievable.

“…At first this meant writing a lot of code but when you only have to type in one command to create a complete website, I found that unbelievable.”

I’m really looking forward to learning about all things DevOps in the coming future and with the opportunities that DevOpsGuys has to offer (training and talks), I’m sure I’ll be learning a lot more than I ever expected from an Intern placement.

Pokemon Go and the art of customer satisfaction (via #DevOps)

Everyone has been surprised by the recent success of Pokemon Go, and that seems to include its creators!
“Going Viral” is not always easy to predict (even when it might be your goal) but your business can take advantage of automation within the cloud to ensure that your website or online service can deal with the demands of rapid growth in visitors or users of your app.
It has long been held within the IT industry that Google and it’s subsidiaries know how to scale – after all, they generate at least 40% of the traffic on the internet and run GMail, Google Search and Google Docs which are relied on the world over for mission-critical IT services by companies such as Roche Pharmaceuticals and BBVA Financial Services, so why has the launch by Niantic (The company running the platform that powers Pokemon Go and is owned by Google) been such a disaster when it comes to running at scale?
Over the weekend, Pokemon Servers went offline for well over five hours world-wide leading to outcry on social media, and, whilst there are claims that it was a hacker group taking the service offline via a Distributed Denial of Service Attack (DDOS), we find it hard to believe that it had nothing whatsoever with the decision to launch in another 26 countries some six hours previously.
If your infrastructure is in a traditional data-centre that you own and manage, or runs on hardware that you co-locate in someone else’s data-center, then it’s more than likely that you have problems scaling in the event of the Slashdot Effect or a major sales campaign that is successful.  The primary reason for this is that even if you are running a virtualisation platform such as VMWare on your infrastructure, eventually you will saturate your existing hardware and need to place a frantic call yo your hardware supplier in the hope that those ten or twenty-day lead-times can be cut drastically!
If you migrate out to a cloud provider such as AWS or Microsoft Azure, then the following three tricks could help you ensure that you deal with even the most severe amounts of traffic:

Use containers for the stateless parts of your application

If you have parts of your website or web service that are stateless (i.e. don’t rely on shared storage and follow the “cattle not pets” philosophy ), then you can migrate them out to containers that can be spawned and deleted as required and hosted in a “container services” environment such as AWS  or Azure Container Services.  This will allow you to configure how many containers are running at any given time, and how your infrastructure should react to sudden spikes in traffic (helpful hint – spawn more containers whilst busy, delete containers when quiet).

Learn how to take advantage of Auto-scaling at your provider

Both Azure  and AWS  provide a method of Auto-scaling virtual instances for those parts of the infrastructure that cannot be turned into containers for whatever reason.  Learn how to use these tools and couple them with Azure ARM Templates or AWS Cloud Formation [11] to deploy and scale multiple instances when you have an issue with traffic (Pete Mounce’s talk at WinOps 2015 is well worth a look to see how Just Eat do this!).

Get your developers and operations engineers talking to each other (aka DevOps!)

We talk to a lot of people who seem to be tired of hearing how much DevOps is about culture and not about tooling, and yet through encouraging developers and operations engineers to talk to each other, you can start to find some incredibly creative ways to enable an application to scale and an excitement in pushing the envelope.  
At this years’ WinOps, Pete Mounce (again!) talked about DDoS’ing yourself every night in production to prove that you can handle the traffic that your customers might throw at you, we think it’s worth a try and we have seen engineering teams rise to the challenge that is presented to them with excellent results.
Hopefully this blog post has given you some helpful pointers on how to make use of Cloud Technologies to avoid the issues that Pokemon GO seems to be experiencing at the moment, however, if you want to talk to any of our team about how DevOpsGuys might be able to help you scale in future, please get in touch.
– Matt MacDonald-Wallace, DevOps Engineer, DevOpsGuys (aka ProfFalken)
[Image by BagoGames –]

5 lessons learnt from the #DevOps Enterprise Summit EU 2016

This week London played host to its first ever DevOps Enterprise Summit, the Gene Kim led two day conference focussed on Enterprise DevOps adoption. There was a wide array of organisations represented by the speakers – from Financial Services (Barclays & ING) to Consumer Goods (Unilever) to Entertainment (Disney) to vendors like HPE and many others all talking about their own DevOps journeys.

So what were DevOpsGuys key lessons and takeaway messages from the event?

1 – No more excuses!

I think it’s fair to say that the wide range and scope of the Enterprises represented by the speakers destroyed the canard that Enterprise organisations can’t achieve a DevOps Transformation. They can, and they are, but it’s fair to say that it’s not easy nor for the faint of heart.

The Barclays case study in particular outlined the challenges of adopting DevOps across a 15,000+ employee global IT organisation. Other excuses like “you can’t do DevOps in regulated environments because of PCI | SOX | <insert compliance framework here>” was also directly addressed by some of the speakers – you can, they are, you just need to engage with the auditors directly early & often.

2 – “One size does not fit all” for your approach to DevOps Transformation

One phrase that was repeated over and over again (for two reasons as we will explore below) was “One size does not fit all”.

Many of the speakers made the point that their organisations’ approach to their DevOps Transformation was bespoke to them – it depended on their goals, their constraints, their systems, their culture etc etc.

Blindly adopting “what Google do” or “what Etsy do” is a recipe for disaster. We (DevOpsGuys) know this from our own work with our clients. We start with a Discovery phase to ensure that we understand their context and then collaborate with them to create a plan that works for them. Each one is different. One size does not fit all.

3 – “One size does not fit all” inside your DevOps model

The second way that “One size does not fit all” is inside your DevOps model itself. Teams need to have the autonomy to achieve their purpose without being smothered under the weight of overly restrictive, centralised, globally enforced “standards”. Start with Why, focus on the outcomes, and leave the “what” up to the product team itself.

That said, a technological and methodological free-for-all can create a support nightmare, reduce mobility between teams and impede collaboration. Which is why some organisations are looking to the open source software (OSS) movement to adopt “inner source” (or iOSS if you prefer).

The goal here is to create easily accessible, re-usable code that developers can use to accelerate their own delivery (application code, infrastructure code, test frameworks etc etc). Create libraries, patterns and practices that people WANT to use, can contribute to and constantly improve, rather than centrally imposed, static and dogmatic “Enterprise Frameworks”.

4 – “Top Down and Bottom Up”

People don’t want DevOps done TO them, they want DevOps done WITH them.

Another contender for “Catchphrase of the Summit” was “Top Down and Bottom Up”. The context for this is that your DevOps Transformation needs support from both the top (the C-Suite) and the bottom (the IT staff at the coal face) if it is going to succeed.

Grass roots DevOps initiatives (often focussed on technical goals like ELK, Docker and “infrastructure as code”) falter when they try to move outside their silos (e.g. Devs trying to get Ops involved or vice versa). They don’t have the mandate or political “juice” to change how other teams work. Collaboration is strangled at birth and DevOps fails.

Similarly a purely “Top down” DevOps transformation driven from the C-Suite can feel like “just another fad”, particular to jaded Enterprise IT Pro’s who have been through numerous other imposed frameworks in the past. The Enterprise immune system is triggered, resistance grows, and change fails.

Multiple speakers made the point that the C-Suite needs to show real leadership and be actively involved in the DevOps Transformation, removing obstacles, devolving autonomy and constantly seeking (and listening to) the feedback from their teams.

People don’t want DevOps done TO them, they want DevOps done WITH them.

5 – Holistic approach to DevOps is crucial

Another recurring theme is that your DevOps model needs to be holistic (which aligns neatly with the “First Way of DevOps”).

There was a running joke that DevOps needs to be renamed BizMarketingHRFinanceProductDevSecOps or something like that to truly encompass all the teams that need to be involved in moving to a DevOps model.

Systems thinking and the Theory of Constraints are inherent in DevOps – they are part of the philosophical framework that underpins DevOps – so it’s no real surprise that we have to consider the WHOLE system that is involved in moving from “concept to cash” to identify the real constraints and follow the POOGI cycle to ensure that things improve.


So that’s our top 5 take aways from DOES EU 2016. We will do a longer write up of the event itself later but we are already looking forward to DOES EU 2017 in June 2017!

Less than a week until Winops Conf

Less than a week to go until the second annual DevOps On Windows conference – – Tuesday 24th May.

We already have over 200 attendees registered to see an awesome line-up of speakers including the inventor of Powershell and Chief Architect for the Enterprise Cloud Group at Microsoft – Jeffrey Snover!

We also have:

  • Ed Wilson – The Microsoft Scripting Guy – talking about Config Management with Azure Automation
  • Michael Greene – Principal Programme Manager @ MSFT – talking about Release Pipelines
  • Iris Classon – Developer @ Konstrukt – talking about their journey to The Cloud.

Plus lots of other MVP’s, panel sessions, sponsor stands (Microsoft, Chef, Puppet, OctopusDeploy, SquaredUp, Jetbrains, IPExpo, Cloud&DevOps World, Redgate, Chocolatey and of course Prism Digital and DevOpsGuys as the organisers!).

This year we also have a FREE workshop day on Wednesday 25th May courtesy of Microsoft – “What’s New in Hybrid IT Infrastructure”

“Attend this free one-day training event to learn how to evolve your datacenter into a true hybrid cloud model to achieve greater efficiency, flexibility and scalability.” 

Note that this is a HANDS-ON lab-driven workshop with Ed Wilson and Marcus Robinson from Microsoft, so bring your laptop and get ready to get first-hand experience of things like Powershell, DSC and Azure Resource Manager.

I look forward to seeing you all there!


p.s. if you follow @DevOpsGuys on twitter and send us a message we might be able to do you a last-minute discount code for🙂


DevOpsDays does London – 2016

After two years off, this week saw the return of the DevOpsDays London. Since that double header in 2013, when London hosted the event twice – to coincide with the O’Reilly Velocity conference – there have been more than 50 DevOpsDays events globally.

This year’s event was an interesting combination of seasoned DevOps professionals who’ve been on the speaking, engineering or consulting circuit long enough now to be considered “veterans” and a gathering of “green horns” – who were either about to start or just starting their DevOps journey. For many, judging by the show of hands, this was their first DevOpsDays experience.

Against a back drop of a much swisher and larger scale venue than the eclectic St Mary Ward House venue which hosted previous DevOpsDays London – came the wide array talks and open spaces sessions.

Compared by a team from Barclays and Accenture, the opening session came from the wonderful Bridget Kromhout from Pivotal. The tone and content of her presentation, set the scene perfectly as she reflected on some DevOps 101 fundamentals, reinforcing the cultural elements and setting out that DevOps is not just about automation. There was also a clear message to both vendors and consultancies that DevOps is something you have to practice and not something you simply just buy in.

Next came the equally impressive, Joanne Molesky from Thoughtworks. Her insightful talk, from someone who didn’t start life as a hardcore technologist, set out her view on why large organisations are struggling to adopt the organisational change needed to successfully practice DevOps, noting that this change is not mandatory and neither is survival, but that today, the biggest risk faced by all business is not to change anything. Her advice included moving from a project to a product centric focus, and reminding us of Deming’s PDCA model – Joanne asked us to consider that measuring value and learning from failure be key to our DevOps journeys’.

Kris Saxton’s refreshing talk Bi-Model IT and Snake Oil, provided a strong and damming case against adopting the notion that your organisation needs an “us” and “them” approach within IT. His view that Mode 1 – Slow & Steady versus Mode 2 – Agile & Lean, as defined in the Bi-Model view of organisations, not only doesn’t work, but is counterproductive, kills innovation and creates a poisonous culture within organisations. Both the tone and content of his talk were superb and I highly recommend you consider his views carefully, if your organisation is discussing Bi-Model IT today.

photo credit: @bridgetkromhout

Fuelled by caffeine, the audience was next treated to a timely and extremely impressive tech talk, which included one of the slickest demo’s I’ve ever seen delivered at a conference. Casey West from Pivotal delivered his view on a Minimum Viable Platform, complete with an implementation in Cloud Foundry. Casey set out his 6 point Minimum Viable Platform which included;

  • Dynamic DNS, routing and load balancing
  • Backing services broker
  • Infrastructure orchestration
  • Health management, monitoring and recovery
  • Immutable artifacts repository
  • Log aggregation

For lots in the audience, they were finally getting a dose of the DevOps technology they’d come to see after a morning of culture and practice focused presentations and Casey didn’t fail to deliver.

Thiago Almeida, Tech evangelist at Microsoft, took the last formal presentation slot of the morning, with the very impressive story of DevOps transformation at Microsoft and some lessons learnt from collapsing silo’d development, test and operations people into cross-discipline, self-managing features teams. As part of the new focus, he highlighted how feature teams have become obsessed with understanding customers and the benefits this has brought in delivery high value solutions. What’s impressive in this story, is not simply the scale of what Microsoft have done, but more the speed at which they have managed to achieve their DevOps transformation.

photo credit: @ClaireAgutter

One of the big takeaways from this talk, was how DevOps had delivered a better work/life balance and this was highlighted in the #Microsoft staff survey. Burn out, is such an important and under discussed subject in our industry that is was great to see a major enterprise organisation highlighting the importance of finding better ways of working.

The morning session was concluded with a set of well delivered Ignites, Claire Agutter covering DevOps & ITSM, Ben Wootton describing Vendor vs Partner relationships in DevOps, and finally the highlight – “four things I learnt about DevOps when my car was engulfed by flames” by John Clapham. John’s entertaining talk did have a very serious undertone of lessons learnt with a key message being “Don’t just plan for disaster. Expect it. Plan for it.” Wise words.

After lunch, DevOpsDays familiar open spaces sessions took place. The diversity of talks offered didn’t fail to disappoint, and there was certainly something to appeal to technical and non-technical alike. Although the large conference space didn’t well suit open spaces, the organising team did a decent job of adapting the venue to suit, however it proved difficult for these sessions to really get flowing, partly because of the noise in the room from conflicting sessions and partly as some sessions had more than 50 people. Having said that, the participation in the talks was faultless and the content was great, even if some did struggle to understand that sessions start when they start, end when they end and can deviate from the original topic. Community events do require some moderation, but sometimes it’s difficult for some to adapt to the free form nature of these sessions, which allows discussion to ebb and flow. It was therefore a slight shame, that the formality of presentations was again introduced in the afternoon, but Justin Cormack did a good job of bringing security to the forefront, maybe such an important topic should have been central to the theme and given more prominence.

photo credit: 

The evening event provided a great opportunity to continue some excellent conversations well into the night. Here the venue came into its own with a large open space, bar and restaurants, making it easy for the discussion to continue without interruption.

photo credit: 

Day 2 kicked off with Kris Buytaert regaling tails of the 6.5 years of DevOpsDays. His talk allowed him to reminiscence on the history of the event, but also to outline some of the core ethos and characteristics that have made this event so successful globally.

Next came a new comer to the DevOps space by the name of Gene Kim. For his first time giving a talk on DevOps, Gene’s perceptive talk on the impact on DevOps becoming mainstream, seem to contain an awful lot of scientific materials and fact. For someone, so new to the industry his ability to gain such insight was simply astounding. Contained in the metrics, was the cold hard fact that this DevOps thing is delivering even more business value than we ever thought possible and that being 200x faster is creating decisive winners and losers in the marketplace. His talk covered many lessons learnt and examples from across the industry, all of which has culminated in his second book the “DevOps Handbook”, which we hope to see released shortly. Well done Gene, it seems you might have a bright future in this space.

As someone, said – “only Gene Kim can follow Gene Kim on stage” and so it was with the panel session up next. With representation from Barclays, Thoughtworks, Deloitte and Pivotal the all-star session was set to be ground-breaking. Disappointingly, poor audio and moderation combined to make this session pretty unengaging, and it failed to deliver the expected energy and open interaction from the crowd.

After the break, Gareth Rushgrove took back control of the energy and the crowd with a punchy and engaging talk on Rates of Change, Microservices and Platforms – a tale of devops coevolution, and it was tonic to those suffering a bit of day 2 conference fatigue. The clean and simple presentation was laden with facts and metrics – backed up with a good dose of science. With reference to culture, process and technology Gareth demonstrated that there are good practices for team structure, concluding that there are no single perfect team patterns for DevOps but that there are many bad patterns. The provides some excellent discussion on Team Structures that might be Right for DevOps to Flourish.

He continued by explaining the bi-directional relationship, as defined in Conways law, that software you use or build can be changed by changing your organisation or that your organisation can be changed by changing the software you use. He continued by exploring the coevolution, a concept rooted in biology, which considers systems as comprising both a “technical” and “social” system. The joint optimisation of both systems, leads to better results and Gareth drew direct comparison to DevOps as an example of this optimisation, stating that organisational change or technical improvement alone provide sub-optimal improvement. In short, DevOps requires both cultural and technical optimisation, to recognise the full benefits.

Jeromy Carriere closed the last formal session of the day with his talk, Enterprise Ops Rising, highlighting numerous operational and security challenges organisations are faced with when deploying systems microservices at scale in the cloud, balancing against a drop of standards, compliance and legacy code. Jeromy, touched on both technical and cultural aspects of employee empowerment, drawing in the topic of fear and touching on blameless post-mortems.

Photo credit: @squire_matt

A series of entertaining Ignites followed the highlight of which was defiantly Oliver Wood taking us to an entirely new place with his talk “You don’t scale” looking at “HumanOps”. Oliver covered the extremely important subject of Burnout and Health. “We adopted the slogan ‘go live or die trying’ because we are idiots.” was a highlight from his inspirational talk.

Photo Credit: 

Open spaces sessions in the afternoon saw a smaller number of topics than day #1. The sessions covered certification, security, post mortems and maturity assessments, with @michal_wojciech concluding that “all organisations need to bring their IT security teams to a DevOps conference”.

Overall it was an immensely enjoyable two days, and the massive amount of hard work the organisers had put in clearly showed as the event was run smoothly, with tons of positive feedback on content and discussions. The event however had taken on a much more “enterprise” feel, which was a slight shame given that this community event is a month before the DevOps Enterprise Summit. Unfortunately a low point of the event was the abandoning an entire Q&A session following one of the best talks of the conference, to allow the vendors their pitch slots. I think the audience and nature of the event should consider a more lenient approach to the schedule. In fairness the quality of speakers, discussion and venue overshadowed any negatives and it was a thoroughly enjoyable 2 days at a great conference.

As Caroline Donnally said, “Sign of a good conference is leaving it with a head buzzing with all the new stuff I’ve learned and can write about”

photo credit: @johnC_bristol

Thanks @DevOpsLondon2016 – we had a blast.

DevOps at Enterprise Scale Breakfast Briefing

A few weeks ago the DevOpsGuys and HPE hosted a joint breakfast briefing entitled DevOps at Enterprise Scale. We were joined by a good selection of household names from a variety of sectors: telecoms, retail and financial services. The over-riding questions were: how to get started with DevOps transformation and issues to avoid when applying DevOps principles at enterprise-level.

For me though, the highlight of the event was the presentation given by one of our customers Raj Fowler, who is Head of Product Delivery at BAE Systems. Raj is approximately 18 months into his DevOps Transformation and was inspired to start his journey after reading The Phoenix Project.

Raj began his presentation by giving us an overview of BAE Systems, its products and heritage as well as the evolutionary history of the organisation. Raj stated that the defence market was changing, just as in other sectors, which requires BAE Systems to increase pace, reduce costs and deliver value the customer whilst maintaining quality. Just as in the beginning of the Phoenix Project, BAE Systems needs to respond and adapt to a changing market place.

As a result, BAE Systems are embarking on the DevOps movement with a view to increasing the delivery of business value from enterprise systems. With help from literature, conferences and coaching, Raj is focussing his efforts on the cultural changes needed to deliver improved business results.

Using this collateral Raj has initiated two key strands of work. Firstly, he has restructured the organisation around Products, bringing the Plan, Build and Operate silos together. He has also initiated a structured education and coaching programme to redefine the rules they work to with a new focus on Value, Flow and Quality rather than Time, Cost and Scope. What he is now seeing are the ‘green shoots’ of progress. The foundations have been worked on, the seeds have been planted and an environment created to nurture a ‘new’ culture. Office walls (and windows) are being filled with Post-It Notes; huddles of people are forming, ‘talking’ about the work; individuals are becoming teams; language is changing with a focus on business value, delivering early and often and getting fast feedback; difficult organisational and customer conversations are being had to break down the ‘real’ barriers to progress and the departments performance indicators are slowly but surely starting to improve – all signs of small incremental cultural transformation.

Raj has underpinned these changes with education, which has been delivered by DevOpsGuys. We’ve worked with Raj to develop an education programme that supports his colleagues’ transformation and our approach has been to educate the department systematically focussing on the ‘why change’ and ‘why agile’ – it’s not just about knowing what to do, it’s about knowing why across the whole team.

Raj strongly believes his colleagues need to understand Why they are doing something, not just What they are doing. Therefore, we have coached rather than trained. Raj commented during his presentation, on how we have asked questions rather than provided answers, forcing his teams to really think about what they are doing. He wants to ensure he transforms his team in a way which really works for BAE Systems rather than copying a documented methodology verbatim. The benefits are being seen already.

Since embarking on his journey, Raj has observed increased customer satisfaction, seen an increase in staff motivation and of course, he’s starting to see change delivered faster. For instance, one of his teams is delivery weekly releases with cycle times reduced to around 2 weeks down from months. Raj maintains though, it’s not all about speed. It’s about flow. After all, there would be little benefit in him speeding up the delivery of change if no one in the business could accept the change.

After what felt like a difficult start, Raj is now seeing the rate of learning and adoption of these principles accelerate. Raj’s team are able to deliver software changes faster and the constraints are starting to move to the wider organisation (creation and approval of new work and business change). He is now starting to work with the wider business to increase the flow of work for the end to end system – from idea to user.

Raj’s transformation is also beginning to gain interest and positive feedback from the wider business, and he firmly believes the principles he’s used to improve the flow of work through his team can be applied to any area of a business, not just IT.

However, the most crucial lesson to be taken from the BAE Systems transformation is that in 18 months, they are still yet to automate anything. Instead of treading the path most other organisations follow, by starting with automation, Raj has pursued a path of education and transformation, choosing to leave automation until after all other process constraints have been removed.

And finally, to quote Raj: “This is not easy. It’s about people – creating the right environment, educating your organisation, stimulating collaboration, new practices and experimentation are essential ingredients to improving business performance.”

2016-02-24 09.03.18


Get every new post delivered to your Inbox.

Join 5,134 other followers

%d bloggers like this: