Archive

Doctrine

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.

No Testing

Testing. Checking. Inspection. Exploration. Learning. Everybody has a different understanding of what testing is. And is not. (Hint: AFAIC, it’s NOT “QA”. And it’s NOT “TDD”).

I’m not going to upset people by offering my own definition. I make no claims to be an expert on testing.

When I’m a customer, I know I don’t want to pay extra just for a product that works as advertised. By extension, I’d not want to pay for testing. I want a product that “just works”. And if asked to pay more, I’d have to enquire skeptically “why can’t you people build it right in the first place?”.

Some years ago now, David Anderson wrote a blog post asserting that “All testing is waste”. I concur. But is it necessary or unnecessary waste (Type I or Type 2 Muda?). And does that categorisation depend on the capabilities of the team(s) – the developers – building the software? If the developers can’t deliver software with the intended levels of defects (which could be non-zero, btw) then maybe testing is a necessary waste, to compensate for that inability. And maybe it’s cheaper and more humane to employ less capable developers, bolstered by testers, than to have capable developers who can meet intended defect levels reliably.

So, do we have to test, despite the customer being unkeen to pay for it? Despite it adding little or no value from the customer’s point of view? Or can we find other, more economic and humane ways to meet the needs testing currently addresses?

Needs

“Testing” is one strategy for getting folks’ needs met. Some of their needs, at least. We might imagine there could be other strategies for getting those same needs met.

What needs does testing address? And who has these needs?

  • Testers need to continue earning a living in their chosen profession, to feel belonging in a community, to earn the respect of their peers for a job well done, to continue their self-development and learning, to add value and make a difference.
  • Customers need stuff that works (that meets their needs), for a price they’re willing to pay.
  • Companies making stuff need to safeguard their reputations and revenues.
  • Managers generally need to appear capable of delivering new products which meet the company’s and customers’ needs, whilst also controlling margins (costs vs returns).
  • And of course every individual may have their own particular personal needs, too.

Strategies

My question is: “Is testing the best strategy for meeting all the above needs?”. It may be the best known. The most widespread. The default. But is it the most economic? The most humane? Indeed, what are the dimensions of “best” here? Or even of “reasonably effective”?

“No Testing” attempts to flag up these questions. No soapbox. Just open enquiry.

– Bob

 

 

 

 

 

%d bloggers like this: