Archive

Monthly Archives: September 2018

Inventing Agile

[Tl;Dr: I invented Agile in UK / Europe, independent of the USA / Snowbird folks, circa 1994].

I was running a project in Europe (Brussels, Belgium) when I first woke up to the value of “process” in delivering working software. It wasn’t the first project I’d been managing, but it was the first time in a corporate environment, with many stakeholders, and with developers and methods not of my own choosing. I have to say that the project was not an unalloyed success.

Upon completing my assignment and returning to England, spurred by my dissatisfaction, I explored the existing literature for ideas about how to do things better. And in my next few assignments I experimented with some of these ideas and began to evolve a coherent approach to software development.

Motivation

I had already long been motivated by a need to see folks able to realise their innate potential. I had often been appalled by the waste of human potential I had seen time and again in places I had worked. I was convinced there must be a better way, and set about finding it.

Influences

Key influences during this time included:

  • RAD (Rapid Application Development – James Martin, etc.)
  • JAD (Joint Application Development)
  • Evolutionary Development (Gilb)
  • Rapid Iterative Development
  • Risk Management (Capers Jones, etc.)
  • TQM (Crosby, Juran, Shingo et al)
  • NextSTEP
  • Modula-2 (Wirth)
  • Eiffel (Meyer)
  • Objective-C (Cox)

The Roots of European Agile

By the time I came to work with the CFO of Barclays, running some internal projects at Barclays head office, I had the kernel of an approach that today we’d label “Agile”. This was 1994.

As you may see from the influences listed above, I was already leaving the waterfall / V-model camp and beginning to favour iterative and incremental approaches.

Even in these early days, the results were outstanding.

Continuing to apply and evolve the ways of working I discovered at Barclays, I then did a tour of some of the major merchant banks in the City, where proven ideas for improving their software development results found some favour.

A couple of years later found me at Sun Microsystems’ UK Java Center, bringing these development approaches to Sun’s major corporate clients looking to transition their development teams into the Java ecosystem.

At this time I began referring to my now well-formed approach as “Jerid”.

Note on the Name

Jerid grew out of two complementary initiatives I had been running for some years named “SPEAR” and “BEAR” – Software Process Engineering And Reengineering, and Business process Engineering And Reengineering. SPEAR consisted of many of the techniques I had found useful through years of experimentation and application, packaged into a coherent whole. But SPEAR was more an umbrella concept, with different flavours of specific development approaches underneath – most notably Jerid.

In case you’re wondering, “Jerid” is a kind of javelin (throwing spear) used in games played on horseback in certain Muslim countries in the Middle East. It was also a somewhat convoluted acronym for “Java Enterprise Rapid Iterative Development”. Jerid later evolved into “Javelin”.

The Heart of Jerid

Jerid was founded primarily on ideas from risk management and rapid and evolutionary iterative development. By 1997 it had evolved to a point where, with hindsight, it looked circa 80% like Scrum was to look some years later. Two-week iterations (time boxed), sprints, sprint goals, sprint planning, retrospectives, etc.. I had independently invented “Agile” software development in Europe some years before the name itself was chosen at Snowbird, USA in 2001.

The core difference between Jerid and e.g. USA Agile/Scrum was Jerid’s emphasis on risk management. Jerid projects ensured that the major risks were identified and controlled. For me, this is the essence of any Agile approach – managing and controlling the major risks – both those common to all software development projects and those specific to each individual project.

We continued to apply and evolve Jerid during the late ’90s, at Familiar and its clients, until my departure from Familiar circa 2000.

Since then I have worked with a large number of different companies, large and small, helping them discover the fundamental principles underpinning iterative and agile approaches, and evolving practices and ways of working from those principles.

Acknowledgements

I’m very pleased to be able to acknowledge the contributions made to SPEAR and Jerid by many folks along the way. Although none of this would have happened without my input, their help and support was invaluable to me in evolving my understanding of software development, and later, the intersection of software development and general business.

Disclaimer

I’m pretty sure other folks also invented their own takes on the Agile theme before it became known by that name. Maybe even before I did. I’d be delighted to hear from anyone who believes they fall into that category.

Also please note that many of the strands of the thing that has become known as “Agile” existed long before I even got started in the field of software development methods. We all owe a debt to those many pioneers who were pushing the envelope and challenging accepted wisdom back as far as the 1960s and 1970s, if not before.

– Bob

Cognitive Function

How often do you get pissed off by interruptions and distractions? You know, when you’re zoned in on something, in a state of flow, and something happens to break the flow? Personally, when I’m writing code, I have to be in a quiet place, by myself or with my pair or mob, else I can’t get anything done for the continual distractions.

This is but one example of how easily cognitive function can be impaired.

Common sources of cognitive impairment:

  • Distractions and interruptions
  • Stress (specifically, negative stress a.k.a. distress) Cf Amygdala Hijack
  • Tiredness, fatigue, lack of sleep.
  • Multitasking
  • Poverty
  • Diet
  • Shift patterns
  • Noise and other forms of environmental stressors (lighting, odours, vibrations, exposure to particulates, elevated carbon dioxide, etc.)
  • Physiological issues (such as colds and flu, hypoglycemia, aphasia, depression, dehydration, hypertension, obesity, trauma, diabetes, Parkinson’s, POTS, dementia, hypoxia, atrial fibrillation)
  • Substance abuse (drink, drugs, etc. – short and long term effects, chronic and acute)

Wow. That’s quite a list. Seems like almost anything can impair cognitive function.

Why Does this Matter?

So why does cognitive function matter. What’s the connection with knowledge work? I’ll spell it out in case it’s not clear:

Knowledge work – such as software development – by definition involves working with our brains. If our brains are performing well (i.e. effective or relatively high cognitive functioning) then we can expect our work to go well, things to get done quicker, with fewer errors, and so on.

Conversely, when our cognitive function is impaired, our brains will take longer to accomplish tasks, come up with less effective solutions, commit more errors, and generally perform more ineffectively.

It’s also likely that with impaired cognitive function we’ll be less reflective, with less energy or capacity to spend on thinking about our work, our relationships, our behaviours, our practices, our customers, possible innovations, our needs and the needs of others, etc..

Does it sound to you like non-impaired cognitive function is something worth having? Something worth paying attention to?

Paying Attention?

So how many folks – managers, workers, organisations – pay any attention AT ALL to folks’ cognitive functioning in the workplace or whilst working? I’d suggest the answer is none, or as near none as makes no difference.

Which seems strange to me, if we truly seek our collaborative knowledge work (and workers) to be as effective as possible. Of course, that objective may be a false assumption. Maybe blissful ignorance and indifference is preferable to paying attention and taking action? Given the reluctance I’ve encountered when broaching this subject, I suspect blissful ignorance and/or indifference holds sway.

How does it go in your organisation?

– Bob

Cost of Focus

Or, more specifically, the cost of suboptimal focus – the cost of focusing on some (less relevant) needs of some Folks That Matter to the detriment or neglect of other (more relevant, valuable) needs of other Folks That Matter.

If we commit our (always limited) resources ineffectively, our returns (we might call this ROI) will likewise fall short of what would be possible if we committed our resources more effectively, or optimally.

How Do We Decide?

How we as a individual, team, group or organisation decide who we’re trying to please, delight, satisfy, or otherwise engage with and deliver to?  How do we get to know what folks need, and who to ask about the details of those needs? How do we choose whose needs we can successfully discount or defer when the inevitable resource (time, money, effort) crunches come? Who matters and who does not? Which needs are more relevant, valuable (with respect our chosen Goal) and which, less?

Might it be useful to have some heuristics, or policy, or other forms of guidance, to guide us in decisions on including, excluding and prioritising folks and their needs? Personally, if it were entirely up to me, I’d go with the general principle describe by Goldratt and summarised in my post “What is Value?“.

By way of a quick summary of that post:

Focus on those things that relax the customers’ constraint, so as to increase the overall throughput of their business (a.k.a. “Mafia Offers”). And focus on the customers, or market segments, that you understand best – or at least can work with to find such understanding.

Our aim: to optimise the Needsscape a.k.a. the needs we meet (for example, need for revenue, profit, cost reduction, etc. often sits at top of mind).

Relevance For Workers

This post is not just about decisions made by executives and managers. Everybody has the same dilemma: how do I/we decide where to focus? Which code module would it be better to deliver first? Which tests are more valuable that others? Who would it be better to work with first, to understand their needs (a.k.a. constraints, requirements, or whatever)? Where we choose to focus absolutely determines how others see us and our efforts.

