Archive

Software development

Learn Through Delivering

In my previous post I talked a little about the role of language and vocabulary in shifting focus – from being busy, to attending to folks’ needs. The word ‘deliverable’ emphasises, unsurprisingly, delivery. But what does it mean to “deliver” in the context of i.e. software development?

Inspect and Adapt

For me, delivery is the opportunity to close the feedback loop. To gain some insight into whether what we’ve been working on has been useful to our stakeholders. And to adjust our sights – and ways of doing things – in the light of that information.  So the defining aspect of any and all “deliverables” is that deliverables, by this definition, must be delivered to stakeholders and they must be able to try them out in as near as possible to real-world situations so as to provide meaningful feedback.

Cadence

Just how often might we deliver something for our stakeholders to provide feedback on? That depends on how short we want our feedback loops to be. Myself, I prefer a maximum feedback loop length of two to three days. Whether your teams are in a position to dance to this rhythm, or something slower, kind of depends on your stakeholders and how quickly they can look at, and respond to, each delivery. Keeping deliveries small can help here, by keeping what they have to look at, and their responses, small too.

Artefacts

Of course, there will be things we create, produce – things for our own consumption, like documents, design artefacts, intermediate transformations leading to deliverables, and so on. I choose to call these non-deliverables “artefacts” (or even “non-deliverables”) – to distinguish them from the deliverables on which we intend to seek feedback.

May I invite you to trial a change of perspective – from learning through doing, to learning through delivering – as soon as you have the opportunity?

– Bob

 

Tasks – or Deliverables

In most every development shop I’ve seen, folks’ planning vocabulary has been founded on the task as the unit of work. Long ago, at Familiar, we discovered that a different vocabulary offers some key advantages. Ever since then I’ve found that a planning vocabulary when deliverables are the default unit of work suit me much better.

Some Key Advantages

  • Planning in tasks encourages (subconsciously for the most part) busywork (a focus on activity).
  • Planning in deliverables encourages a focus on outputs (ands thus, closer to outcomes).
  • Deliverables are closer to what stakeholders seek (i.e. having their needs attend-to, or even met).
  • Tasks are generally one stage further removed from needs than are deliverables.
  • Deliverables are, to a degree, ends in themselves – tasks are means to ends (and hence more disconnected from outcomes).
  • I find it easier and more useful to quantify aspects of deliverables than aspects of tasks. YMMV.

Mayhap a focus on outcomes directly would be a further step in the right direction, but for most of the development groups I’ve seen, a single leap from tasks to outcomes might have proven infeasible.

May I invite you to trial a change of vocabulary, and of focus, next time you have the opportunity?

– Bob

 

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

%d bloggers like this: