Archive

Software development

The Future Of Software-Intensive Product Development

A little while ago I wrote a post posing some questions about what ways of working we might look to, After Agile. Fewer folks engaged with this post compared to some others I have written. So I’m assuming that few are thinking about what we might see as the natural – or even unnatural – successor to Agile.

It is, however, a topic that occupies me regularly. Not least because of the intrinsic flaws in the whole Agile idea. We can, and eventually must, do much better.

Recently, some folks have been asking me about what I see as the future for software- and software-intensive product development (SIPD). Of course, I’ve been answering this question, on and off, for at least the past few years.

In a Nutshell

To sum up my take: In a nutshell, the issues that plague SIPD seem obvious. They’re mostly the same issues that plague all forms of collaborative knowledge work. Issues compounded by the gulf between conventional or traditional work and the new world of work (i.e. the world of collaborative knowledge work) – a new world distinctly unfamiliar to most in the world of work today.

We are faced with various collections of pathogenic beliefs (management, traditional business, Agile, etc.), none of which provide us with a context for EFFECTIVELY tackling the challenges we face in the new world of work – i.e. the world of collaborative knowledge work.

I’m choosing here to list these challenges in terms of needs, and in terms of the strategies – conventional and unconventional – for meeting those needs.

Developers’ Needs

Agile came into being driven by developers attempting to see their needs better met. These include:

  • Less working time “wasted” on mindless bureaucracy and distractions, such as meetings, reports, documentation, etc..
  • More time to focus on making great software, and stuff that delights customers.
  • Improved relationships with co-workers, business folks, customers, and the like.
  • More flexibility to adapt to emerging information, to changing needs, and to things learned along the way.
  • More say in what they work on, the tools they work with, and how they do their work.
  • Approval of one’s peers (including a sense of belonging and community re: the “technical” tribe)
  • And simply, the leeway to just “do a better job” and make a positive difference in the world.

Bottom line: Many developers need to feel valued, purposeful, that they’re making progress (learning) and are recognised for their abilities.

Business Folks’ Needs

Secondarily, but still important in the Agile approach, is better outcomes for “the business”. Agilists have come to recognise the following needs (even though common forms of Agile do not address them).

  • Approval of one’s peers (including a sense of belonging and community re: the “management” tribe).
  • Empathy (meaningful connection with other human beings).
  • A positive self-image.
  • Stability (folks have families to support).
  • Acclaim/fame (folks have careers to pursue).
  • Warmth (of human relationships) – Most business folks are just normal people, too.
  • Peace (i.e. an absence of distress).
  • Purpose.

Users’ / Customers’ Needs

Businesses ultimately stand or fall on revenues. Revenues which depend on their products and services meeting the needs of their customers. These needs include:

  • Approval of one’s peers (including a sense of belonging and community re: the “brand” or “XYZ customer” tribe).
  • A positive self-image (what being a user or owner of a certain product says about you, in your own mind).
  • Stability (folks don’t like to think too hard, or continually learn new stuff for no good reason).
  • Warmth (of human relationships) – Most customers, being humans, value interactions with other human beings.
  • Low fuss (i.e. being able to get their jobs done with minimal distress).

Shareholders’ Needs

Shareholders also have needs which they seek to get met. These include:

  • Approval of one’s peers (including a sense of belonging and community re: the “investor” tribe).
  • Contribution to society (e.g. ethical investments) and communities.
  • Financial returns (investors have families and/or lifestyles to support).

In a future post I’ll be looking at the strategies that people use to get these needs met, including those strategies implicit in Agile methods – and some alternative strategies that might prove

– Bob

 

What’s The One Question A Scrum Master Must Ask?

When interviewing for a new Scrum Master or similar position, we can often intuit much about the position, the team and the company from those many little clues which offer themselves. But one thing often less obvious, and so, worth asking about is:

“How does the blockers’ pipeline work here?”

The key role of the Scrum Master is to facilitate the escalation (and to some extent, resolution) of blockers a.k.a. impediments – problems noted by the team but not actionable / fixable by them because the root cause lies outside their span of control.

Some organisations will already have a pipeline or process for escalating such “blockers”. Many more will not, not often understand the need for one and the role of non-team people in that process.

The prospective Scrum Master may want to see how the land lies before committing to a position in an organisation that is not ready or able to institute an effective blockers’ pipeline.

– Bob

The Twelfth Principle

There are four values and twelve principles connected with the Agile Manifesto. As the folks at 12thPrinciple say,

“the four values and eleven of the twelve Agile principles do not address the wider organization at all.”

This is one of the key reasons why so many Agile adoptions (circa 80%) fail to deliver on the Agile promise.

I have this weeks added my name to the list of signatories at 12thprinciple.org.  Not because I totally and wholeheartedly embrace the “Twelfth Principle” in its current form. But because I wish to lend support to the idea that it’s the wider organisational context that utterly determines whether any kind of progressive change effort or initiative succeeds or fails.

The Twelfth Principle (n.b. actually appearing fifth in the list of Principles behind the Agile Manifesto) reads:

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”

I see some basic flaws in this, but it does serve to highlight (at least, implicitly) the role of the wider organisation.

Here’s my take on these “flaws”:

  • Projects. I see little point in using projects to frame development efforts. Personally, I subscribe to #NoProjects, and FlowChain as a practical means to replace the whole idea of projects, in favour of product development flow.
  • Individuals. Yes, teams consist of individuals. But Man is a social animal, and collaborative knowledge work – such as software and product development requires society, not individuals. I get the idea that we’re really taking about a focus on people, here. As opposed to say structure, hierarchy, process, or what have you.
  • Give. Not so much give as in charity or largesse, but give as in make available, enable.
  • Them. Shades of them and us? Unfortunate choice of pronoun.

With a free hand, and the awesome benefit of hindsight, I might represent this principle thusly:

“We accept that collaborative knowledge-work proceeds best when we place people at the core of our focus.
We recognise that people do best within a supportive environment,
where needs are shared and attended to by all.”

How might you rephrase this principle?

– Bob

 

 

The Organisational Psychotherapy Approach To Agile Coaching

GroupTherapy

What’s the point of an Agile Coach? I guess the most common answer would be “to make development teams more productive”. After all, Agile Coaches cost money, and they don’t do much in the way of development work themselves. If they’re not a “force multiplier” for one or more dev teams, then where’s the cost-benefit justification?

Personally, I’d suggest the most common reason, although rarely articulated as such, is “to raise the pace of improvement”. Or, worst case, to reduce the pace of degradation of performance (given that things are always changing, and some teams may not be able to even keep abreast of change).

There are two essential problems with seeing the appointment of an Agile Coach as a means to improve a development team’s productivity: The Motivation Fallacy and the Local Optimisation Fallacy.

The Motivation Fallacy

Many development teams have little to no manifest interest in improving, nor therefore in the pace of any improvement. This is often compounded or aggravated by the appointment (a.k.a. imposition) of a coach to “encourage” them. An iron first of coercion, even in a velvet glove of a smiling, happy coach, often offends. And rarely is the agenda for improvement part of any joined-up initiative. Much more often it occurs at the behest of one or two people looking to secure their personal bonus or make a name for themselves as innovative go-getters. Such personal agendas also serves to alienate people further, both the folks in the development teams and those folks up-stream and downstream on whose cooperation any joined-up approach would depend.

The Local Optimisation Fallacy

Unless the development team is the current constraint limiting the throughput of the whole organisation, improving the team’s productivity has little to zero effect on the productivity of the whole organisation. Some authorities on the subject go further and suggest that in these (non-bottleneck) cases, improving the team’s productivity will actually make the performance of the organisation as a whole worse. (Cf. Ackoff)

Even when the development team IS the current bottleneck, improving it soon moves that bottleneck elsewhere in the organisation. Agile Coaches and other folks in the development function rarely have the remit or authority to follow that moving constraint. And so rarely if ever does the improvement initiative continue in the newly-constraining area of the business.

Where Organisational Psychotherapy Comes In

Both of the aforementioned fallacies arise in organisations with low levels of congruence. Such organisations have a gulf between how they perceive themselves (self-image), their ideal self, and how they actually experience life. To paraphrase Carl Rogers:

“Organisations behave as they do because of the way they perceive themselves and their situation.”

Where an organisation’s self-image and actual experience are consistent or very similar, a state of congruence exists. Rarely, if ever, does a total state of congruence exist; all organisations experience a certain amount of incongruence.

Organisational therapy serves to help willing organisations reduce the gulf between their self-image and their actual experience. In other words, to improve congruence. Agile Coaches could do this, given the brief (remit) and skills – and some of the more effective ones likely do already. Albeit intuitively rather than with an explicit understand of what’s happening. Oh so rarely is this remit conferred, or sought, however.

The practical side to Roger’s Theory of Self states that being in a condition of incongruence is uncomfortable; therefore each organisation seeks to become more congruent. When the distance between the self-image and actual experience becomes too great, the organisation is more likely to exhibit both distress and anxiety. Likewise the people within it.

Thus organisational therapy helps to:

  • Increase congruence.
  • Reduce stress and anxiety levels.
  • Broadly improve cognitive function (through e.g. lower levels of stress and anxiety).
  • Indirectly, address a wide range of pathogenic beliefs, which in turn may lead to…
    • Improved motivation.
    • Increased collaboration across silos.
    • More joined-up initiatives (fewer local optimisations).

The Therapist’s Stance

All the above is predicated on the Agile Coach – if indeed it is he or she who becomes the agent in this kind of intervention – adopting more of a therapist’s stance:

Tweet20151124

– Bob

 

What If #8 – Agile Never Happened

Alternate realities are a staple of many science fiction series. Exploring what our world might be like if this or that had or hadn’t happened can help shed light on the significance of a particular event.

The Agile approach to software development, although neither conceived nor born at Snowbird in 2001, coalesced and started to gain traction from around then.

What if the Snowbird gathering had never happened? What if the seeds which led to Snowbird had not been planted, or had fallen on barren ground?

Here’s a few hypotheses, or scenarios, to consider:

The Business Hypothesis

Maybe, in the absence of developers trying to wrangle some effectiveness into the work they were obliged to do, business folks might have got a grip. Unlikely, I grant you. But absent some existing movement to suborn or seize upon, maybe the pain of software and product development might have persuaded the “business side” to find better ways of creating and delivering products.

The Together Hypothesis

Maybe everyone involved in software and product development might have got together and pursued the finding of a joint solution. Also unlikely, I guess.

The More Of The Same Hypothesis

Another possibility is that nothing much would have changed. Developers would have continued, more or less frustrated, in prevailing waterfall or ad-hoc projects and ways of working. Outcomes would have continued to be poor for all concerned. Some may say that this is really what did happen, only the names have been changed.

The Extrapolation Of Prevailing Trends Hypothesis

Maybe trends prevailing circa Y2K would have continued to evolve. Organisations seeking to improve might have embrace and evolved things like project management, CMMI, and so on. I can’t see this as effecting significant change or improvement, but maybe things might have improved slowly, in the order of a percentage point or two annually.

The Radical Hypothesis

Finally – in the list of alternate realities I’m presenting here – we might have seen a (more) radical alternative to Agile arise. Without convenient, ready-made, and packaged “Agile solutions” to adopt, maybe folks who cared might have studied their problems for themselves. Maybe this study might have found the root conditions. Maybe it might have surfaced more radical, more fundamental solutions. Solutions explicitly directed at communities of collaborative knowledge work, at the core role of collective mindsets, people and relationships, and at a system (business) wide approach to both adoption of new approaches and the ongoing use of those approaches.

What do you imagine might have happened if Agile had never been?

– Bob

Other Posts In This Occasional Series

What If #1 – No Management
What If #2 – No Process
What If #3 – No Telling
What If #4 – No Answers
What If #5 – Continuous Improvement Is Useless
What If #6 ~ Agile Nirvana
What If #7 – No Work

The Cold Wet Nose Of Reality

bloodhound

If you’re in the business of supplying IT services, especially software and product development, to your clients, you may be getting uneasy (again). Agile software development, and its close cousin, DevOps, are the latest in a long line of approaches promising to solve the “software crisis”. And like the many approaches that have gone before, their faults are beginning to show, and the chickens are coming home to roost.

As they say:

“…you can’t fool all of the people all of the time.”

I don’t doubt that many solutions providers and consultancies have the best interests of both their clients and their own staff at heart, and are not just focused on their revenues. And just like their antecedents, Agile and DevOps did look promising. But just as with those antecedents, time has shown the core ideas wanting. Or, more accurately, insufficient in the majority of cases.

Why Early Adopters Have Good News

Whatever the approach, its early adopters generally have good stories to tell, about good outcomes. And why not? These folks had the enthusiasm, the curiosity, the drive, and the grasp of the principles to make the approach work. Later adopters, absent some or all of these advantages, have struggled to see useful benefits. No matter what the approach.

That Nose

Truly, the cold wet nose of reality has been sniffing out the latent flaws implicit in Agile and DevOps from the outset.

Smarter Now

I’d like to hope that we’re collectively smarter now. That having seen so many promising approaches come and go, we might be on the verge of seeing beyond the superficial attractions of each new approach. That we may be, finally, developing the deeper lore that will show us why all our approaches to date have sooner or later failed us. I’d like to hope that, But in general, I see precious little evidence of it happening.

“A new type of thinking is essential if mankind is to survive and move toward higher levels.”
~ Albert Einstein

– Bob

Nine Aspects Of Top Developers

topdevs

Ask a hundred people what’s their definition of a “top software developer” and you’ll likely get a hundred different answers. Many definitions may cluster around “someone who can make the computer jump through hoops”, i.e. a technical virtuoso of some sort.

Personally, my definition of a top developer is somewhat different. My definition is someone who:

  1. Understands people and how they – as e.g. users – might find joy in interacting with software.
  2. Understands people and how best to get along with them – e.g. in a team, a business – to create “solutions”.
  3. Understands people and their needs – and how to attend to those needs by e.g. writing software.
  4. Understands herself or himself – e.g. her or his own biases, tastes, limitations and capabilities.
  5. Looks to improve themselves and – together with other people – the way their work works.
  6. Has a broad range of life experiences to draw upon for e.g. inspiration and insight.
  7. Is widely read and informed – and especially, not just technical books, articles, blogs, etc..
  8. Is different and thinks different – to the other people around them. A.k.a. Diversity.
  9. Seeks out and takes ownership wherever and whenever folks’ needs aren’t getting met.

Technical virtuosity, aptitude, coding talent, experience, domain knowledge, numeracy, ability to learn quickly, etc. are all nice-to-haves, but not core to being a “top developer” – at least, from the perspective of e.g. folks paying their wages.

Bottom Line

My bottom line: I’d regard someone a “top developer” if they are highly effective in attending to folks’ needs. Although, just the idea of labelling someone “top”, or not, makes me feel uneasy for its implicit judgmentalism.

“it’s not what you say, or know, or even who you are, it’s what you do that matters.”

I guess my definition is just one amongst that hundred.

– Bob

Further Reading

The Three Virtues ~ Cf Larry Wall

%d bloggers like this: