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.]
Long-time readers of this blog may remember when I build the SIC out of recycled Internet meme-pipes and any random noise I had lying around. The basic engineering principle was that creativity happens when ideas collide, so by maximising the number of streams, then crossing them, I could get the Internet to super-charge my creative process. In no time at all I had started three different books.
Lean practice puts a maximum limit on Work-In-Progress. The less you do, the faster you will achieve, the quicker you will deliver value.
The Bad News:
- You can either be creative or efficient.
- You can be really competitive or really care about quality.
- You can be decisive or know about the details.
Compromise is balance. It’s a Yin and Yang thang.
I shall probably continue to oscillate between the two, attempting to optimise cadence. I may come back to cadence when I feel I really understand what it is.
[ I wrote the post below on LinkedIn, as a reaction to something I read which annoyed me. One person whose opinion I respect liked it, so I thought I’d share it here. I don’t understand where old LinkedIn posts go and you never know when you might need a positive thought. ]
I’m always surprised how many people believe software development is about turning what they think someone wants into code, when the really hard part is understanding what they will turn out to have really needed, at the end.
OK, coding is hard too; so don’t waste effort writing the wrong thing. The answer is not a better specification, a more demanding project manager or more people. The answer is to embrace your human limitations and think small. Be lean and agile. Work as a team. Go back for the wounded. Be a human.
I graduated just after the Structured Programming War was won. I was probably the first generation to be taught to program by someone who actually knew how; to be warned of the real and present danger of the GOTO statement and to be exposed first to a language that didn’t need it. I didn’t need to fall back to assembler when the going got tough or to be able to read hex dumps or deal with physical memory constraints. I entered the computing profession just as people were starting to re-brand their programmers as ‘software engineers’ and academics were talking of ‘formal methods’ then ‘iterative development’ and ‘prototyping’ as we lost faith and retreated, as the techniques borrowed from other engineering disciplines continued to disappoint when applied to software.
After some years away from software development, I returned to find ‘Agile’, ‘Lean’ and ‘Software Craftsmanship’. We’d surrendered to the chaos, accepted that we weren’t designers of great engineering works but software whittlers. I was pleased that we’d dropped the pretence that we knew what we were doing but disappointed that we’d been reduced to hand-weaving our systems like hipsters.
There had been another good change too: The Object Model. The thrust of software engineering had often been decomposition but our model had been the parts breakdown structure, the skeletal parts of a dead system. Objects allowed us to model running systems, the process network at the heart of computation. I’ve recently seen a claim that the Unix command line interface with its pipes and redirection was the first object system. Unix begat GNU and Free software and Linux and close to zero costs for the ‘means of production’ of software. I don’t believe that Agile or Lean start-ups could have happened in a world without objects, the Internet or Free software. Do you know how much work it takes to order software on a tape from the US by post? I do.
So here we are, in our loft rooms, on a hand crafted loom made of driftwood and sweat, iterating towards a vague idea emerging out of someone’s misty musings and watching our salary eroded towards the cost of production. Is this why I studied Computer Science for 3 years? Who turned my profession into a hobby activity?
For some weeks now I’ve been putting off a task I had set myself to get the difference between Agile & Lean sorted out in my head, then in writing. The very first link brought up by Google means I don’t need to do that now. It’s also on a blog that I’m already following which suggests I’ve spotted gold here before:
and she then went on to explain in Part 2 why Scrum is just a (probably necessary) stepping stone from ‘traditional project planning’ to Kanban scheduling.
I should just stop, read everything she’s ever written and save myself a lot of time.
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!
Everyone who has done any job for a while has a few ‘war stories’. It’s even a standard management technique to throw a few techie-tales into the conversation to bolster credibility with the geeks in the platoon. That can go badly wrong but that’s a story for another day.
Because some of my tales from the trenches were acquired while contracting, I’ve felt bound by client confidentiality and only shared them with a small number of trusted colleagues but surely a good yarn has a statute of limitations, if it is told for the good of society. As this one is more than 20 years old and the company has changed ownership at least twice in that period, I’m going to risk it. The facts don’t reflect badly on any individual, only on a manufacturing culture that had unwittingly survived beyond it’s sell-by date.
A group of Japanese businessmen were being guided around a luxury sports car manufacturer’s engine test facility to show off the company’s recent massive investment in robotics. The company had experienced a long-standing problems with cars being delivered to customers or showrooms, only to be returned because of significant oil-leaks from around the engine-block.
In the new system, each engine arrived in a wooden box which was unpacked and delivered on it’s pallet to a testing station where an operator attached oil, water and electrical connectors. Each engine had a bar-code attached so that it could be tracked throughout the manufacturing process and the foreman knew who was to be blamed for any error. Each engine was filled with oil and water then started up and run through a number of test cycles until the operators had either made minor adjustments to get the engine through the tests or had failed and been sent back to manufacturing for complete re-work. No more sub-standard engines would be put into cars and sent out of the factory gate to damage brand reputation.
The UK managers turned to the main Japanese visitor, glowing with pride that for once they were ahead in the race to manufacture the most reliable cars. The visitor hesitated then said, “That is very impressive but what I don’t understand is: why did you decide to build some of your engines with leaks?”
I dedicate this story to my Agile & Lean friends whose tests are built into their manufacturing process and I offer it as a warning to those who throw their software onto a transporter for delivery to Engine Test.