Monthly Archives: February 2013

Manage As If You Meant It

(With thanks to Keith Braithwaite for inspiring the title of this post)

Wouldn’t it be great if you had a specification describing the “API to your manager”? I mean, think of all the things a useful manager can do for her people, and how many of these things never happen – or at best, happen haphazardly – because no one knows they’re there, how to invoke them or how to track things?

Aside: At this point, you may just be reminded of Robert K. Greenleaf’s idea of Servant Leadership. If we have to have leadership at all, then maybe servant leadership is a reasonable kind of leadership to hope for. Or perhaps Host Leadership.

As well as providing generally improved clarity regarding what a manager can and will do, a well-defined API might – as Roger Martin writes in The Responsibility Virus – “help people avoid the natural predisposition to screw up the handling of responsibility in ways that undermine their goals and well-being,”

If a manager embraced the idea of an API, and, more specifically, wanted to develop one, how might that happen?

Aside: I’ve been musing on the idea recently, as an offshoot of some work I’ve been doing on Product-Development-as-a-service. This latter may likely be the topic of a future post.

The Manager API

So, the thought occurred to me, could we use something like BDD to facilitate a conversation between a manager and the folks to whom she’s providing services – not least the folks she’s “managing”? (Remember – Servant Leadership). In other words, what benefits might accrue from having clarity on what the manager can (and can’t) do for her people, and for others who might, from time to time, also ask her to do things for them?

Here’s a couple of examples of stories that might be relevant for this “Manager API”:

Story: Developer Needs a New Piece of KitIn order to work more productivelyAs a DeveloperI need to have a way to obtain the necessary kit (computers, peripherals, software tools, etc). for the job at hand.Scenario 1: I have a sudden need for a piece of kitGiven I have a sudden need for a new piece of kit When I request that new piece of kitThen...Story: Development Team Needs a New Team MemberIn order to continue meeting commitments to our stakeholdersAs a Development TeamWe need to find and enrol a new team memberScenario 1: We know of someone who could fill the roleGiven some folks already know someone who would be a good fitWhen we need to make them a job offerThen...

The TDD Connection

OK, so let’s assume that our manager has been having conversations with her stakeholders, and has identified some (early) versions of some “management” stories worthy of implementation. How to approach such implementation?

Here, might Test Driven Development be helpful? Using TDD, the service implementation can emerge and evolve without much (hard) thinking. Here’s the vanilla TDD four-step red-green-refactor process:

Add a test – the simplest possible
See it fail (red)
Make all tests (to date) pass, using the minimum amount of instructions (green)
Refactor

Using this approach, the manager can – incrementally – implement some part – or all – of each “service” story, in turn. Of course, the “instructions” will not likely be coded in a programming language, for execution by a computer, but in human-readable e.g. pseudo-code or work instructions, for herself, and for others helping her deliver the service.

Your thoughts?

– Bob

Intervention on People Issues is a Red Herring

February 21, 2013

Agile, Coaching, Organisational effectiveness

11 Comments

Intervention on People Issues is a Red Herring

Photo Credit: StuartWebster

In his typically assertive (cough) style, John Seddon in this video clip hits a particular nail on the head.

“Intervention on people issues is a red herring; but a popular red herring amongst Western management thinkers.”
~ John Seddon

It’s not that people don’t matter, it’s that there’s a paradox here: change the system and behaviour change comes for free. Also known as “don’t work on the 5%“.

Managers As Coaches

I’m writing this post because the implication for the trendy “managers as coaches” idea seems clear. If a manager is trying to coach a member of their staff, they’re not only “working on the 5%”, they’re also likely distracting themselves from their real job by spending less time working on the system.

“The productivity of work is not the responsibility of the worker but of the manager.”
~ Peter F. Drucker

How likely is it that coaching, whoever is doing it, is merely helping people cope better with the dysfunctions of the systems they find themselves working within? Not that an improved ability to cope with feelings of e.g. frustration, disempowerment and disengagement is without merit. But maybe that’s not what folks are looking to coaching to deliver?

Only when there’s a possibility of changing the system will coaching – specifically, coaching in how to change the system – provide any real value and meaningful change.

How often do coaches have any influence on – or recognised part to play in – such systemic change?

– Bob

Stakeholder, defined

February 19, 2013

Product development, Snippet, Software development

Stakeholder, defined

In my previous post I talk about “stakeholders”. I occurs to me that I have used this term for so long that the definition I have for it may elude some folks, and differ from some other folks’ definitions.

So here’s my definition:

A stakeholder is any person that stands to (possibly) gain or lose something from a specific proposed or actual endeavour.

Or, expressed in terms of needs:

A stakeholder is any person with needs that might be met – or jeopardised – because of a specific proposed or actual endeavour.

Aside: Often, I find it convenient to subdivide the needs of any one individual, according to the various role(s) they may play in an endeavour. For an example of this, see my post entitled “Nonviolent Project management“.

– Bob

Effective Product Development

February 19, 2013

Organisational effectiveness, Product development

5 Comments

Effective Product Development

One question that has been preoccupying me in recent weeks is:

“What makes for effective product development?”

Having pondered on this question for a while, my own answer is presently quite simple:

“Meeting the needs of the stakeholders.”

Note I don’t say “Meeting the needs of the customers“ or “delivering value”. I do not single out any particular constituency of stakeholders, nor any particular kind of need.

So what does this statement mean? Let’s deconstruct it:

“Meeting…”

Not exceeding. Not falling short. Exactly meeting. Not that we’ll ever be able to meet the stakeholders’ needs exactly, for we will never be able to understand them or define them exactly.

“You cannot define being exactly on time.“
~ W. Edwards Deming

But it’s a consummation to which we can aspire, at least. And one to approach asymptotically.

“…the needs..”

Needs. Not wants. Not “requirements”. Not what folks say they need. What they actually need. At a specific point in time. To the extent that we have a product which meets folks’ needs, then we have a successful product. And we might do well to remember that rarely are needs of different stakeholder in harmony, congruent, compatible. We have to balance the various needs as best we can. We have to resolve conflicts. And no, I don’t mean compromise. Sometimes, balancing the various needs is just not going to be possible. So sometimes we’re onto a loser as far as coming up with a completely successful product goes. And needs can change. Over time. In different circumstances and contexts. A man in the desert might need water rather more than a man in a lake. So a successful product today, or in one context, may not be so successful tomorrow, or in another context. So we may have to produce difference variants, and change the product over time, to keep it in the “sweet spot” of the stakeholders’ collective needs.

“…of the stakeholders.”

All the stakeholders. Not just customers. Nor just the producing organisation. Nor just its managers and executives. Nor just the employees – developers and suchlike. Some years ago I coined the term “covalent” to describe this.

[Update January 2022: I have for some time been using the term “The Folks That Matter™️” in preference to “stakeholders”.]

Few product development or software development folks seem to make an effort to explicitly list their stakeholders. Whether specific (people) or generic (constituencies). And fewer still seem to attend to understanding their respective needs, in any deliberate or organised way.

“Corporations should be maximizing stakeholder, not shareholder, value to employees, customers, and shareholders.”
~ Russell L. Ackoff

To sum up then. A product development organisation – or a product development effort – is effective to the extent the it meets the needs of its stakeholders. Simple as.

Having happy customers but dispirited employees is not so effective. Having happy employees but disappointed managers and executives is not so effective. Having happy executives but high costs or impacts on society at large is not so effective. You get the picture.

All the multitude of opinions, ideas, methodologies, etc. that speak to how to go about being effective at product development seem incidental compared to this basic definition of effectiveness.

– Bob

Afterword

One thing has been bugging me about this post. My thanks to Sami Honkonen for bringing it up, which in turn has motivated me to pen this afterword.

He tweeted “This is a local optimum. What about the system? Are you trolling?”

And while I was not trolling, I did fail to mention the systems implications of the answer “Meeting the needs of the stakeholders.”

It was not my intention to imply that effective product development is the sole responsibility of some “product development group” or function. In siloed organisations (the norm), there may be a product development silo. Although that in itself is rather unusual – piecemeal product development and product enhancement being much more common, with the work sliced up and stuffed into the existing silos of marketing, sales, IT, finance, etc.

To get to highly effective product development, the whole organisation must be involved. And ultimately, that means breaking down the silos, liberating the specialists locked inside each, and bringing them together to evolve new “whole products”. Cf. Prod•gnosis.

Meeting the needs of all one’s stakeholders is always a challenge. Doing so effectively within a siloed organisation – focused on local optima – is even more of a challenge. Maybe being highly effective under those conditions is just not possible. I believe that attempting to move to a place of highly effective product development has profound implications for the organisation as a whole. And not least for the mindset that underpins the siloed model – i.e. the Analytic mindset.

Baggage

February 17, 2013

Organisational effectiveness, Product development

11 Comments

Baggage

[Tl;Dr: A list of e.g. Theory-X memes that Analytic-minded organisations will find themselves giving up as they become more synergistic and effective.]

I have recently been giving a series of internal presentations about growing an effective Product Development capability, using ideas from Rightshifting and the Marshall Model as a general framework.

To one slide I talk about the intellectual baggage that any e.g. Analytic-minded organisation will find itself abandoning on its journey to Radicalsville.

Aside: If such baggage is not abandoned, then it’s inevitable that the journey will be.

Another term for “baggage” might be “premises that have become (or always were) invalid”. Here’s a list of such “invalid premises” that I tweeted this morning:

Invalid premise: Management is necessary and desirable.
Invalid premise: Hierarchy is the best way to e.g. organise, coordinate and align.
Invalid premise: People must be told what to do.
Invalid premise: Predictability is a function of tight control and e.g. conformance to rules.
Invalid premise: Predictability has no downside.
Invalid premise: We don’t want any problems.
Invalid premise: Coercion through e.g. fear, obligation, shame or guilt does not alter cognitive function (ability to think well).
Invalid premise: Jackal culture, jackal language is the best and only way to motivate and direct people.
Invalid premise: Feelings and emotions in the workplace are unprofessional and out of place.
Invalid premise: Theory X.
Invalid premise: Productivity and performance of individuals is down to the individual – their innate talents, skills, experience and attitudes.
Invalid premise: Effective knowledge-work is best achieved through factory-like conditions.
Invalid premise: Efficiency is King, effectiveness a nice-to-have.
Invalid premise: Highly (local) optimised parts of an organisation means an optimised (whole) organisation.
Invalid premise: Cost Accounting gives reliable numbers that can be safely used to guide decisions.
Invalid premise: Rationality trumps intuition, emotion and humanity.
Invalid premise: Conscious thought trumps subconscious thought.
Invalid premise: Man is a rational animal.
Invalid premise: Organisations as machines.
Invalid premise: People are as interchangeable as cogwheels.
Invalid premise: Fast is better than slow.
Invalid premise: Anyone gives a hoot about profits.
Invalid premise: “Telling people things” means they will respond rationally and so come to see things differently, and thereby behave differently.
Invalid premise: My organisation works just fine.
Invalid premise: Meaningful dialogue is an unnecessary luxury.
Invalid premise: Investment in e.g. organisation-wide dialogue skills has a poor or uncertain ROI and is not worthwhile.
Invalid premise: Knowledge (grey muscle) work is no different than physical (pink muscle) work.
Invalid premise: Extrinsic motivation raises knowledge-workers’ productivity.
Invalid premise: Truths are absolute.
Invalid premise: Context doesn’t matter.
Invalid premise: A comprehensive plan is a necessary prerequisite to any endeavour.

And here’s some contributions from the community:

invalid premise: Software development is “engineering”, so it’s not knowledge work.
Invalid Premise: Conforming to a standard is all that is required (to produce good work).
Invalid Premise: Regular reports tell people all they need to know.
Invalid Premise: “Projects” are the one and only way to organise and control work.
Invalid premise: Positive feedback – let alone real compliments – are a distraction and will render people complacent.
Invalid premise: Highlighting failures will help people improve.
Invalid premise: Appearing reluctant to engage in a certain activity is a sign of weakness.
(See also the suggestions in the comments section, below).

Have you any invalid premises you feel might be worth adding to this list?

– Bob

Nonviolent Inspiration

February 15, 2013

Organisational effectiveness, Organisational Therapy, Psychology, Snippet

Nonviolent Inspiration

My thanks go to Charlie Badenhop at Seishindo.org for an article containing the following quote:

Do you find yourself avoiding change?

”Change has a considerable psychological effect on the human mind.
To the fearful it is threatening because it means things might get worse.
To the hopeful it is encouraging because things might get better.
To the confident it is inspiring because a challenge exists to make things better.”
~ King Whitney Jr.

So, if our organisations use fear (along with obligation, guilt and shame) in attempts to meet their needs, then the “fearful” will only feel more threatened by the prospect of a bleaker future. How likely is that to bring about positive change – change for the better?

Conversely, if our organisations encourage hopefulness and confidence, then how likely is it that folks will feel encouraged and inspired by the possibilities of a brighter future?

– Bob

Ambitions

February 14, 2013

Agile, Fellowship, Flowchain, Organisational effectiveness, Prod•gnosis, Product development, Rightshifting, Software development

4 Comments

Ambitions

Not in the sense of being ambitious, but in the sense of having some things in mind that I’d like to see come to pass. You might call that an agenda. Or some needs which, upon being met, might make my life more wonderful…

Whatever you choose to call it, here’s my list:

An implementation of FlowChain. I’ve had this model rattling round inside my brain for years now. I see little prospect of someone else taking the necessary leap of faith and implementing it – although the Reaktor folks seem to have evolved something similar, independently – so it’s down to me.
An illustration of just how much like product development is software development. And an illustration of the value – and relevance – of applying decades of well-evolved product development practices to the betterment of software development and a business.
A systems thinking approach to a) product development and b) (more ambitious) running a business. I refer to this as “Prod•gnosis“.
Learning how practical all the above ideas really are, in the crucible of real life. And how much – and in what regards – they need modifying when they come into contact with the “enemy’s main strength”.

“No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength.”
~ Helmut von Moltke

This is my agenda.

As I explained recently in my post “Introducing Rightshifting“, I have no desire to foist these things upon people. But (in the context of my new job) I HAVE been asked to bring my experience and insights to bear. And to “innovate”. The above list seems to be a start, at least.

And just in case you’re wondering about my motivation, it’s not all selfish. I’ve made no secret over the years about what drives my work: to see an end to the egregious waste of human potential happening in software organisations everywhere, today. I believe the above ideas, implemented, will contribute significantly to this aim.

If someone asked me what needs of theirs their participation might serve, I’d offer the following list of possibilities:

The opportunity to learn lots of new things.
A chance to master the art of software development (esteem).
Making a difference. Advancing the art, illuminating the possible, and inspiring others.
The prospect of much fellowship, positive stress, self-actualisation (cf Maslow) and fun!

Am I an idealist? A dreamer? You may choose to make that judgement. Although such a choice (i.e. to judge) would make me feel sad.

“Observing without evaluating is the highest form of human intelligence.”
~ Jiddu Krishnamurti

So who’d like to join me on this journey? How do you feel about my agenda? What’s your agenda? What needs can we meet, together? What might make your life more wonderful? And how might we help each other?

– Bob

Product Development Flow

February 12, 2013

Organisational effectiveness, Prod•gnosis, Product development, Rightshifting, Software development

3 Comments

Product Development Flow

I’ve been seeing a lot of funny looks and blank faces recently. Although not unusual <wry grin>, in this case it’s been when answering the question “What’s your job title?”. My reply, for the record, has of late been “Head of Product Development Flow”.

I suspect that the terms “Product Development” and “Flow” both are causes for confusion and puzzlement. And I also suspect that the combining of them only compounds the bewilderment.

So, here’s my explanation of each term, and then of the combination, along with some minor digressions and mention of other related ideas, along the way.

Product Development

Some folks, myself included, use the term “Product Development” to describe the myriad of activities involved in taking an idea from e.g. a vague concept to a fully-formed design for a product. In other words, the elaboration (a.k.a. “development”) of an idea for a product into something that, once instantiated, is compelling enough that potential customers will be willing to pay money for it. Wikipedia happens to have an entry for “New Product development” (Caution: much misinformation there).

Personally, I regard product development as not only the elaboration of ideas for new products, but also the elaboration of new features for, or variants of, existing products.

Aside: In the world of software and software products, the continual release of updates and new features is the norm, and happens much more frequently than the introduction of completely new products.

Whole Products

Few are the organisations that approach Product Development systematically. Fewer again are those that share Toyota’s practice of explicitly ensuring all aspects of a product design are created in a joined-up way. Toyota’s TPDS has the concept of the “Big Room” or Obeya, signifying their emphasis on getting all the various specialists necessary for creating a “whole product” design (in Toyota’s case, a design for a new product line) together in close physical and temporal proximity. This approach is, in part, what allows Toyota to bring complete new car designs to market – cars rolling off the production line and onto the road – in around 18 months, compared to GM’s 36 months (source: BBC News, 2007).

Flow

Flow (n): the movement of a product or service through the process which creates it.

In the context of product development, we might choose to modify this definition slightly:

Flow (n): the movement of the designs for a product or service through the design processes which create them.

And continuous flow:

Continuous Flow (n): The progressive movement of units of design through value-adding steps within a design pipeline such that a product design or service design proceeds from conception into production without stoppages, delays, or back flows.

Operational Value Streams

