Archive

Doctrine

The Folks That Matter™

Stakeholders, team members, the Big Team, customers, users, snakeholders – call them what you will, they’re the people that we’re doing the work for. They’re the people to whom we deliver the fruits of our efforts. They’re the people whose reactions – and emotional responses – decide the success or failure of our endeavours.

Personally I like to call them The Folks That Matter™.

By way of example, Here’s a partial list of the groups and individuals that are candidates for inclusion in the set of The Folks That Matter™.

  • Your organisation’s Core Group
  • Your manager
  • Your project manager
  • Senior managers and executives
  • Your dev team
  • Other dev teams
  • Ops people
  • The PMO
  • Testers (when separate from the dev team)
  • QA folks (when present)
  • The Process Group (when separate from the dev teams)
  • Your business sponsor(s)
  • Other people across your organisation
  • Your (end) customer(s) (and their purchasing departments)
  • Commercial partners
  • Regulators
  • Wider Society
  • The Planet (Gaia)

The Interesting Angle

For me, when I’m involved building stuff, I have a need know who we’re trying to please, delight, satisfy, or otherwise engage with and deliver to. I need to know what folks need, and who to ask about the details of those needs, if and when the detail moves to front of mind. I need to know whose needs we can successfully discount when the inevitable resource (time, money, effort) crunches come. Whose needs we can reasonably consider as outside the scope of the endeavour in which we’re involved? And I need some heuristics to guide us in decisions on including, excluding and prioritising folks and their needs.

But there’s something much more interesting than who’s on and who’s off the list of The Folks That Matter™, at any given time. The much more interesting question for me, as an Organisational Psychotherapist, is: What governs the choices? How do folks get added to or removed from the set of The Folks That Matter™? Are the means the product of rational thought, discussion and evolution, or maybe they’ve just happened, or been cargo-culted. And what are the consequences of the prevailing means? What impact do those means have on the success or failure of our endeavours? And therefore on our bottom line?

By way of example, here’s some common means for tackling the question of means:

  • Consensus
  • The Advice Process
  • Autocracy
  • Dictatorship
  • HiPPO
  • Cost of Focus

(Aside: Each collective mindset in the Marshall Model has its own popular choice for these “means”: Autocracy for the Ad-hoc, Dictatorship or HiPPO for the Analytic, Consensus or the Advice Process for the Synergistic, and e.g. Cost of Focus for the Chaordic).

Is it helpful for folks on the dev team to be involved in some way in maintaining or keeping the list of the The Folks That Matter™? Is that possible, in any given organisation? Is the question even discussable?

When Resources Are Limited, Some Folks, Needs, HAVE To Not Matter

