Latest information from Radtac

See all topics

Subscribe to the Radtac blog

Connect with us

Recent Posts

Latest information from Radtac

DevOps : A Longer Story Than I Thought!

27-Jan-2016 16:30:00 DevOps Agile
Find me on:
Continuous improvement is my definition of being Agile. ‘But wait’, I hear you cry, surely it can’t be that simple… Well of course it is, so where do you start?

In the Agile arena, we prescribe frameworks to manage our workflow, behaviours to influence our culture and technical practices to improve product quality.

Not surprisingly then, my personal experience of coaching and training over the last couple of years has revealed this ‘thinking split’ in all its glory in every organisation I have had the pleasure of being invited into.

Inherently we tend to divide our organisations into logical steps. I'm sure those well versed in human psychology and literacy can describe it far better than I. But it seems that in order to reduce complexity and chaos, we build walls, processes, and funnily enough complexity to manage complex things.

What this ultimately means is that to produce an idea we create communication gaps and handoffs as a mode of working. I’m not talking Agile or Traditional here, you can see this behaviour all around us all the time. We queue, wait, pass and wait again. How often have you stood in a queue at a coffee shop or restaurant and have thought ‘why aren't they organising themselves differently or optimising the process so I can get served quicker’?

Interestingly, one of my first introductions into process optimisation was a descriptive conversation around how Starbucks focused on queue theory during their rise to global domination. For those thinking that coffee is simple, this blog post points out there are 87-168 thousand drink combinations. Talk about product complexity!

So to build software things better, we start dipping back into the thinking that software is just like producing a bike, the same bike, over and over again. Of course not, we know all software is customised and forever changing. Just imagine if building software was an easily repeatable high quality manufacturing process, what would our creative limits be?

Now let’s hold on to that thought, as there’s a lot to be taken from thinking ‘how can we make our production process as simple and repeatable as possible?’

That’s the mindset we need to encourage in our organisations. Whether you are making coffee, bikes or software, it allows us to start thinking of the things that are holding us back, and target those wasteful things for elimination on our continuing path to bike software coffee production glory :)

OK, so that’s the mindset taken care of. From here, it’s simple - think waste. We know we want to improve our production time by eliminating wasteful things such as waiting around for sign-off meetings, that other team to do their work, or the production site to build so we can launch our very worthy and long time coming amazing product. These are all feasible yet time consuming items in our production flow.

Hang on, flow is a Kanban thing isn't it? (I hear y'all cry again ;))

Yes, so what!? It’s great! Use it!

One of the first things I do with an organisation or team is to draw a production flow map: ‘how does an idea get from brain to consumer’, and what are the steps and time scales involved. If you don't have this, do it now! Add wait times or time based metrics to allow you to analyse the cost associated with an idea.

From here we can look at the difference between the mindset thought and the actual flow that is preventing us from being a high performing bike software coffee production system. OK, that gets us on the lean organisation thinking, but how does this work with those darn computer thingies?

It’s the same, nothing changes in the approach. Adopt the improvement mindset. Look at the steps taken from product brain to the operations that usually a service delivery ‘chap’ or ‘chapess’ needs to perform in order to put the idea in the hands of a consumer. Measure and target waste for optimisation or elimination.

It should be that easy. However, we know software is complex so we create tooling to deal with complexity and end up with the concepts of Continuous Integration and Continuous Delivery. These are aimed at reducing the time to market for software development products through to the consumer. Another concept to research for yourself is ‘left shifting’ of testing practices to improve quality. Test early, fail early, learn early!

Reader, beware, we are now entering the murky world of DevOps, where, as usual, lots of people are defining the same term in their own unique way. Mostly I should add to make money or sell books.

My version, or should I say where I've seen DevOps succeed is:

DevOps is a completely viable extension of Agile and in particular the Scrum framework and its inherent behaviours and values. DevOps is a combination of one or more technical and cultural practices, that enables the Scrum objective to produce a “potentially releasable Increment” to be an actual releasable increment so that value can be realised. (Scrum Guide, 2013)

DevOps is not just about being technical and doing technical things.

If you've got this far in reading, we have covered the mindset, then the understanding of the cost and time associated with getting an idea to a consumer. For me DevOps is about reducing the communication and handoff gaps between product brain idea, those doing the work and those putting the work into live.

Scrum gets us disruptively challenging the way the organisation works to produce software. It forces roles, behaviours and patterns, and without those there would be chaos. But technically Scrum leaves us flat. I like to think sometimes it leaves us feeling like we are in a state where every 30 days or less we could provide some value to the consumer, but ‘oh wait’ there’s another sprint coming so ‘no bother’ we’ll look at releasing that another time.

DevOps thinking addresses that ‘flatness’ by moving the responsibility for releasing software closer to the teams developing the software. Think of left shifting with software delivery teams and right shifting with product teams. Actually just think one team. Brain, hands, fingers. All ready to release the good work to the end consumer within every sprint.

DevOps ultimately combines the three complex organisational challenges (frameworks to manage our workflow, behaviours to influence our culture and technical practices to improve product quality) into one repeatable process allowing ideas to emerge from brains, teams to produce those ideas, and happy consumers to do something with them.

Cool huh? :)

Author

Andy Hiles

Andy Hiles

Principal ConsultantA firm believer that great teams build great products. Andy is a highly experienced process coach, agile practitioner, and certified Agile trainer with the British Computer Society. Currently co-organiser of the South Wales Agile Group Read more