Category: Lean

The System Rules

I have worked in numerous companies and roles over the past 15+ years.  Culture and behaviour are a symptom of the system. 

I will level with you; I do not like job roles or titles they are symptom of the system.  More specifically I now consider myself a problem solver – even though this is a role, whether that be Front End, Back End, DevOps, QA, BA, PM, coach, leader, mentor, etc.  I will do any role that needs fulfilling to ship valuable working software to the customer.  I have got areas of specialism, areas I am ok at and areas where I need to read and learn.  However, on a personal note I love learning new technology and techniques.

Back to the system, if you create a system with job roles – more specifically the trend that I see now is the split between Front End vs. Back End & the new Full Stack role and the more traditional QA engineer or DevOps engineer.  That is the system, people’s behaviours will start to align with the roles.  For example – ask a DevOps engineer to do some React or Angular in this system and the likely hood is that you will get push back.  That is not my role, I’m employed as a DevOps engineer and all I do is Terraform and AWS! 

Delivering working software does not occur in a silo of work, do Front End then Back End – at any point you could be a stakeholder, PM, PO, BA, Front End, Back End, QA, DevOps, Release Engineer, etc. 

My experience of highly successful teams – read delivering valuable software to customers, with short lead times. Is that most team members will be needed to fulfill any role while delivering software. 

Having push back just creates queues and expands lead times.  Oh, the Front End dev’s just finished the UI, but the Back End component isn’t ready.  Software sits there waiting in a queue before the Back End work is done.  Queues kill flow.

Start with what you do now

Well I managed to get out to Lean Agile Manchester last night about Workplace visualisation and catch up with Carl Phillips of ao.  We had an excellent burger in the Northern Quarter before heading over to madlab, therefore delaying our arrival – oops sorry guys!  We spent quite a bit of time chatting about old times & then got down to the problem at hand.

Weirdly the first example was very reminiscent of where Carl & I started our journey at ao nearly four years ago.  Although, some of the key points where slightly different – i.e. number of developers, the location of the constraints in the department.

A rough guide of the scenario:

  • Specialists with hand-offs, bottleneck in test, multi-tasking galore
  • Small changes and incidents getting in the way of more strategic projects
  • 4 devs, 1 QA, 1 BA

We came up with a board similar to this:

We introduced WIP limits around the requirements section and set this at 1 as testing tended to be the bottleneck.  Reflecting this morning – introducing the WIP limits might have been a little premature…

As we where happy with the previous board, Ian challenged us to look at the digital agency scenario.

We started to map out the current value stream for the digital agency.  A rough guide for the scenario:

  • Multitasking on client projects, fixed scope and deadlines, 
  • lots of rework particularly because of UX
  • lots of late changes of requirements
  • 3rd party dependencies and a long support handover for client projects
  • 4 devs, 1 QA, 1 BA

This time we used swim lanes.  It looked similar but not exactly like this:

 These actually added inherent WIP limits because a swim lane could only have one card in within the column.  We introduced different two additional classes of service (we had a “feature” class of service for project work):

  1. A defect which blocked the current ticket and got tracked across the board.
  2. CR’s which would track across the board too.

We had a differing opinion on whether the “client support hand over” should be an additional column or a ticket – we ended up going with a column.

What I realised about this second scenario was that we mapped what was currently happening, although we introduced some inherent WIP limits due to board layout, but these where not forced upon the board – i.e. with numbers above the card columns.

Visualisation is good first step on understanding how work flows through a system, but remember to not force concepts on to the current environment.  “Start with what you do now”.

Why is Agile/Lean so tough?

