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

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)

  • Talk to each other as often as possible.
  • Set up a regular operating rhythm and cadence of meeting and ceremonies
  • Have as many meetings as possible face to face (video conferencing facilities and / or web cams are pretty standard these days)
  • Be sensitive to each others timings / cultures / routines
  • Start your meetings on time (rather than the first 5 minutes being spent ‘gathering’)
  • Use shared document storage. (SharePoint / Wiki / Confluence / Dropbox)
  • Avoid emails. Face to face first, phone second, instant messaging third, email should always be a last resort.
  • Ensure common terminology has been agreed, so everyone is talking the same language (at least when in comes to agile)
  • Ensure stories are well understood by everyone before being accepted into a Sprint
  • Have everyone on the team 100% allocated
  • Limit work in progress

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

  • 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?

Related Posts

Subscribe and get the ultimate office cheat sheet FREE, plus future posts sent straight to your inbox. No cost. No spam, ever.
There are 3 comments for this article
  1. Alex at 9:37 am

    Good stuff Noel!

    Thanks for the lift on Sunday 😉

    What scrum tools do you use? Any open source (free!) ones that you recommend? I’m starting scrum again (with a team of two) in the new year so I need to get something up and running

    Cheers,
    Alex

    • Noel at 6:29 am

      Hey Alex, there’s a few out there, depending on what you need. If it’s just a virtual kanban board for logging stories and tasks then trello.com is free and super easy with a nice app (but a real board in the office is still better if you work in the same location). What is it that you want to use the tool for?

      • Alex at 12:06 pm

        Ah Yes we’ve been using trello, mostly for project overviews

        I’ve tried the burndown chart add on to trello which seemed to work ok but wondered if there was anything that was a bit more integrated. I think I’ve used scrumworks in the past.

        Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *