Archive

Monthly Archives: April 2014

The Future Of Work

[Tl;Dr: Most people, and in particular managers, have yet to realise the nature of work has fundamentally changed, and that the old ways are catastrophic for collaborative knowledge work.]

I love living in the future. Folks think differently there. I find I’ve spent my entire career some 5-20 years ahead of the mainstream. That can be frustrating, of course. But honestly, I’d have it no other way.

Aside from a bunch of technology and business ideas – some implemented, some not – I’ve seen hundreds of organisations close up and personal. For as long as I can remember, I’ve been interested in the question “why is software development so broken, just about everywhere?”. In my journeys through these organisations, I’ve looked for clues which might furnish some kind of answer.

My sleuthing to date has led me to the hypothesis that most folks are unaware of a couple of things:

  • Software development work is not like classical “work” – it’s something new, something different.
  • It’s not irredeemably broken. Some very few organisations are quite effective at it.
  • Our most widespread mental models of work are catastrophically incompatible with this “new work”.

“The most important, and indeed the truly unique, contribution of management in the 20th century was the fifty-fold increase in the productivity of the MANUAL WORKER in manufacturing. The most important contribution management needs to make in the 21st century is similarly to increase the productivity of KNOWLEDGE WORK and the KNOWLEDGE WORKER.”

~ Peter F. Drucker

It’s clear to me that the future of work is what Drucker called “knowledge work”. More specifically, collaborative knowledge work.

“What differentiates knowledge work from other forms of work is its primary task of ‘non-routine’ problem-solving that requires a combination of convergent, divergent and creative thinking.”

~ Reinhardt et al., 2011.

And what differentiates collaborative knowledge work is the involvement of some number – greater than one – of agents (read: people) involved together in tackling any given task. We may cling to the image of the lone mad scientist, but today the nature of the challenges we face as a species demand groups or teams of people working together.

The Robots Are Coming

Why is collaborative knowledge work the future of work? Because other forms of work – manual labour; repetitive, routine tasks, etc. – will become more and more the domain of the robots. Sure, that may yet take some time to happen. But the writing’s on the wall. And writ larger every day. Maybe one day Artificial Intelligence will be able to out-perform people even in non-routine, highly variable and intuitive tasks, too. Maybe AI-driven robots will become at least as – if not more – “human” (read: humane) companions and social collaborators than people. But that day, if and when it comes, is much further off. And distant not least because most of the work in making it happen is collaborative knowledge work and we’re just not doing very well at that, as a species (yet).

Still Living in the Past

Most organisations, and the people working in them, have a mental model of work dating back to the late nineteenth century. A model predicated on the coordination and oversight of a largely illiterate and uneducated workforce. A workforce mostly engaged in repetitive, routine manual, manufacturing, clerical or administrative tasks. The modern workforce has changed out of all recognition. Organisations and their methods patently have not.

Trends

And not only has the nature of the workforce undergone a sea change. So have folks’ expectations. A basic “living” is becoming ever less attractive to people. Especially in the relatively privileged West. People are looking for more from a job. More meaning. More self-determination. More opportunities to “discover themselves” and become all they can be. And the role of organisations in our societies is ever more closely scrutinised and challenged. “Productivity” for its own sake – or simply for the sake of making the rich richer – is no longer something that folks regard as unequivocally desirable. These are all trends that are not going away.

Maybe, in time, the whole concept of a “job” or working for a living will find itself consigned to the trashcan of history. Switzerland is already exploring some of the implications of this possibility, such as a guaranteed basic income for all citizens.

But for the immediate future, we work. So it seems to me that finding ways to make that a more convivial experience for all, makes some kind of sense. Not that we humans are very rational animals.

The Future Is Bright

People can change. Organisations can change. Not yet perhaps in large numbers, and not each, overnight. But slowly, by degrees. Most organisations today are still woefully ineffective in their approach to collaborative knowledge work. Hamstrung by wholly unsuitable mental models of work from the past, they hobble along doing the best they can under their burden of their outmoded assumptions.

But there are some few organisations that have transcended this toxic inheritance, and found ways to be much more effective – and to be much nicer places to work, too:

The Rightshifting Chart (click to enlarge)

Few, indeed. But a few more, every day. There’s no reason why organisations have to be as lame as they are today, excepting our human fallibilities and lack of imagination.

It’s All Hidden

One key reason this state of affairs has come to pass is the very opacity of collaborative knowledge work. Observers (e.g. managers) not directly involved in the work have little visibility into what’s actually going on. And the ubiquity of collaborative knowledge work, like the situation of the metaphorical frog in slowly heated water, has come about barely imperceptibly, over many decades. Long enough that most folks have not (yet) noticed that the very nature of work has fundamentally changed.

“In the knowledge society the most probable assumption – and certainly the assumption on which all organisations have to conduct their affairs – is that they need the knowledge worker far more than the knowledge worker needs them.”

~ Peter F. Drucker

What We Might Learn

To paraphrase Betrand Russell:

“Most organisations would die sooner than understand knowledge work – in fact they do so.”

Is this wilful ignorance? I don’t see it that way. Rather, I see it as folks trying to get their needs met, through strategies familiar to them, without an awareness of – and confidence in – other strategies which could get those same needs met much more effectively. Their current strategies, predicated as they so often are on outmoded and inherited assumptions, are what leads to ineffective behaviours and disappointing outcomes.

The competition between Theory X and Theory Y (McGregor) is just one example of two strategies that different folks choose to get their needs met.

For those who are willing to consider alternative strategies for getting their needs met, and e.g. learn about collaborative knowledge work – what it is, the climate in which it thrives, etc. – what might they find? Here’s my list:

  • Cognitive function is a fragile thing, yet central to effective knowledge work (cf. Flow – Mihaly Csikszentmihalyi)
  • Skilful social interactions – and especially dialogue – are central to collaborative knowledge work (cf. Idea Flow – Pentland)
  • Power structures by their very nature are toxic to collaborative knowledge work
  • People like to work, are creative, seek responsibility and can self-direct and self-coordinate (cf. Theory Y – McGregor)
  • Mutual joy is the strongest – and naturally occurring – form of human motivation (cf. Nonviolence – Rosenberg)
  • Free play brings profound benefits (cf. Psychology – Scott G. Eberle, Stuart Brown, et al.)
  • Environment matters. Both the physical working environment and the “collaborative climate”. (Cf. Peopleware – DeMarco & Lister)
  • Intrinsic motivation is all – extrinsic, a non-starter (cf. Drive – Dan Pink)
  • 95% of folks’ relative contribution is a function of the way the work works (cf. Deming)
  • Even the best, most engaged and talented workers can be defeated by “the way the work works”.

“Extrinsic reward systems have seven deadly flaws. They can undermine performance, creativity, good behaviour and intrinsic motivation, as well as encouraging short termism, unethical behaviour and become addictive.”

~ Dan Pink

Lots of people ask me “I’m not a senior manager or exec – what can I possibly do to contribute in some way to changing things for the better?”. Maybe one way forward is to empathise with how senior managers are, like everyone else, trying to get their needs met, but with outdated and unsuited strategies – and offer to introduce them to some new ideas.

– Bob

Further Reading

Management Challenges for the 21st Century ~ Peter F. Drucker
The Robots Are Coming ~ Gavin Kelly
The Importance of Play For Adults ~ Margarita Tartakovsky
Closing the Individual Productivity Gap: Putting First Things First ~ Franklin Covey (pdf)
Collaborative Climate and Effectiveness of Knowledge Work – an Empirical Study (pdf)
Extrinsic and Intrinsic Rewards ~ Jo Ann Sweeney

(See also comments, below.)

 

 

Flow, Shmo

We hear a lot from certain quarters about the benefits of flow – i.e. of value, through eg a value chain, or network, of suppliers to eg customers. I myself have written about it on occasion. And I even had the job title of Head of Product Development Flow, last year.

As a guideline for the initiated, this can work. See: the Lean Decision Filter.

But, as I wrote more recently, the Antimatter Decision Filter illustrates how flow, and even value, comes some way down the list of what matters to most people.

And all this finagling around flow (or value, or even needs, for that matter) is moot to the point of utter batshit irrelevance to most folks out there in businessland and beyond.

So what does matter to people? Don’t ask me. Why not ask them?

– Bob

Further Reading

Theory of Constraints 3 Bottle Demo to improve Flow ~ Youtube video

Eight Ways Customer Value is Killing Your Business

Tl;Dr – A blind faith in the idea of “customer value” can cause many more problems than it solves.

Some folks seem to believe in “customer value” like it was the New Church.

The idea appears to have transcended logical enquiry and consideration, and become some kind of sacred cow. So be it. I do not subscribe. I guess that makes me an apostate.