I watched an excellent video by Ken Schwaber the other day regarding SCRUM.  Like all these things certain stuff just resonated with me…
One of the key points was how tough SCRUM was to implement and the relative poor success rate in implementing SCRUM.  The reason behind this is due to the tough questions that SCRUM highlights, my firm belief is that “Agile methodologies” like SCRUM, Kanban, etc do exactly this on the tin.  Highlight your problems – I recall a quote, “It’s like developing software in a room with all the lights full blast, compared to the dark room you’ve been sat in for last 5 years!”
People often see “Agile methodologies” as silver bullets – follow some simple rules and this will change your software development process for the better.  I mean what else could be simpler?  It will make you able to accept changing requirements late in the build process, build better quality and deliver faster.  The honest truth is that just following these simple rules won’t help your process.  The reason you’re looking for a change is usually because of the three reasons highlighted.  
  • You’ve got to accept that there are going to be some really tough questions that are highlighted.  
  • You’ve got to accept that you have to answer these questions to be successful.  
  • Only you can answer these questions, not anybody else.  
  • If you’re scared of answering tough questions and having tough conversations then do not engage with these “methodologies”.  Or if you do then be prepared to fail.  
  • So who is “you” – it’s everyone from the top to the bottom.
The answers to these questions will inevitably lead to change, and once again this change has to be done in the correct manner.  Embracing change, and ensuring that everyone is happy with the change is extremely hard to do – it needs time and effort from people.  It needs people to address people’s concerns, discuss why the change is better than the status quo.   
There are better articles about managing change at the following locations:

Efficient Vs. Effective

I’ve been thinking about “The Goal” of Kanban in our organisation for some time.

I believe that there are numerous (side/non) goals – however, the one true goal is to deliver high quality, business value to the customer.  However, to enable this to happen a Kaizen (continous improvement) environment is likely to aid & probably help you on this “path” to the goal (you might never get to the goal – it is after all a goal).  You also have to accept that life/business/software dev/nothing is never static so you have to be able to adapt your process to ensure that you keep delivering value to your customer.  This Kaizen environment helps people to eliminate waste, but also empower people to make changes to a process or system which isn’t helping to deliver value to the customer.  Anything that doesn’t add value is essentially waste.

I think there is a lot of “Non-Value Added” time during software development.  In fact maybe the only “Value Added” time is the point in which you push/pull it to live.  Everything else might just be “Non-Value Added” time!
 
So what exactly is efficiency within Software Development – well to me now it’s clear – thanks to wikipedia & the above mind burb!  Efficiency in software development is anything that is not “Value Adding” in your current value stream.

Now you might think – well if you’ve got Kaizen time (i.e. slack time to improve your process) how is this adding value to your current value stream.  Well it might be something to help improve the flow within the value stream.  This is as important because you are trying to optimise the current value stream – so essentially you are aiming to add value or remove waste from your value stream (agh confusing!).  It’s important to accept that these might fail sometimes – but hey people make mistakes and learn from them.

I think Effectiveness & Efficiency get confused.  I’m certainly confused this late at night!  Let me give some arbitrary examples of measuring these two things…

Measuring Effectiveness might be measuring the number of LOC (Lines Of Code) a developer writes.  However, this is irrelevant in line with the “Goal”.

Measuring Efficiency might be measuring the amount of Business Value a developer delivers to the business.  This is more relevant to the “Goal”, and to some degree is measurable against the goal.

However, this will promote local optima – promoting selfishness, and definitely promoting a non-kaizen environment.  This would lead to a process which is not optimised – you essentially get silos of optimised process, with other areas unoptimised.  That’s why it is important to look at your full value stream when measuring Efficiency.

Before measuring Effectiveness think about the impact this might have on your overall “Goal”.

Thanks to the following for making me think about this stuff way too much:

Increased WIP = Increase in Lead Time

I’ve been viewing our Cumulative Flow Diagram and some interesting stats surrounding the work we are developing, our current flow rate and WIP.  Today I was able to see how increasing our WIP directly affects our Lead Time.

Our big spike is due to all the items being placed on the backlog (TODO) – although some of these may never be implemented more on this in the future! 

To summarize some of the information I can see (and you can’t!):

Average Lead Time for any sized item from inception to live:

  • 35 days – 7 and 11 items in progress
  • 21 days – 2 and 5 items in progress

There are a number of things to note:

  • Variability in size has an impact on lead time – large items increase lead time.
  • Increase in Work in Progress decreases lead time.

 The above ties nicely in to Little’s Law.