InfoQ Homepage Presentations Continuous Improvement: Hell on Earth?
Continuous Improvement: Hell on Earth?
43:33
Summary
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.
Bio
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.
About the conference
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.
Jul 08, 2014
-
Related Sponsored Content
-
Related Sponsor
/filters:no_upscale()/sponsorship/topic/2c0d72d2-1768-47c2-8f5b-24f3ef0ae0e0/QconNYrsb-1679560094156.png)
Community comments
misleading of the term continious improvement
by Gabriel Klappenbach,
Muddled
by Frank Krasicki,
Re: Muddled
by David Marsh,
Re: Muddled
by Frank Krasicki,
Re: Muddled
by David Marsh,
Re: Muddled
by Frank Krasicki,
Re: Muddled
by David Marsh,
Re: Muddled
by Frank Krasicki,
Awesome
by Roy Oliver,
misleading of the term continious improvement
by Gabriel Klappenbach,
Your message is awaiting moderation. Thank you for participating in the discussion.
I feel like this talk is misleading when talking about continious improvement (in an Agile context). The speaker is talking about product improvement, and how fast a team can develop features. That is not the aim of agile continious improvement; see leankit.com/kanban/continuous-improvement/
It's about the development process, not about a manager asking for a feature developed in three weeks time...
Muddled
by Frank Krasicki,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think the speaker makes a good point that continuous improvement is not the same as innovation. However, nothing in her understanding of Agile/Lean is accurate enough to justify or sustain the conclusions she jumps to.
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.
Re: Muddled
by David Marsh,
Your message is awaiting moderation. Thank you for participating in the discussion.
Agile/Lean does not exist in a vacuum, while I didn't like the presentation style. Managers often make very basic mistakes or are driven by self interest, this can lead to age old problems independent of what process people claim to adhere to.
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 ?
Awesome
by Roy Oliver,
Your message is awaiting moderation. Thank you for participating in the discussion.
Reminds me of Mr. Logic: stupid-it-project-managers.blogspot.com.
Re: Muddled
by Frank Krasicki,
Your message is awaiting moderation. Thank you for participating in the discussion.
@David - re: "The 'embrace change' mantra far too often goes with the 'shit rolls down hill'."
Not sure why you believe this. Lean in Software development actually empowers employees behaviorally to do the right things. It is not so much about speeding up the process but refining process details that in and of themselves may alter development speeds one way or another assuming there's a superior outcome worth adopting.
Which brings us to your assertion, " If people cant reliably follow the process in many cases then it is a real issue with the process."
YES, precisely. Change the process - that's a lean thing to do, IMO.
Finally, "The idea is to maximise production, time and motion study etc. The workers are treated as expendable garbage. -snip- This is taken from where lean comes from."
No. Lean is not about treadmill improvements (although that's the way old-school management practices it... and there are a lot of these boneheads around... ever-louder, ever-faster, ever-piling on) per se. It can be. Building the best, most cost-effective widget is very different from building the fastest, most indifferent treadmill imaginable.
And this is where this woman's argument falls down. The lack of R&D and design vision can't be fixed by a philosophical methodology that has nothing to do with design and R&D. It may. Co-incidentally. But that's not what lean does for the most part.
Re: Muddled
by David Marsh,
Your message is awaiting moderation. Thank you for participating in the discussion.
Frank, clearly its not whats intended by Agile, but its rarely the ones in power in the organisation that change, its normally up to subordinate workers, and producing the wrong widget for the wrong market isn't a worker or manufacturing problem.
I don't believe there are significant examples where lean has corrected poor management or poor management structure. Its rare for employees the be 'truly empowered'. Try telling your boss their ideas are all wrong and see how far you get..
As far as new better widgets, this would be R&D, again I've not seen lean proven here, often on software projects the toolset isn't even creatively considered, 'we are Java team so we use Java' we are 'MS shop so we use .Net', its rare to see companies in software be truly creative with their decisions, instead they tend to limit creativity.
Re: Muddled
by Frank Krasicki,
Your message is awaiting moderation. Thank you for participating in the discussion.
Well with bad management its always turtles all the way down. No methodology is going to affect that.
But in cases where there is a glimmer of hope its hard to get it right. And empowering workers in hostile environments can go wrong very quickly.
Still. You misconstrue what Lean is about (agile is everything to everyone these days - self immolating). choosing .NET or Java is not a creative act and largely co-incidental IMO.
Re: Muddled
by David Marsh,
Your message is awaiting moderation. Thank you for participating in the discussion.
What tools you pick for the job is not coincidental.
While not a creative act, it shows that real choice and empowerment is largely absent even for some 'minor' (in your perspective) choices, let alone the major choices that might be required for real creativity or innovation.
Re: Muddled
by Frank Krasicki,
Your message is awaiting moderation. Thank you for participating in the discussion.
This depends on whether there is an empowered architecture team in place or just a developer team euphemistically labeled "architects" to no-wink compensate for lower pay/crappier work environment. With the latter you should instantly recognise that lean is not in play and agile is probably a dysfunctional mess as well.
Archetypes.
Tools can affect architectures that are already in play or anticipated to be in play. Over-their-head developers in love with Apple/.Net/theOnlyFrameworkIKnow development choices will snuff out your Responsive mobile dreams in a heartbeat when religion trumps broader technical discourse. (Which is not to dismiss any religious developer contingent per se - just sayin', the myopic Mikes of the world sometimes are not to be trusted with those decisions).