Katherine Kirk reflects through case study examples on what continuous improvement feels like on the ground and explores how it can be better by learning from other industries, research and real-life.
Now an independent consultant and researcher, Katherine Kirk has solid experience contracting and freelancing in a variety of roles within the IT and Media industries: from blue chip investment banking to media conglomerates. Recently she spent time as an Agile Coach at Rally after a period consulting as Delivery Improvement Specialist, Project Manager and Agile Coach at the BBC.
Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
misleading of the term continious improvement
It's about the development process, not about a manager asking for a feature developed in three weeks time...
The all too pervasive co-opting of Agile and Lean rhetoric by high-stress, fixed deadline project managers and project co-ordinators has indeed created yet another development cycle hell that substitutes Death marches with perpetually accelerating Death Sprints. This critique is accurate. But the problem is the distortion of the Agile/Lean process by the new and antithetical project management industry that has interjected itself into and over software development processes that work better without them.
So much of this talk is misguided that it is difficult and quite frankly futile to argue too many of these manufactured points. However, her most distorted ideas may be her explanations of and expectations of [Agile] Retrospectives. These conversations must be about what went well, what didn't, architectural anomalies or consequences, and so on. This results in project recalibration and development process improvements, not necessarily product innovation specification rewrites.
The 'embrace change' mantra far too often goes with the 'shit rolls down hill'.
All too often I hear the 'No true Scotsman' defence of Agile, the trouble is you can say this of all software processes. If people cant reliably follow the process in many cases then it is a real issue with the process.
I also think that lean has a basis in manufacturing, there is no reason to expect it should apply to software development, which is part engineering, part research, part creative endeavour.
The lean process comes from the factory floor and the supply chain, it says nothing about R&D in manufacturing.
Lastly a parable of real factory life :
When I was 16 I worked night shifts in a perfume factory. You would sit in front line, screwing bottle tops on for 8 hours, the line speed would gradually be increased by the 'line manager', until nobody could keep up. During this time you would have to panic sweat, stress, and pull the bottles off the line onto a small shelf in front of you. Should you ever 'catch up' you should clear your table while still working on the line. Every 30 mins the line was invariably slowed/stopped because the workers are about to collapse and have a heart attack, they are allowed to quickly clear their table and the process starts again.
The idea is to maximise production, time and motion study etc. The workers are treated as expendable garbage. There is no creativity.
Now does this sound like the lecture story ? This is taken from where lean comes from.
Factory processes generally maximise output, they probably wont maximise retention of staff or creativity.
Good Software developers are not expendable, and they need to be creative. Why are you treating them like factory workers ?