My view? I see organisations that focus on customer value putting their business in jeopardy. Of course, there are numerous other ways to do that, too. But this particular path seems deeply ironic, given the number of self-styled experts who hail “customer value” as the salvation of business.

So, here are eight ways in which an incautious and credulous emphasis on “customer value” can undermine business success:

  1. If you don’t mean it
  2. What about everyone else?
  3. Narrow definition of “Customer” and “Value”
  4. Confusion of Value Disciplines
  5. Unintended Consequences
  6. Choosing the Wrong Kind of Value
  7. Conflating means with ends
  8. Strangles Innovation

1. If You Don’t Mean It

Is your organisation just striking a pose with regard to caring about delivering value to its customers? If so, they will find you out soon enough, and quickly spread word of your duplicity far and wide. Poor service and/or product quality is the norm in most businesses today, but pretend that you’re different when you’re not, and the backlash increases dramatically. More than the effect on disaffected customers, consider the effect on staff, too. How long can they go on living a lie? How will their chagrin affect their attitude to customers?

Aside: Becoming really customer-focused demands fundamental changes in organisations – in their collective mindsets, in their structures and in their daily actions. I’d go so far as to say that it’s a challenge far beyond the capacity of the Analytic mindset.

2. What About Everyone Else?

When a business truly places its customers on a pedestal, other stakeholders typically suffer. Employees and their issues get short-changed, managers are overworked or trapped in continual fire-fighting, and other stakeholders similarly lose out. Disaffection in key stakeholder groups, especially front-line employees, leads to a poorer customer experience, too. How about considering the value of balance, rather than unilateralism? How about attending to everyone’s needs?

3. Narrow Definition of “Customer” and “Value”

Who do you regard as your customer? How do you decide what is of value to them? Do you define customers as (just) those folks that sign the cheques? And do you define value in terms of simple hard cash? If so, what about all those other folks who suffer your goods and services without a voice? And what about their (non-cash) experiences?

4. Confusion of Value Disciplines

Michael Treacy and Fred Wiersma describe three generic value disciplines: operational excellence, customer intimacy and product leadership in their book The Discipline of Market Leaders (1997). They go on to make the case that any given business can and must focus on just one out of these three disciplines. Many organisations have yet to realise this.

5. Unintended Consequences

In his book “Obliquity”, Alan Kay makes the case for approaching one’s goals obliquely. Rushing headlong at “customer value” can often result in many unintended consequences. A more indirect approach, such as providing value to customers by building an organisation or workforce with the capability to do so “baked-in”, and evolving continuously, can avoid many of these unintended consequences.

6. Choosing the Wrong Kind of Value

There’s a story about Frank WIlliams and his Williams Formula One team. When any of his engineers came up with a modification to the car he would ask “does it make the car go faster?” Some folks cite this as an example of excellence of focus, and a great heuristic or metric (how much faster will the car go). But in Formula One, having a faster car is not necessarily the optimal strategy, all things considered. Better questions might be “will we win more races?”, “will we take the Championship?”, or even “will we get more sponsorship?”. If you give folks a goal, they’ll strive to meet it, even when it’s the “wrong” goal. Even when it destroys the company. And how likely is it that, even if senior managers do choose the “right” kind of customer value, folks across the organisation will understand and deliver on that?

7. Conflating Means With Ends

In his book The Goal, Eliyahu Goldratt asks the fundamental question “Why are you in business? What’s your goal?” Having happy customers is a means to a commercial organisations’ goal, not an end in itself. Yes, even a necessary means (see: Necessary But Not Sufficient). But not sufficient.

8. Strangles Innovation

Focusing blindly on customer value can drive short-termism in the organisation, because the connection between longer-term investment in e.g. innovation and the customer value of such proposed innovations is often hard to see.

I hope this piece has provided you with some food for thought. Maybe even… some value?

– Bob

Acknowledgements

My special thanks to @drunkcod for his valuable contributions to this post.

Further Reading

The Discipline of Market Leaders ~ Treacey & Weirsma
Goals Can Kill a Company ~ Rafael Aguayo
7 Reasons Why Most Organizations Don’t Know Their Customer ~ Karen Martin

 

Can We Imagine?

Can we imagine alternatives to conventional management? Different ways of coordinating organisations, large and small?

“Finding deficiencies and getting rid of them is not a way of improving the performance of the system. An improvement program must be directed at what you want, not at what you don’t want. And, determining what you do want requires redesigning the system, not for the future, but for right now, and asking yourself what would you do right now if you could do whatever you wanted to. If you don’t know what you would do if you could do what you wanted to do how could you ever know what you would do under constraints?”

~ Russell L. Ackoff

Of course there are constraints on what we can do right now to improve the fundamentals of how we coordinate and direct our organisations. But if we can’t even imagine other ways, better ways, then what does that say about our imaginations?

As a starter for ten, here’s a comparison of just three alternatives for coordinating our organisations:

Different Forms of Organisational Coordination

Conventional Management

Vs.

Lean Management

Vs.

Fellowship

Authority

Vs.

Responsibility

Vs.

Mutuality

Results

Vs.

Process

Vs.

Relationships

Give answers

Vs.

Ask questions

Vs.

Make refusable requests

Plans

Vs.

Experiments

Vs.

Conversations

Formal education

Vs.

Gemba learning

Vs.

Mutual exploration

Specialists own improvement 

Vs.

Line manager and teams own improvement

Vs.

Those doing the work own improvement

Data-based decisions made remotely

Vs.

Facts-based decisons made at the gemba

Vs.

Decisions made together

Standardisation by specialists

Vs.

Standardisation by manager and team

Vs.

Standardisation by team

Go fast to go slow

Vs.

Go slow to go fast

Vs.

Play

Vertical focus

Vs.

Horizontal focus

Vs.

People-as-individuals focus

Fixed mindset (cf Dweck)

Vs.

Growth mindset

Vs.

Mutuality mindset

Extrinsic motivations

Vs.

Intrinsic motivations

Vs.

Mutual joyfulness

Violence

Vs.

Respect

Vs.

Nonviolence

Imposed or opaque purpose

Vs.

Shared (static) purpose

Vs.

Mutually-evolving purpose

Key decisions made by a few

Vs.

Key decisions made by a few

Vs.

Key decisions made by consensus of all

Economics of Cost

Vs.

Economics of Flow

Vs.

Economics of Joy

What other forms can you imagine?

– Bob

 

Objectives, Proclaimed vs Practised

Tl; Dr: Most organisations do software development not for the outputs, but to satisfy the members of the core group, whose needs are pretty much entirely disconnected from both software quality and the evolution of an effective development organisation.

Mistaken Beliefs

“Discrepancies between objective proclaimed and objective practiced can be observed in most organizations. For example, one could mistakenly believe that the principal objective of universities is to educate students. What a myth! The principal objective of a university is to provide job security and increase the standard of living and quality of life of those members of the faculty and administration who make the critical decisions. Teaching is a price faculty members must pay to share in the benefits provided. Like any price, they try to minimize it. Note that the more senior and politically powerful teaching members of the faculty are, the less teaching they do.”

~ Russell L. Ackoff

So To Software Development

One could mistakenly believe that the principle objective of e.g. software houses and other software-producing organisations is “working software”. What a myth! The principle objective of such businesses is to provide job security and increase the standard of living, positive self-image and quality of life of those in the core group of these organisations, and provide sufficient (read: minimum) income, entertainment and other such “attractions” necessary to retain the continued attendance of the rest of the workforce. “Frontline” work such as coding, testing, designing, decision-making, etc. is a price core group members must occasionally pay to share in the benefits provided. Like any price, they try to minimise it. Note that the more senior and politically powerful the core group member, the less frontline work they do.

The Core Reason For Lameness

Here we have one answer to the question “Why are software products generally so lame?”. Note: we could also phrase this as “why does the practice of software development generally result in outputs (software, products) with such limited positive impacts (outcomes) for anyone but members of the core group?”. Or more bluntly: “Why does no one ever seem to care that we’re just continually churning out crap?”.

Just like universities, where the positive outcomes for students are more or less limited to a handy, albeit increasingly expensive qualification, in software development positive outcomes for customers and workers are more or less in the lap of the Gods (or the members of the core group, which we may choose to regards as synonymous).

– Bob

Further Reading

Who Really Matters ~ Art Kleiner

Can You Use A Scrum Master?

A giant tied down by little people

I don’t mean “do you have an opening for a Scrum Master right now?”. I mean, “if you hired a Scrum Master today, would you, your development teams and your organisation be able to get any real value out of him or her?”.

There’s a whole bunch of pathologies I see time and again in Agile adoptions. One set of such pathologies is around the role of Scrum Master. These pathologies, unchecked, result in situations which demoralise the new hires and the development teams alike, and rob the organisation of any value from having a Scrum Master, and even from the Agile adoption itself.

Fools Rush In…

The line of so-called reasoning which leads to this particular group of pathologies generally runs like this:

“I’ve just heard about this thing called Agile. Could we use it?”

“We need to do something about our software development around here. It costs too much / takes too long / is not predictable enough / produces low quality resulting in a poor customer experience / insert your gripe here.”

“I know, this new-fangled Agile thing looks like it solves all our problem. I read as much in an inflight magazine last week. Let’s get our tech folks to adopt agile.”

“What flavour of Agile?”

“Um. There are flavours? I’ve heard of something called Scrum. Seems quite common. Let’s go for that.”

“Right! The development teams will start using Scrum next Monday.”

“But they don’t know anything about Scrum. It’s quite different to how they’re working now, I guess. They’ll need someone to show them the ropes and train them in the whole thing. The Scrum book says so. That person is called the Scrum Master.”

“Ok. We’ll hire one of those, then. Now they can jolly well get on with it. It’ll be great. Problem solved – at last. Golf this afternoon?”

And so the scene is set for another train-wreck. Here’s an explanation of some of the pathologies implicit in this dialogue:

Scrum is a Thing

It’s not. It’s an entry point, an on-ramp, a way to get started. The sooner a team becomes comfortable with the basic principles of Agile, the sooner Scrum-By-The-Book can fall away, and the team can continue its journey in whatever directions it deems best, according to the unfolding and evolving situation.

Scrum Can be Mandated

It can’t. If the development teams have no choice but to adopt Scrum, are not involved in the decision, they will likely resent it from the very outset. And resentment breeds opposition.

The Scrum Master is a Management Appointee

They’re not. Or rather, all too often they are – which only compounds the issue of the involvement of the development team in key decisions. Lack of autonomy is not a good foot upon which to get started with e.g. Scrum. Giving a development team little or no say in who gets to be their Scrum Master will again exacerbate their sense of learned helplessness, and breed dissatisfaction and disengagement.

The Scrum Master Is a Trainer

They’re not. Maybe they have some Scrum knowledge, maybe not. (And no, certification will not provide you with any assurances about that, one way or the other). The Scrum Master is no policeman, either, despite some opinions to the contrary. Primarily, the Scrum Master is someone who speaks for the “improvement” of the way the work works, offering some counter-balance to the daily pressure to get stuff shipped. (See also: Two Masters). If they do bring some Scrum expertise to the party, that can afford some short-term acceleration for the team, but often at the cost of longer-term progress – delaying the onset of a team’s confidence in itself and in its ability to learn.

Change is Bounded to the Dev Teams

It’s not. Most of the issues impacting development teams will lie outside the control of the development teams themselves. The Scrum Master will act as a catalyst for the team to bring these issues to the attention of senior management – the only folks in typical organisations that have the scope of authority to get these issues sorted out. This means that the Scrum Master and/or Team will be a regular – and demanding – visitor to the executive suite. Have you space in your schedule for this?

The Problems are Known Beforehand

They’re not. Scrum was created to shine a light on each dysfunction in the organisation. Many of these dysfunctions will have been around for years, if not decades, hiding in plain sight. Managers may think they know what the problems are, Scrum will say something different. Are you prepared to revisit your fondest assumptions?

Hire and Forget

Many folks hiring Scrum Masters assume they can just hire and then leave the Scrum Master to just get on with “fixing the team”. Any Scrum Master worth their salt will demand much time from the senior managers outside the development function. Do you have the time to commit?

All Scrum Masters Are Much of Muchness

Certification can make it seem that all Scrum Masters offer much the same level of skill, experience, and ability to contribute. Not so. Scrum Masters, being human beings, are just as variable as other humans. Do you know the kind of person that will best suit where you want the organisation to be in three, six, twelve months from now?

The Individual Can Trump the System

Many organisations look to the Scrum Master hire to come in and “fix” the dev team, with little understanding of how the existing assumptions, policies, structures, etc., of the organisation can cripple even the best Scrum Master. Deming’s 95% applies here as much as elsewhere. Are you ready to change such things, to enable the Scrum Master to add real value?

The Scrum Master is an Interim Hire

If you believe that the Scrum Master is there to “kick-start” the team, then you’ll miss the key value-add of any Scrum Master (or Agile Coach, or Organisational Therapist, for that matter). Every dev team can improve faster, feel better, and produce better software with the full-time, long-term availability of a competent coach. If it works for e.g. sports teams, why not for dev teams?

The Scrum Master is a Management Patsy, Stooge or Dupe

There are undoubtedly some Scrum Masters out there that are just doing it for the money, willingly toeing the management line, caring little for real improvement or the well-being of their teams. Most, however, will push against the status quo. Which kind do you want to hire?

Scrum Masters Are Selfless

They’re not. They’re just human beings too. They have needs. Most often, the need to make a difference is strong in them. Stronger than the need to conform. Or the need to make money. Making a difference is what you’re hiring them for? But they’re not super-men and -women, able to wave a magic wand to make things happen. So are you prepared to see the changes the teams propose regularly get actioned? Or is their morale and continued engagement not so important to you?

Summary

Most times, those appointing a Scrum Master find themselves in a Market for Lemons – being unable to discern a good candidate from the rest. Making a “good hire” then becomes largely a matter of pot-luck. (See also: Make Bad Hires).

And once a hire IS made, the challenges, far from being over, are only just beginning. Are you creating the kind of conditions in which your new hire can thrive and add real value to your development efforts, or are you just tossing them into a maelstrom and letting them sink or swim unaided?

Good luck!

– Bob

Further Reading

The Perfect Scrum Master ~ Agile Scout

Code Refactoring

Don’t ask me why I’m writing this post. It’s bound to get me into trouble.

Anyways…

What Is Refactoring?

Code refactoring (according to me) is taking a piece of code, code that is already working, and revising it – typically in small steps – to make it more readable, more efficient in execution, or otherwise “better” in one or more ways. Folks expect that such pieces of code will exhibit the same (unchanged) behaviour before and after refactoring.

Aside: This “invariant behaviour” itself seems arguable, as in practice many refactorings leave the code with different “-ilities” (non-functional characteristics – for example, execution efficiency). I suggest claims for such equivalence (of behaviour) are, in general, bogus. “Passes the same tests” is not a great yardstick – how many teams have a suite of tests checking all “-ilities”?

Refactoring is Waste

Given that the piece of code in question is already working, then doing more work on it could be construed as waste (i.e. not adding any value). But hang on. There’s more to it than this.

Firstly, “working” is a relative term. In the Antimatter Principle vernacular, “working” means “meeting some folks’ needs, to some extent”. We can always meet folks’ needs better. So the question then becomes, “when to stop?”. When is any piece of code “good enough”? We can really only answer this question when we have some general understanding of what “good enough” means, for each and every person involved.

Aside: How does your team go about soliciting and sharing information on what “good enough” means?

Why Not Make It Right First Time?

Well, there are some valid reasons. Cognitive load perhaps being the most relevant. Many coders just can’t always get their head around every aspect of the code they’re writing, all at the same time. Many find it necessary, at least sometimes, to defer some considerations – such as performance or readability – until they’re got something roughly “working”.

And then there’s the question of coders’ competence, and intellect, as well as the working environment and coders’ states of mind, from moment to moment.

So, for many coders, right-first-time is just beyond their present capability-in-the-moment.

All this doesn’t change the basic fact that refactoring is waste (muda, in japanese). It does beg the question, though, as to whether it is type I or type II muda:

  • Type I muda: Non-value-added tasks which seem to be nevertheless necessary.
  • Type II muda: Non-value-added tasks which can be eliminated immediately

Why Bother with This? Isn’t it a Storm in a Teacup?

My ha’penn’orth: If we choose to regard refactoring as muda, then we have our eyes open to reducing it, to writing better code on our first attempt, learning and finding other, less wasteful means to meeting folks’ needs, and getting progressively better at our craft. If we choose to see refactoring as part of our regular toolkit of practices, we may be less inclined to search for better ways, and more inclined to just live with it.

And, honestly, the whole “what is waste” question from the Leanheads seems contrived and mostly arbitrary when it comes to drawing a waste/no-waste line. IMO there’s not so much a clean line as a broad and fuzzy overlap between what is and what isn’t value-adding, especially when one considers the needs of all stakeholders, and not just the needs of the “customer”. See also “What is value”.

– Bob

Postscript

[29 March 2015]

What is “good enough”? Generally, when the stakeholders each  say “that’s good enough for me”. And how might we get to such a point? By showing them stuff, allowing them to play with it, work with it, and seeing to what extent what we have given them, to date, meets their needs.

Given we may from time to time give them stuff they’re not so happy with, and choose to try again, I’m minded to ask “how can we minimise the effort and investment in each ‘candidate release’ whilst maximising the relevance of said release?”.

%d bloggers like this: