I still see many people writing about adopting Lean and/or Agile software development. I can remember how difficult it was for my team to work out what ‘Agile’ was and I think it has got harder since, as growing popularity has drawn charlatans into the area. I see two main types of useful articles.
- What (theory) : “It’s a philosophy” articles which usually point first towards the different values of agile and lean practitioners. But you can’t “do” a philosophy, so we get:
- What (practice) : Methodology – the study of methods that embody the philosophies. Many will say that Lean & Agile are not processes but I disagree; I think they are ‘software development process’ change processes.
I’d like to try something different: WHY?
The old ways of planning engineering projects, used for building a tower block, didn’t work for software. We don’t know enough, with sufficient certainty at the beginning of development to design top-down and are rarely sufficiently constrained by physics to be forced to build bottom-up.
Unusually for computing, the words ‘lean’ and ‘agile’ have useful meanings.
Lean is about ‘travelling light’, by avoiding waste in your software development process. It uses observation and incremental changes of your current process, while you incrementally deliver business value via working software.
Agile is about doing only valuable work, being nimble and able to change direction, in response to changed requirements or better understanding. It recognises that there are very few completely stable business processes, so software developers need to identify changes that will have impact on the software under development and apply effort in a new direction.
I recommend that you consider both approaches, as they are complementary. Neither removes the need for appropriate engineering practices. We’re only throwing out hard-engineering stuff we packed but didn’t prove useful on a software journey. We throw out what we don’t need, to prevent the weight of unecessary baggage holding us back.
Since trying to learn about Lean software development I’ve kept bumping into ‘The Theory of Constraints’. An article on LinkedIn https://www.linkedin.com/pulse/what-theory-constraints-steve-holcomb?trk=hp-feed-article-title-like has shown me this diagram
on Wikipedia’s entry about
It illustrates that the capacity of the barrel is limited by the shortest stave but I’m left wondering what the appropriate fix would be, in Lean philosophy.
My ‘engineering’ solution would be to replace the top of that stave, up to brim level and consider ordering a new top hoop. It would use more material but wouldn’t make much difference to the time and effort required and would provide a strong structure for fixing the rest of the barrel, when resources were available. I might get a new barrel or a recycled-plastic water-butt.
By different logic, there is no point repairing above the next constraint – or maybe the one after. Or I could nail a metal hoop around the top of the barrel and suspend a good bin-liner. Maybe that would hold it until the wood dried out, shrank and the barrel collapsed. I guess I’m saying that the Lean concept of ‘process waste’ seems a slippery animal to get hold of.
[Please don’t take the barrel analogy too literally. I know that the wood used for software is more stretchy and staves can be invoked multiple times but there are still times when a bit more effort now will save trouble later or ‘the thing’ has become structurally unsound.]
At the recent Agile Staffordshire meeting on Kanban http://www.meetup.com/Agile-Staffordshire/events/220533872/ the subject of ‘waste’ was discussed. It reminded me of another story:
Kanban is a scheduling system, designed at Toyota. Cards attached to a notice-board model the passage of production items through the manufacturing process. ‘Waste’ occurs when a backlog of cards start to build up anywhere on the board. Workers are responsible for ‘pull’ing the next unit of work by picking up the next scheduled card. The idea of ‘pull’ was closely allied to the concept of ‘Just in Time Manufacturing’ that was giving Japan a lead over US and European motor manufacturers, leading to efficiency drives and fuelling 1980s industrial unrest in the British motor trade.
Across UK industry, ‘The bosses’ and the unions were in an uneasy cease-fire that could tip into conflict over a ‘brother’ spending more than 5 minutes in the toilet or a manager speaking too harshly to a worker who had made an obscene remark to his secretary as they walked across the shop floor. It was the time of ‘one out, all out’ as unions flexed their muscles in preparation for the class war they saw ahead.
The company I worked for was engaged in ‘push’ manufacturing. They measured success by the number of cars coming off the production line per hour (and days lost to industrial action.) The story I want to tell is about a time when the transport drivers were on strike but the production line workers were not. Cars came off the line and were parked in a dedicated car park, from where they were normally picked up for delivery on transporters. Occasionally, this area would fill up with cars and for a short period, a quiet corner of the huge staff car park was set aside and used. This time, the dispute dragged on for weeks. The guys who parked the cars were incentivised to keep the line running. They started to park new cars anywhere they could find a space. Their sympathy was probably with the striking drivers rather than than their employers’, whose income stream had been severed. Anyway, they weren’t paid to think. That was Management’s job. “Let’s see how long before they notice.”
No system to keep track of where the cars were going appeared. There was 24-hour production, so the car park was never empty. Unregistered cars might be visiting from other plants. Many of the managers drove company cars or had bought at discount. No-one had a list of which cars had been lost and which had been found. It had never been necessary because they had a perfectly good system.
Several years later, during a complete plant shut-down, several unused cars were discovered, dotted around the now empty car-park. Legend has it that if you go there now and hoot a car horn on the stroke of midnight… No, THAT would be silly!