And what about the folks that don’t matter (that don’t appear in the set of The Folks That Matter™? I know many readers will baulk at the idea that some folks and their needs don’t matter. But, please, get over yourselves. In any situation where resources are constrained (i.e finite, not infinite), choice HAVE to be made. Lines drawn. Resources committed to some areas and held back or withdrawn from others. How could it be otherwise? Inevitably then, in this particular frame, there must be Folks Who Don’t Matter™.

Cost of Focus

Don Reinertsen states that the Cost of Delay – the financial or economic cost of prioritising one feature over another – is rarely considered in most organisations. Put another way, the way in which delivery priorities are selected and adjusted, the frequency and means of such adjustments, etc., are rarely discussed, and rarely even discussable.

I propose that Cost of Delay is a subset of the wider question stated above. The question of Cost of Focus.

By definition, we are not meeting some needs when we choose to or otherwise exclude certain folks with their particular needs from the set of The Folks That Matter™.

Maybe those excluded folks and their needs are indeed irrelevant, or their exclusion has little impact – financial or otherwise – on the success of our endeavour. But maybe, contrariwise, some of those excluded needs are in fact critical to our “success”. How would we know? The arguments for Cost of Focus are much the same as for its golden child, Cost of Delay.

FWIW, I’ve seen countless projects stumble and “fail” because they inadvertently omitted, or chose to omit, some crucial folks and their needs from the their list of The Folks That Matter™. Get Cost of Delay wrong, and we lose some money. Sometime a little, sometime a lot. Get Cost of Focus wrong, and we more often lose big time. Cost of Focus often has a much more binary impact.

What is Cost of Focus?

Cost of Focus is a way of communicating the impact, on the outcomes we hope to achieve, arising from excluding or including specific folks and their needs. More formally, it is the partial derivative of the total expected value with respect to whose needs we focus on.

“Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organisation.”

– Donald G. Reinertsen

Similarly, I’d say that unless and until we have a handle on Cost of Focus, the golden key of Cost Of Delay remains firmly beyond our grasp.

Put another way, until we have a means for deciding whose needs to attend to, the particular order in which we attend to those needs (cf. priority, Cost of Delay) is moot.

– Bob

Further Reading

Who Really Matters ~ Art Kleiner

Not Obviously Wrong

What’s obviously wrong in software and product development? The list is continually changing, but here’s some stuff which was not obviously wrong ten or twenty years ago, which has recently become obviously wrong, at least to many people in the world of software development:

Obviously Wrong

  • Big batches and queues of work (aka Waterfall)
  • Utilisation (i.e. keeping resources fully busy)
  • Ignoring stakeholders
  • Big Design Up Front (BDUF)
  • Violence in the workplace
  • The daily commute

And here’s a list of stuff which has not (yet) attained the status of “obviously wrong” – and so appears in the list labelled “Not Obviously Wrong”:

Not Obviously Wrong

  • Estimating
  • Management
  • Command and control
  • Telling (ordering) people what to do
  • Leadership
  • Specialisation
  • Cost accounting
  • Projects
  • Big developments in big chunks with big groups of people
  • Ignoring the costs of delays
  • Testing
  • Demanding compliance to defined ways of doing things
  • Separating ownership of the way the work works from the people that do the work
  • Agile
  • SAFe
  • Scrum
  • Kanban Method
  • Work
  • etc.

How do items get to move from the one list to the other? (note: everyone has their own two lists, and each item moves at different times for different folks). How do your two lists look, at the moment?

Unlearning

Looking at this another way, the obviously wrong list above has items that, although once not obviously wrong, now appear on many folks’ obviously wrong list, having made the transition through e.g. a process of reflection, evaluation, discussion and above all UNLEARNING.

No Hashtags

FWIW, it occurs to me that we might choose to regard the raft of #No… hashtags on Twitter as opportunities to consider in which of our own – and others’ – lists the related (hashtagged) topic appears.

– Bob

Business Development

The word “development” in the phrase “business development” has always meant something very different than in the phrases “product development” or “software development”. The term “business development” is generally taken to mean finding new customers, building customer relationships, and such like. And thus responsibility primarily resides in the Sales & Marketing silo.

Maybe this is one reason why the idea of “developing” a business, in the same sense as developing a product or a software system, is pretty much unknown to business folks. Many’s the time I have invited business folks to consider the merits of taking a “development”approach to the construction and evolution of their business, only to receive little response other than a sea of blank faces.

Which makes me sad, because there’s an enormous amount of “development” practice, expertise and skills available to apply to the challenges of developing a business or other organisation. I’d say that some 80% of the know-how involved in developing products or software systems is directly applicable to “developing” an organisation.

Have you ever suggested to business folks that “development” know-how could have a massive impact on their bottom line? Or otherwise effectively meet many if not all of their core needs? What kind of reactions have you seen?

– Bob

Further Reading

What, Exactly, Is Business Developoment? ~ Scott Pollack
Prod•gnosis In A Nutshell ~ FlowchainSensei

I Love To Play With Organisations

Having churned through many, many strap lines and personal branding statements over the past few years, I feel I’ve finally found one I like. One I can live by, and attempt to live up to:

“I love to play with organisations.”

I accept it’s a statement open to interpretations other than the one I have in my head. And maybe that ambiguity is a positive, in any case.

It’s The People

To clarify, I love to be involved with communities of people, contributing to what’s alive in those communities and in the people that make them up. I find joy in making and sharing relationships. And in attending to the needs of others. And some joy when that’s reciprocated, too.

I choose to call the nature of my involvements “play”. I accept the risk that some might choose to regard this as frivolous. I’d very much like to rehabilitate the idea of play as something positive, weighty and valuable.

“Accept the fact that we have to treat almost anybody as a volunteer.”

~ Peter Drucker

And what are volunteers but folks who want to play at what they’ve volunteered for?

In Practice

In practice, playing with organisations, for me, means getting involved with people as they work – or better, play – each day. Listening to how they feel and what they guess they and their communities might need.

Playing together with them to see and explore together how their individual needs dovetail into the needs of the communities in which they live, work, and play. And asking the odd (sic) question here and there to invite folks to consider if their current assumptions and modes of working/playing/living best suit their needs, or if there may be other ways, more effective ways, to do that.

I’d go so far as to declare my support for Marshall Rosenberg’s suggestion:

“Don’t do anything that isn’t play.”

~ Marshall Rosenberg

– Bob

Further Reading

Serious Play ~ Michael Schrage
LEGO Serious Play ~ The LEGO Group

Twelve Signs Of A Great Agile Evangelist

HolyAgile

1. Don’t Talk About Agile.

The first rule of evangelising Agile is: You do NOT talk about Agile. The only folks who want to hear the word – or the gory details – will be those who are looking for a badge of some kind. Or for bragging rights at the golf club. Or tyre-kickers. Strong prospects will not be interested in the label, or the details, but rather in the fact that you understand and care about their problems (empathy) and have useful – and proven – solutions for them to apply. Some of these useful solutions may involve Agile things. Shhh. For example: Talk about their business issues, and the issues common to their business domain. Telcos might be interested in better customer service, and better customer experiences when using their online services, apps, etc..

2. Know Your Cause

“Doing Agile” is not much of a cause, really. Even “being Agile” doesn’t quite cut it. Why are you enthused by Agile? Personally, I see it as a means to move folks closer to a workplace – and a way of working – that allows those folks to realise more of their potential and get more of their needs met – whilst seeing others’ (customers, suppliers, managers, shareholders) needs better met, too. For example: “Effective agile means people more engaged with their work, more focussed on our customers – and our customers more engaged with our products.”

3. Get down with your motivation

Whatever it is that motivates you, embrace it. People can sense half-heartedness and dilettantism. For example: “We’ve seen major steps forward in happier workers, and organisations which are a joy to work in, and with.”

4. Work With Fertile Soils

Plant your cause’s seeds in fertile minds. With folks that are ready or at least willing to listen. If they think they know what their problems are, and that their existing strategies are good for addressing those problems, don’t waste your – or their – time. There will be a few folks who are either unaware of their problems – these may listen, or aware but dissatisfied with their current strategies (solutions). For example: Engage with new prospects, equipped with a checklist of those things that you believe signify fertile soils. Make it an early priority to gather the information needed to complete the checklist. If a new prospect rates poorly on the checklist, decline their kind offer to take things further.

5. Connect To Folks’ Needs

Make your cause relevant and specific to individuals and their existing needs. Help them see how your cause is a more effective strategy for them than their existing ways of working, and thinking. Of course, to connect with folks’ needs, you’ll have to attend to (explore) those needs. For example: Ask your contacts in the organisation what they need. Enquire as to whether there might be others they could suggest with whom you might have similar conversations. Discuss how new ways of working might address some of their needs, individually and collectively.

6. Supply Metastrategies

Many folks need help in acquiring a suitable metastrategy or two before they can move on from their existing strategies and adopt the one(s) you are proposing.

7. Be Honest About The Pitfalls

In many sales situations, standard advice is to avoid talking about the negatives. In Agile adoptions, avoiding mention of the pitfalls only sets up the client for failure. As DeMarco and Lister said in Waltzing With Bears “Risk Management is Project Management for grown-ups”. Maybe your audience has few to no adults? Then RUN! For example: Talk about the rates of failure (generally estimated at somewhere between 50% and 95%). Talk about the common failure modes (faux agile, management discomfort and resistance, change fatigue, organisational cognitive dissonance, etc.). And talk about some possible mitigations for those common modes.

8. Talk About The Benefits

What are the benefits? Not the old chestnuts of “faster, cheaper, quicker”. But benefits that directly address their own particular specific pain point(s). For example: “I understand your biggest competitor can add major new features to their flagship product in six weeks or less. With the necessary changes, we believe that your team could do the same, in timescales as short as two weeks.” In my post “Pitching Agile” I describe using The Three Box Monty as a sales tool in “selling agile” to executives.

9. Make The First (Or Next) Step A Small One

The Kanban Method, for example, cunningly says “start where you are”. Although this begs the question – where else could one start? In any case, engage the prospective client in discussing options and help them come up with their own way forward. For example: Visualisation (of a part of the current workflow) or explicitly limiting work-in-progress (recognising current implicit limits) might be places to start.

10. Don’t Try To Motivate People

Rah-rah motivational speeches and miraculous stories are best left for the God Squad. They have an audience that responds to that kind of thing. Use empathy rather that motivation.

11. Be Organised

Wow. Really? Not “appear well-organised” But actually be well-organised. For example: Have standard templates, checklists, and other documents and planning tools ready and to hand for each new prospect. Keep track of contacts, needs, dates, conversations, and so on. Again, clients and prospects can tell when you’re organised.

12. Be Humble

Don’t proselytise dogma. Don’t make grandiose claims. Don’t make any claims at all. Not even when you have ironclad evidence. Evidence rarely sways anyone. Great evangelists connect with people, and their existing needs. If what you’re selling isn’t what they need, then smile, wish them well, and move on.

– Bob

Further Reading

The Art Of The Start ~ Guy Kawasaki
The Art Of Evangelism ~ Guy Kawasaki
Value Forward Selling ~ Paul DiModica

What Is Agile Software Development?

The term “agile” now signifies whatever folks want it to. It’s a term that has achieved widespread recognition within the software development field, and with that recognition, dilution to the point of near meaninglessness.

Agile was (circa 2001) a reaction by a bunch of experienced, senior developers to both the conventional “heavyweight” and widespread “cowboy coding” approaches to writing software prevailing at the time.

Forget about talk of incremental, iterative approaches. Forget about “inspect and adapt”. Forget about “embracing change”. Forget about “quicker development of higher quality software”. Forget about “earlier realisation of investment”. Forget about methods or frameworks like Scrum, Kanban, DSDM, XP, etc.. And forget about practices like sprints, wall-boards, and the whole practices nine yards.

These are all post-hoc rationalisations of one basic truth: The Snowbird folks and their fans – then and now – were fed up with wasting their lives on failed and “challenged” software projects, on make-do-and-mend development, and wanted to do something about the quality of their lives at work. Theirs, and their peers. They felt a need to make more of a difference to the world than then-current software development approaches allowed.

Meeting Their Own Needs

Put another way, their championing of the agile cause was a means for developers everywhere to – rather unilaterally – attend to their own needs, including more closely living their (Theory-Y) values.

Sadly, lacking a whole-system, all-stakeholder, organisational-dynamics perspective, the result was a somewhat parochial thing. A thing that failed to recognise that software and its development rarely exists in isolation, and much more often happens in a context largely outside the control of those folks directly engaged in writing the software.

Now, some fifteen years on, we can see that the insanity – and tragedy – of agile – lies in the Sisyphean task of trying to build effective teams – and ways of working- inside ineffective organisations.

– Bob

Capability

There’s an old saw that goes:

“If you want to make a great product, build a great team and they’ll make the product for you.”

From my observations, few organisations subscribe to this homily. I’ve always wondered why.

Is it that organisations don’t want to make great products? I’ve certainly seen some of those. Organisations where everyone is just getting by. Keeping their heads down. Expending little if any discretionary effort. Today it seems trendy to call this “disengagement”.

Or maybe it’s just too much trouble. Building a great team rarely just “happens”. People, from senior managers through to the teams themselves, generally have to put a lot of effort over a sustained period to build a great team. And what happens when the product is delivered and the team disbanded? Like the labours of Sisyphus, we start all over again? That seems a demoralising prospect, to say the least.

Or is it that organisations just don’t believe it? That they don’t see a connection between great teams and the capability to build great products?

Or, perhaps it’s not even on the organisation’s radar. That people might believe the old saw, if they were paying attention to it, but because so many other things take priority, the question of i.e. a strategic capability for product development, or even just software development, doesn’t come up? Doesn’t get considered, discussed, acted upon?

Or, maybe organisations are still stuck in the past, not believing that this software thing will catch on, and that the product thet’re creating at the moment is the last one they’ll ever be call upon to make? Why invest time and effort on building a capability that has only one project – the current project – in which to provide a return on investment?

Or maybe any one organisation just can’t serve two masters. That organisations focussed on delivering products to market just can’t focus simultaneously on building a capability for the future, too.

Or maybe there’s not enough money to make it happen. Like any investment decision, the money has to come from somewhere. Short-termism seems endemic in many organisations, particularly the larger, publicly-listed ones. Jam tomorrow never looks as attractive as jam today.

Or perhaps the organisation has no faith in its being able to keep its people, and thus no faith in its ability to sustain any improvements in its capabilities. Perhaps its business model is predicated on high staff turnover, low wages and the idea that “people are merely cogs and resources”. Where this is true – and I have seen some organisations that think like this – then it might be an entirely rational response neither to invest in people as individuals, nor in the organisation’s capability as a whole.

Whatever the reason, I see organisation after organisation where people are stressed beyond endurance because the organisation is not up to snuff in its ability to deliver new products and product enhancements effectively.

I can’t fathom why this is so widespread, and so persistent – and yet I wish I knew.

– Bob

Afterword

Actually, if we look at the issue though the lens of the psychologist, we might suspect that the current situation is a product of people – and especially the Core Group – getting their needs met, albeit in sub-optimal ways. Do Core Groups not need their organisations to have an effective software or product development capability? Given the many ways I have seen organisations degrade or destroy their capability over time, I think this is a valid question.

%d bloggers like this: