What can dev teams learn from manufacturing? It’s as clear as mud(a)…

References in books and training courses about agile, scrum, lean or kanban almostalways include a reference to the manufacturing industry (anyone else sick of hearing about Toyota?). Whilst mildly interesting this always left me thinking – ‘but I don’t build cars – I build web sites’…

I know that the point is not what gets produced but how they go about producing it, but it’s still 2 very different industries, with different types of people and processes, working at different paces, using different machines, for customers with different demands.

Personally I think we need to stop talking about Japanese cars, start focusing on the Japanese concepts, and tailor these to what we need when considering software development.

Let’s start with waste (muda). This is one of the 3 evils of manufacturing, which depending on what you read will list out 7 or 8 types of waste.

Lots has been written about it before, so to live by the values of this post I’m going to cross reference a detailed post about the different types of waste to reduce the time and effort to get this to market.

Also here’s an image for a quick fix if you prefer visuals:


easset_upload_file854_73154_e

Put simply the goal of the concept is to minimise waste occurring and reduce it where it already exists, but how do we do this on a scrum team?

Here’s 2 scenarios:

Scenario 1 – A globally distributed team (London, Leeds, Manchester and Pune)

  1. Talk to each other as often as possible.

  2. Set up a regular operating rhythm and cadence of meeting and ceremonies

  3. Have as many meetings as possible face to face (video conferencing facilities and / or web cams are pretty standard these days)

  4. Be sensitive to each others timings / cultures / routines

  5. Start your meetings on time (rather than the first 5 minutes being spent ‘gathering’)

  6. Use shared document storage. (SharePoint / Wiki / Confluence / Dropbox)

  7. Avoid emails. Face to face first, phone second, instant messaging third, email should always be a last resort.

  8. Ensure common terminology has been agreed, so everyone is talking the same language (at least when in comes to agile)

  9. Ensure stories are well understood by everyone before being accepted into a Sprint

  10. Have everyone on the team 100% allocated

  11. Limit work in progress

Scenario 2 – a co-located team in the same office

  1. All of the above!!!

Yes, having a team sitting together is inherently more efficient than being distributed. Period. We all agree on that. This should always be the goal, despite in large organisations this often not being the case. However, I would argue that the route cause of waste, and ways to reduce it are very much the same regardless of co-location or not.

I consider the above very basic tips for reducing and avoiding waste, but I’ve seen these common mistakes (i.e not doing the above) being made time and time again which tells me that we’re not very good it, so looking at the basics is the perfect place to start.

Start today. Get out of the muda!

OK, now it’s your turn to share – what do you do in your software teams to avoid / reduce waste?

1 view0 comments