Bottom Line

The bottom line is: the more effective we are at focussing on things that contribute to our personal or business goal (Cf. Goldratt), the more of our goal we’re likely to get. (Is that self-serving? Only if our goal is self-serving. Choose wisely).

– Bob

Further Reading

The Goal ~ Eliyahu M. Goldratt
It’s Not Luck ~ Eliyahu M. Goldratt
Focus ~ Think Different blog post
What is Value? ~ Think Different blog post

Team Building For High Performance

I’ve recently been writing a post on building high-performance teams (I’ve spent most of my career either building high performance teams myself, being part of a high performance team under construction, or helping others build high-performance teams). The post in question is rather getting away from me, in terms of length, and I might choose to convert it into a small book instead.

But I did want to post something on the topic, not least because during my research for the post I’ve come across so many instances of advice contrary to my own experience, advice which I believe if followed would undermine any such effort, and result in mediocre, under-performing teams, at best. Compared to what’s possible.

So, skipping over the definitions of “teams” and “high performance”, the rationale for teams, and the detailed ins and outs and how-to’s, in this post I’ll just cut to the nub of the challenge, as I see it: whole-part thinking.

Whole-Part Thinking

Most teams I’ve seen being built exist as a part of a larger whole (team, development organisation or silo, company).

That larger whole usually holds all the aces when it comes to stipulating what is and is not permissible. Hiring practices; compensation practices; incentives and motivational practices; working practices; internal and external communications practices; management structures, doctrines and practices; ways in which folks can relate to each other a.k.a. social norms; influence over the workplace, tools and equipment; remote vs on-premise working; working hours and locations; and so on. All these and more are generally under the control of the wider organisation (sometimes explicitly, more often, implicitly).

So, the constraints on our team building efforts are legion. And these constraints are generally antithetical to our achieving high performance. For successful builders of high performance teams, the biggest challenge they have overcome is the challenge of circumventing these constraints, without alienating the larger whole (and the powers that be) to the extent that they lose their credibility and influence. And sustaining their circumventions, credibility and influence, over the long haul.

I’ve written at greater length about these challenges in my 2012 posts “OrgCogDiss” and “French Letters” (the latter specifically about Agile teams, but equally relevant for all kinds of high-performance team).

In a nutshell, then: whole-part thinking leads organisations to believe that a development team or silo is a more or less independent entity, masters of their own performance, and can be held accountable as such. In reality, the constraints of being a part of the larger whole impact teams to such an extent that they have little to no independent control over their own performance.

Enable High Performance For the Whole

Organisations that truly value performance over rules change the rules (constraints) to enable high performance across the whole organisation. Many prefer to stick with their existing assumptions, beliefs and rules.

– Bob

Further Reading

Why Agile is No More (or Less) Than a Skunkworks ~ Think Different blog post
Innovation ALWAYS Demands We Change the Rules ~ Think Different blog post
I Want You To Cheat ~ John Seddon

The Needsscape

-scape

suffix forming nouns

  1. Indicating a scene or view of something, esp. a pictorial representation: seascape, cityscape, soundscape.

Word Origin: Abstracted from “landscape”.

The Essence of Business

Business is, in essence, about attending to folks’ needs. Here’s a quick list of typical needs, to illustrate:

  • The financial needs of the owners and shareholders, and of staff.
  • The particular needs of customers, which the business’s products and services attempt to address.
  • The needs of suppliers for revenues.
  • The needs of wider society for commerce, prosperity, growth of social cohesion and living standards, wealth distribution, and so on.
  • The emotional needs of owners, shareholders, executives, managers and staff (examples: status, self-worth, compassion for others, making a difference, safety, love, esteem, curiosity, joy, learning, accomplishment, contributing to society, etc.).

I use the term “needsscape” to refer to the ever-changing set of Folks That Matter, and their ever-changing sets of needs. (Not all the needs listed above might feature in a given business’s needsscape).

In particular, the term Needsscape, for me, evokes the idea of one or more visualisations of the ever-changing set of Folks That Matter, and their ever-changing sets of needs, including the evolution of those sets over time. And especially visualisations of the current and relevant future set of Folks That Matter, their various sets of current and relevant future needs, and where the business is “at” in terms of attending to those folks and their needs. In other words, making all work (and objectives) visible, including attributes such as progress, status, and other interesting aspects of the work (aspects made interesting due, themselves, to the pertinent set of Folks that Matter, and their needs).

Indeed, all value-adding work is attending to (some) folks’ needs. And all wasted work is work where folks’ needs are undermined.

What value would a real-time (or near real-time) visualisation of the needsscape bring to your group and/or business?

– Bob

Further Reading

English Words Suffixed with -scape ~ Wiktionary entry

Solutions Demand Problems

I’m obliged to Ben Simo (@QualityFrog) for a couple of recent tweets that prompted me to write this post:

I very much concur that solutions disconnected from problems have little value or utility. It’s probably overdue to remind myself of the business problems which spurred me to create the various solutions I regularly blog about.

FlowChain

Problem

Continually managing projects (portfolios of projects, really) is a pain in the ass and a costly overhead (it doesn’t contribute to the work getting done, it causes continual scheduling and bottlenecking issues around key specialists, detracts from autonomy and shared purpose, and – from a flow-of-value-to-the-customer perspective – chops up the flow into mini-silos (not good for smooth flow). Typically, projects also leave little or no time, or infrastructure, for continually improving the way the work works. And the project approach is a bit like a lead overcoat, constraining management’s options, and making it difficult to make nimble re-adjustments to priorities on-the-fly.

Solution (in a Nutshell)

FlowChain proposes a single organisational backlog, to order all proposed new features and products, along with all proposed improvement actions (improvement to the way the work works). Guided by policies set by e.g. management, people in the pool of development specialists coalesce – in small groups, and in chunks of time of just a few days – around each suitable highest-priority work item to see it through to “done”.

Prod•gnosis

Problem

Speed to market for new products is held back and undermined by the conventional piecemeal, cross-silo approach to new product development. With multiple hands-offs, inter-silo queues, rework loops, and resource contentions, the conventional approach creates excessive delays (cf cost of delay), drives up the cost-of-quality (due to the propensity for errors), and the need for continual management  interventions (constant firefighting).

Solution (in a Nutshell)

Prod•gnosisproposes a holistic approach to New Product Development, seeing each product line or product family as an operational value stream (OVS), and the ongoing challenge as being the bringing of new operational value streams into existence. The Prod•gnosis approach stipulates an OVS-creating centre of excellence: a group of people with all the skills necessary to quickly and reliably creating new OVSs. Each new OVS, once created, is handed over to a dedicated OVS manager and team to run it under day-to-day BAU (Business as Usual).

Flow•gnosis

Problem

FlowChain was originally conceived as a solution for Analytic-minded organisations. In other words, an organisation with conventional functional silos, management, hierarchy, etc. In Synergistic-minded organisations, some adjustments can make FlowChain much more effective and better suited to that different kind of organisation.

Solution (in a Nutshell)

Flow•gnosis merges Prod•gnosis and FlowChain together, giving an organisation-wide, holistic solution which improves organisational effectiveness, reifies Continuous Improvement, speeds flowof new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

Rightshifting

Problem

Few organisations have a conscious idea of how relatively effective they are, and of the scope for them to become much more effective (and thus profitable, successful, etc.). Absent this awareness, there’s precious little incentive to lift one’s head up from the daily grind to imagine what could be.

Solution (in a Nutshell)

Rightshifting provides organisations with a context within which to consider their relative effectiveness, both with respect to other similar organisations, and more significantly, with respect to the organisation’s potential future self.

The Marshall Model

Problem

Few organisations have an explicit model for organisational effectiveness. Absence of such a model makes it difficult to have conversations around what actions the organisation needs to take to become more effective. And for change agents such as Consultants and Enterprise Coaches attempting to assist an organisation towards increased effectiveness, it can be difficult to choose the most effective kinds of interventions (these being contingent upon where the organisation is “at”, with regard to its set of collective assumptions and beliefs a.k.a. mindset).

Solution (in a Nutshell)

The Marshall Model provides an explanation of organisational effectiveness. The model provides a starting point for folks inside an organisation to begin discussing their own perspectives on what effectiveness means, what makes their own particular organisation effective, and what actions might be necessary to make the organisation more effective. Simultaneously, the Marshall Model (a.k.a. Dreyfus for Organisations) provides a framework for change agents to help select the kinds of interventions most likely to be successful.

Organisational Psychotherapy

Problem

Some organisations embrace the idea that the collective organisational mindset – what people, collectively believe about how organisations should work – is the prime determinant of organisational effectiveness, productivity, quality of life at work, profitability, and success. If so, how to “shift” the organisation’s mindset, its collective beliefs, assumptions and tropes, to a more healthy and effective place? Most organisations do not naturally have this skill set or capability. And it can take much time, and many costly missteps along the way, to acquire such a capability.

Solution (in a Nutshell)

Organisational Psychotherapy provides a means to accelerate the acquisition of the necessary skills and capabilities for an organisation to become competent in continually revising its collective set of assumptions and beliefs. Organisational Psychotherapists provide guidance and support to organisations in all stages of this journey.

Emotioneering

Problem

Research (cf Buy•ology ~ Martin Lindstrom) has shown conclusively that people buy things not on rational lines, but on emotional lines. Rationality, if it has a look-in at all, is reserved for post-hoc justification of buying decisions. However, most product development today is driven by rationality:

  • What are the customers’ pain points?
  • What are the user stories or customer journeys we need to address?
  • What features should we provide to ameliorate those pain points and meet those user needs?

Upshot: mediocre products which fail to appeal to the buyers’ emotions, excepting by accident. And thus less customer appeal, and so lower margins, lower demand, lower market share, and slower growth.

Solution (in a Nutshell)

Emotioneering proposes replacing the conventional requirements engineering process (whether that be big-design-up-front or incremental/iterative design) – focusing as it does on product features – with an *engineering* process focusing on ensuring our products creaate the emotional responses we wish to evoke in our customers and markets (and more broadly, in all the Folks That Matter).

The Antimatter Principle

Problem

How to create an environment where the relationships between people can thrive and flourish? An environment where engagement and morale is consistently through the roof? Where joy, passion and discretionary effort are palpable, ever-present and to-the-max?

Solution (in a Nutshell)

The Antimatter Principle proposes that putting the principle of “attending to folks’ needs” at front and centre of all of the organisation’s policies is by far the best way to create an environment where the relationships between people can thrive and flourish. Note: this includes policies governing the engineering disciplines of the organisation, i.e. attending to customers’ needs at least as much as to the needs of all the other Folks That Matter.

– Bob

Some Alien Tropes

Most people, and hence organisations, fear the alien, And by doing so, cleave to the conventional. Yet progress, change, and organisational effectiveness depend on embracing the alien.

“Problems cannot be solved with the same mindset that created them.”

~ Albert Einstein

To help folks understand what I mean by the phrase “alien tropes” here’s a short list of tropes from the Synergistic mindset. Very alien to all the Analytic-minded organisations out there.

  • Treat people like adults. In all things.
  • Allow people to choose their own terms, conditions, locations, salaries, equipment and ways of working together.
  • Understand who matters and what each of these individuals need.
  • Attend to all the needs of all the folks that matter.
  • Be aware of both the prevailing and the desired social dynamic in the organisation.
  • Think in terms of communities and teams, not individuals. Ensure all the policies of the organisation support this perspective.
  • Actively support and encourage self-organisation, self-management and self- determination (e.g. of teams).
  • People really do want to contribute, learn, make a difference and do the best they can.
  • Effective collaborative knowledge work is a learnable set of competencies.
  • Skilful dialogue is essential for effective teamwork and, as a skill, requires constant practice and development.
  • Intrinsic motivations add, extrinsic motivations subtract.
  • Productivity in collaborative knowledge work demands superior cognitive function.
  • Stress causes a decline in cognitive function.
  • Stress has many causes (fear, obligation, guilt, shame, lack of safety, …).
  • Eschew leadership in favour of e.g. fellowship.
  • Common (shared) purpose has a unique power.
  • Enthusiastically model and support discussion, debate, open-mindedness and the ability to change oneself and one’s assumptions, beliefs.
  • Alien tropes do not come naturally to people. Support their uptake.
  • Do not fear the alien; embrace it, use it, exploit it.

I’d be delighted to expand on any of the above, if and when invited to do so.

– Bob