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.

Sponsored Content

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.

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.

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...

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.

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.

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.

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.

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.

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).

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.