There are many way of looking at a business, but the mental image I use most often in the context of Product Development is “business as a series of operational values streams” (cf. Allen Ward), where each such operational value stream’s business-as-usual consists of a bunch of people (often assisted by technology and/or machinery) adding value to some raw materials – and delivering units of product or service for consumption by the business’s customers. These operational value stream folks would use the product designs created by the “Product Development” folks to tell them how to manufacture and assemble the product(s), or in the case of a service, how to deliver the service(s).

Note that in most businesses, organised around silos (a.k.a. functional departments) as they are, the value streams are notional rather than actually manifest in organisational policy. And their business-as-usual rather, erm, haphazard. The day-to-day (business-as-usual) operational processes (the way the work works) are rarely designed, per se, but rather grow up, like Topsy, over time. With much management tinkering.

Prod•gnosis

I’ll just drop a mention of Prod•gnosis in here. Prod•gnosis refers to my concept of having a “Product Development Value Stream”, responsible for the instantiation of each and every operational value stream within a business.

Typically, when a business first decides to launch a new product line, the product design(s) for the product line will be developed, and then these designs will be sliced-up, and stuffed into the various functional departments of the business, alongside the slices of current products. There will likely also be large gaps in the product design, due to an absence of “whole product” thinking. Various functional departments will have to rally round and (reactively) patch these gaps as they see fit.

For example, a Marketing department may be surprised by the imminent arrival of a new product line, and then feel obliged (to jump) to develop the marketing collateral for that new product line.

With Prod•gnosis, each operational value stream is the “whole product” for that product (line). As an integral part of the “Product Development”, all the operating procedures (processes), support and admin systems, interfaces to common “shared” services – such as billing or CRM systems – etc. are part of the design for the operational value stream in question. By “instantiating” this value stream design – by, for example, adding the people and equipment needed to “run” the operational value stream – the business has the necessary means to sell and support the product line in question. This instantiation can happen once, or maybe even several times in e.g. different geographies.

Aside: You may spot some similarities here to the model often used by franchisers.

Of course, Prod•gnosis is an ideal. But one which I suggest is entirely feasible to use as a model, and to “grow into” progressively, as the product development competence of the organisation grows and matures.

And just in case you’re thinking I’m making a case for a big, up-front design of a new operational value stream – I’m well aware of the egregious dysfunctions inherent in BDUF. No, rather I’m thinking more in terms of a Lean Startup-like approach – instantiating version 0.1 of the operational value stream as early as possible, conducting experiments with its operation in delivering an MVP (even before making its 1.0 product line available to buying customers), and through e.g. kaizen by either the product development or – the few, early – operational value stream folks (or both in collaboration), incrementally modifying, augmenting and elaborating it until the point of the 1.0 launch, and beyond.

Product Development Flow

Basically, the idea of Flow – a fundamental concept in e.g. Lean Manufacturing, Lean Service, etc. – relates to the continual delivery of something of value to someone who needs it.

In Lean Manufacturing, it’s the continual delivery of product units – such as cars – to customers.

In Lean Service, it’s the continual fulfilment of service requests in response to demands from customers, a.k.a. “service users”.

And in Lean Product development it’s the continual delivery of (whole) product designs into the business, and thence – via e.g. the operational value streams of manufacturing or service delivery – of instances of those designs into the hands of the business’s customers.

So, pulling this all together: I use the term “Product Development Flow” to refer to the flow of new product designs into the business. The operational side of the business can then take these new product designs, slice them up (and patch the gaps) and stuff them into the organisation, to sell and support alongside existing products.

For businesses that embrace the idea of the “whole product”, “Product Development Flow” refers to the flow of new “whole product” designs into the business.

And for businesses that embrace the ideas of Prod•gnosis, “Product Development Flow” refers to the flow of (one or more instances of) complete new operational value streams into the business (in the case of new product lines). In the case of new features for, or variants of, existing products, it refers to the flow of updates to existing operational value streams. We can imagine we might like to do this incrementally and iteratively, in the Agile way.

Measures

We might choose to monitor the flow of each new product, whole product, or operational value stream – in terms of things like:

Rate or speed of flow (in, say, throughput dollars/day, or function points/month)
Lead time (time between a customer requesting e.g. a new feature and them beginning to use it)
Cycle time (time, on average, between starting on the development of a new product or feature and the completion of that new product or feature i.e. ready for sale)

And we might also choose to monitor the flow through the product development process itself (the design of new operational value streams, or updates thereto):

Rate or speed of flow (in, say, new operational values streams, or updates, per year)
Lead time (time between the business requesting a new operational value stream or update, and its instantiation, ready to serve customers)
Cycle time (time, on average, between starting on the development of a new operational value stream or update, and the completion of that new value stream or update)
Process cycle efficiency (PCE – ratio of value-adding time to lead time)

Big Head

And as for the job title, “Head of Product Development Flow”? For me, it refers to a role with the responsibility for helping folks in the organisation move towards improved flow of new products and updates, new whole products and updates, or new operational value streams and updates, into the business.

To use an analogy, it’s a bit like the role of a master plumber: planning, installing and then overseeing the operation and maintenance of the organisation’s “concept-to-cash” pipeline. Making sure the pipework is fit for purpose, installed competently, continually adapted to changes in circumstance, and kept clear of blockages, scale and corrosion – so that “value” can flow smoothly, reliably and continuously from ideation at one end to satisfied customers at the other.

And what does “improved” mean? Ah, well, that’s a good subject for a future post.

– Bob

Introducing Rightshifting

February 7, 2013

Ethics, Organisational effectiveness, Organisational Therapy, Rightshifting

1 Comment

Introducing Rightshifting

I recently saw a tweet which read:

“Change is about the interaction of competing narratives, whilst change management aims to impose a dominant narrative on others.”
~ @aptviator

When I saw this I thought “Nooooooo”. Not imposition! I hope I don’t do that. Or rather, I hope people don’t perceive my presentations on the subject of Rightshifting and the Marshall Model as an imposition, or an exercise of dominance. Especially after writing much about nonviolence and nonviolent change.

But then I thought about it a bit more. And saw that maybe the tweet in question has some valuable insights to offer.

Looking back, I can certainly recall management consultants and change agents attempting to impose a dominant narrative on others – and in particular on their client and that client’s people. Generally (with complicity by management) in a coercive and violent fashion.

And I can definitely agreed with the first half of the tweet – that change is about the interaction of competing narratives – and moreover the memes and memeplexes underlying those narratives. With the Core Group’s narrative and memeplex generally winning out – however dysfunctional it might be.

I feel uneasy because I need to believe that folks have the freedom to both construct and to follow their own narratives.

“I’m interested in learning that’s motivated by reverence for life, that’s motivated by a desire to learn skills, to learn new things that help us to better contribute to our own well-being and the well-being of others. And what fills me with great sadness is any learning that I see motivated by coercion.”
~ Marshall Rosenberg

I’ve been making quite a few Rightshifting presentations to groups of people recently, and I’d hate to think I’d been inadvertently giving folks the impression that Rightshifting was the new party line. My position of relative influence – at least, as possibly perceived by my audiences – also compounds the risk that some folks may have thought they had and have little option other than to comply or agree.

So, for any of those folks that may be reading this, and as a reminder to myself to make things more conspicuous in future, here’s the kind of introduction that might make my intent clearer:

“Today I’m going to explain Rightshifting, and the Marshall Model. I find these ideas useful to help explain and understand what I see as the root causes of effectiveness – and Ineffectiveness – in today’s knowledge work organisations, both large and small.

“I’d be delighted to hear if anyone here has any alternative explanations – or even partial explanations – for organisational effectiveness. This would meet my need for dialogue, for meaningful personal connections and for learning new things.

“To the extent that the ideas I’m presenting here today meet your needs in explaining these things, please take, use and share as much or as little of these ideas as you see fit.

“I’d be delighted to hear in the future what aspects of these ideas – if any – you have actually found useful and adopted. And which have proven less than useful, or even downright unhelpful, too.

“And I’d also be entirely delighted if you folks would be willing to contribute further to the evolutions of these ideas, and in tailoring them for best fit in this organisation.”

“We should not expect an application to work in environments for which its assumptions are not valid.” #Goldratt #TPS #Lean #tocot
~ @goldrattbooks

– Bob

Manage As If You Meant It

The Manager API

The TDD Connection

Further Reading

Share the joy :)

Intervention on People Issues is a Red Herring

Photo Credit: StuartWebster

Managers As Coaches

Further Reading

Share the joy :)

Stakeholder, defined

Share the joy :)

Effective Product Development

“Meeting…”

“…the needs..”

“…of the stakeholders.”

Afterword

Further Reading

Share the joy :)

Baggage

Share the joy :)

Nonviolent Inspiration

Further Reading

Share the joy :)

Ambitions

Further Reading

Share the joy :)

Product Development Flow

Product Development

Whole Products

Flow

Operational Value Streams

Prod•gnosis

Product Development Flow

Measures

Big Head

Further Reading

Share the joy :)

Introducing Rightshifting

Further Reading

Share the joy :)