The DXC Blogs – 3 Ways to Make DXC Better

31May17

Originally posted internally 9 Nov 2016:

TL;DR – the 3 ways

  1. Improve flow
  2. Improve feedback
  3. Improve our ability to learn by experimentation

Why this is for you

When you see the word ‘DevOps’ please keep reading – this post is still for you. I deliberately left the word DevOps out of the title of this post, because I don’t want people to filter based on assumptions. This post is for you.

This post is for you if you’re a developer that doesn’t do ops – because it’s about how we help ourselves and our customers improve development.

This post is for you if you’re and ops person that doesn’t do dev – because it’s about how we help ourselves and our customers improve operations.

This post is for you if you’re a project manager – because it’s about how we make our delivery better.

This post is for you if you’re an architect – because it’s all about design thinking, and how we can make things better by design.

This post is for you if you’re a manager – because your help is needed in leading the necessary changes to our culture – the way we do things around here.

What is DevOps anyway?

DevOps is the set of practices that emerge from organisations that have designed for operations, which is a more mature level of design than design for purpose, or design for manufacture. Pretty much every product or service goes through design evolution, and we can now see many software based services that have effectively designed for operations. DevOps is the label we’ve given to the stuff they’ve done to accomplish that.

What are the ‘3 ways’?

  1. Flow
  2. Feedback
  3. Continuous Learning by Experimentation

The 3 ways originate from the total quality management movement in manufacturing, and over the course of the last few years those lessons from the late 20th century are being relearned and applied to software. They were first articulated in a DevOps context by Gene Kim and his co-authors in The Phoenix Project, and have recently been much more clearly explained in practical terms in The DevOps Handbook.

The rest of this post will look at each of the 3 ways, and what it means to us at DXC

Continuous Learning by Experimentation

The tip of our spear here is Operational Data Mining (ODM), which is run out of GD’s Operations Engineering (OE) team. ODM takes the data from our service management and ancillary systems and allows us to perform analysis, modelling, hypothesis extraction and experiment design for things happening in our delivery.

ODM helps us identify the constraints in our operational environment that are holding us back, and it helps us figure out what to do about them.

Pretty much every experiment we’ve run so far has succeeded, because the data has let us to obvious stuff, and generally it’s clear what to do about it. It’s not uncommon for front line staff to say, ‘I knew that, I knew we needed to do that’. The way we do things around here, our culture, has stopped those front line people from fixing those problems. ODM is providing the empowerment to change how we do things around here, to change our culture (to more data driven decision making rather than decisions made by ‘HiPPOs‘ – the Highest Paid Person’s Opinion).

It’s worth highlighting here that the true measure of ODM working for us will be when we move past the obvious ‘I knew that’ stuff and start finding the real edge of our organisation. We’ll know that’s happening when experiments fail to produce the expected results, and that’s just fine. Learning by failing needs to sit alongside of learning by doing and learning by using in our overall learning approach.

Flow

Flow is about moving things through our ‘factory’ as quickly as possible. It means breaking things down so that they’re smaller, easier to manage, and more likely to succeed.

Flow is the opposite of ‘Death Star’ projects, where every conceivable requirement and every possible risk mitigation gets pushed into something that takes years to deliver and $MMs to get there.

Just about every struggling project that I encounter is one where we’ve piled up a bunch of requirements, and pushed back delivery. Those projects get later and more complex, and more complex and later. We fix that by delivering as little as possible, as early as possible, as quickly as possible – then following with the next incremental delivery.

Feedback

Feedback is about finding out whether something works or not as soon as possible, so that any corrective action can be early and inexpensive.

Practices like continuous integration (CI) improve feedback when developing software, but there are many opportunities to create and improve feedback besides CI.

Feedback can only work if we’re willing to accept that things can go wrong, and be ready and willing to change what we’re doing (a little) and try again.

Many of the customers I talk to expected more from the cloud they bought from us. They bought into ‘agility, agility, agility’ – that business agility needed agile software that needed an agile infrastructure. Having bought the agile infrastructure they waited for the magic to happen, but there is no magic. We need to help those customers create the connective tissue between their business needs and their cloud infrastructure, and that’s done with delivery pipelines. Pipelines that embed testing and quality assurance. Pipelines that provide feedback.

What *you* can do

Think about what you’re doing:

  1. Does it improve flow?
  2. Does it improve feedback?
  3. Does it provide an opportunity for learning by experimentation?

If you can’t answer yes to at least one of those then think again, and ask for help if you’re struggling on your own.

Personal learning

We cant become a learning organisation without individual learning, and we shouldn’t conflate learning with training, or learning with education (as Andrew Clay Shafer explains in his ‘There is No Talent Shortage‘).

IT is a complex space, so nobody comes into an IT career without a desire to learn, but for some of us that desire gets crushed by burnout. An early statement in the DevOps handbook is:

When people are trapped in this downward spiral for years, especially those who are downstream of Development, they often feel stuck in a system that pre-ordains failure and leaves them powerless to change the outcomes. This powerlessness is often followed by burnout, with the associated feelings of fatigue, cynicism, and even hopelessness and despair.

If your work at DXC is making you feel like that then firstly take heart that we’re trying to fix things, and secondly please try to find again that thirst for learning that brought you into an IT career in the first place.

Conclusion

DevOps is just a name that’s been coined for the stuff that organisations that are good at delivery do.

We want to be good at delivery too, which means we need to embrace DevOps.

There are 3 ways: Flow, Feedback and Continuous Learning Through Experimentation – everything that we do should aim to improve at least one of those.

Here’s a nice visual from the folks at Pivotal:

 

Retrospective

This post more than any from the back catalogue embodies why I took the job in the first place and what I’m trying to achieve. Things don’t change overnight, and the arrival of DXC means that I’ve gone from a ‘bigger train set’ to an environment that’s three times bigger still; but the weekly ODM reviews show the power of incremental gains. If the UK can use incremental gains to come 2nd in the Olympics and Paralympics then we can do the same to come 1st in the global services integrator competitive landscape.

Original Comments

MB

Great post – well done. Having being an advocate Agile + DevOps + Lean Change in Consulting (ANZ) for some time I am totally with you.

The big question is how can this lead to real, tangible action within CSC? That is, what 3 things would you do if you were Steve Hilton, Jim Smith, or Carlos Lopez to foster a culture of Flow, Feedback, and Faith (Trust, Experimentation and Learning)?? I ask because culture is the challenge before anything else.

For me I would:

– Introduce Lean Change techniques into the way we run our business (see Lean Change | CSC Consulting — CSC Consulting Australia and Lean Change: a unique approach to managing change at speed — CSC Consulting) – we use it in our consulting practice

– Foster a culture of trust by setting clear expectations around what is required from employees, THEN remove bureaucracy, approvals, red-tape and THEN manage the exceptions (the 5% who get it wrong not the 95% who get it right)

– Invest in better business intelligence so we all gain more situational awareness which leads to us improving what we do.

Of course I totally understand that it’s not a simple as what I’ve written – the leaders have the tough job of keeping the business running well, while driving change through it – that’s not easy stuff!

CS

Thanks MB – I wasn’t familiar with the Lean Change material, and it’s great stuff.

The good news here is that the process to change our culture is already underway. I should explain that with reference to my preferred definition of culture – ‘the way we do things around here’, and so we’re changing the way we do things around here.

As I mentioned in the post the Operational Data Mining from the Operations Engineering (OE) team is where we’re leading the change, by identifying the constraints then capturing the data, doing the analysis, building the model, forming the hypothesis and running the experiment; rinse and repeat (and share lessons across the org). In recent weeks we (as a management team) have been looking for ways to push that forward (from the Global Delivery Network) into the broader picture of how we engage on delivery.

The bad news is that we have a psychological safety problem that touches many of our people, it’s been a problem for a while, but it’s particularly bad as we head towards DXC. I’m getting the ball rolling now to figure out how we establish better psychological safety for more of our people once we’re past the merger. I don’t think we can do much to foster trust until we’re trustworthy as an organisation – so the first step has to be ‘Make Safety a Prerequisite‘ (if I may borrow from Modern Agile).

The investment in better business intelligence is happening – that’s why we have a data science team in OE, and why we’re working with our colleagues in Big Data & Analytics to build robust and contemporary flow based analytics platforms for the data exhaust generated by our operations.

SS

“- Foster a culture of trust by setting clear expectations around what is required from employees, THEN remove bureaucracy, approvals, red-tape and THEN manage the exceptions (the 5% who get it wrong not the 95% who get it right)”

Makes so much sense as a guiding principle. Hopefully DXC will provide a great opportunity for a clean slate approach rather than a mishmash of legacy thinking and workarounds on top of workarounds…



2 Responses to “The DXC Blogs – 3 Ways to Make DXC Better”


  1. 1 Bionics – a primer | Chris Swan's Weblog
  2. 2 Bionix – a primer | Chris Swan's Weblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: