Archive

Engineering

A Hiding To Nothing

June 2, 2018
Agile, Antimatter principle, Culture change, Dialogue, Engineering, Leadership, Management, Organisational effectiveness, Product development, Rightshifting, Software development
3 Comments

A Hiding To Nothing

Most large companies are on a hiding to nothing if and when they decide they’re “going Agile” for software development. “Going Agile” can only ever deliver the outcomes these companies seek if the whole organisation is prepared to change some of its fundamental beliefs about how organisations should be run.

Sought Outcomes

What outcomes do larger compares typically seek from “going Agile” in their software development teams? Here’s a partial list:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement
  • Shorter timescales (i.e. “from concept to cash”)

Why These Outcomes Are Unrealisable

What’s not to like in the outcomes these companies seek by “going Agile”? Although maybe not comprehensive – they lack, for example, outcomes like “joy in work”, “folks getting their needs met”, “improved flow” and “customer delight” – there’s a bunch of stuff here I could get behind.

Setting aside the observation that some of the above “outcomes” – such as “common standards” and “people working in sync” – are more solutions than needs, “going Agile”, per se, is not the answer for delivering these outcomes. At least, not within the Analytic mindset world view.

Why the Analytic Mindset is the Blocker

With an implicit Theory-X, local optima (manage the parts separately) perspective, any and all solutions attempting to deiver these outcomes through “going Agile” are doomed to undermine the very outcomes sought.

It’s likely to start well, with much interest and hope expressed by the staff. After all, who wouldn’t want more autonomy, more mastery, more purpose in their work? But as things progress, existing company policies, rules, attitudes, etc. will begin to assert themselves. To the detriment of staff morale, motivation and engagement. Pretty soon, staff will begin to question the sincerity of the management in their support for “going Agile”. Pretty soon, it will start to become apparent to anyone who’s paying attention that existing policies, rules, etc., have to change fundamentally to see the outcomes sought begin to happen.

And with declining staff engagement in “going Agile”, and reducing enthusiasm for understanding the principles necessary for making Agile successful, progress will slow to a crawl. At this point, middle-management, who have to carry the burden of making “going Agile” happen will also begin, quietly, to question the wisdom of the senior management direction. This will lead to their more often reverting to orthodox, “tried and tested” (and less personally burdensome) ways of working. And more often baulking at the effort needed to push through adoption of more Agile practices.

What To Do?

So, what’s a company to do? Most companies will not realise, or want to hear, that the Analytic mindset is fundamentally incompatible with successfully “going Agile”. So, another Agile adoption failure is in the making.

Personally, having helped various companies face up to this challenge, I’d say:

“It’s extremely unlikely that you’ll want – or even be able – to give up your existing world view. At least in the short term. So something’s got to give. And it’s probably better that you give up on “going Agile”. But DON’T give up on wanting things to be better. Park your Agile aspirations, and try another path, another solution. After all, it’s the OUTCOMES you seek that matter, not some specific – and cargo-culted – solution.”

So what might that alternative solution look like? What can an unrepentantly Analytic-minded organisation do to improve its software development outcomes?

My recommendation would be to focus on the interpersonal relationships within and between departments. Help developers understand and relate to customers (both internal and external) better. Help other folks within the organisation better understand and relate to developers.

Leveraging these improving relationships, encourage multi-party, cross-function dialogue about the outcomes sought, and what folks of every stripe can do, every day, to begin to shift the organisation’s rules, policies, structures and assumptions.

In a nutshell, be less autocratic, directive and strategic, and more democratic, collegiate and opportunistic.

And remember, I’m here to help.

– Bob

The Future of Coding Environments

May 29, 2018
Coding, Engineering, Software development
1 Comment

The Future of Coding Environments

How would Scotty or Geordie go about writing code for the Starship Enterprise? Would they write code at all? Would they just interact with the Computer via speech or holodeck, or would a keyboard of some sort still have a place? 

In any case, my interests have always stretched beyond matters of organisational effectiveness, beyond matters of human and humane relationships, and beyond matters of how the work of software and product development might better work.

One of my other abiding interests has been the nature of programming. Indeed I spent more than two years, decades ago, on conceiving, designing and implementing a proof of concept for the kind of development environment I’d like to use myself, when writing code. At the time, the work was codenamed “Simplicity”.

My core feature set / wish list includes: 

  • Editing source code directly in the AST, rather than editing source code in text files
  • Direct and incremental compilation of source code as it’s being entered
  • Multiple coders editing in the same AST concurrently
  • Live editing of the AST “in production” (with appropriate safeguards built-in)
  • One homogenous AST for each entire (live production) system
  • Source code control / version control features built right in (and automated away from distracting the coders)

OK, so this may not be the kind of development environment Scotty or Geordie would recognise. But it’s a world away from all the crap we have to put up with today.

Blockers

So why don’t we see more movement towards the emergence of some of these features in our development environments today? In a word: conservatism. Developers en masse seem disinclined – or unable – to look anew at their tools, and dream.

“The future is a foreign country; they do things differently there.”

– Bob

Further Reading

The Mjølner Environment ~ Görel Hedin, Boris Magnusson

 

Testbash Dublin and Organisational Psychotherapy

May 21, 2018
Culture change, Engineering, Fellowship, Management, Nonviolent Communication, NoTesting, Organisational effectiveness, Organisational Therapy, Product development, Software development, Teambuilding, Therapy
Leave a comment

Testbash Dublin and Organisational Psychotherapy

As I mentioned in my previous post, I’m just back from presenting an interactive session on Organisational Psychotherapy at Testbash Dublin. Some folks seemed confused as to the relevance of Organisational Psychotherapy to testers and the world of testing, so I’m happy to explain the connection as I see it. (And please note that many of my previous posts on Organisational Psychotherapy may also help to illuminate this connection.)

I’ll start by riffing on something Rob Meaney said during his presentation:

“Significant quality improvements [aren’t] driven by testing. They [are] driven by building relationships and influencing the right people at the right time.” ~ @RobMeaney #TestBash

Quality (and other) improvements come from improved relationships. This has been a theme on this blog for some years now. For example see: The Power of Humane Relationships.

I asked a key (for me) question during my session (several times):

“If we accept that (as per the Marshall Model) it’s the collective mindset of the organisation that determines its relative effectiveness, how do we propose to support the organisation if and when it choses to do something about its mindset?”

Unsurprisingly perhaps, I heard no answers, excepting my own proposal for a means to that end: Organisational Psychotherapy.

I wonder how many folks involved with testing ask themselves and their peers the question “How can our organisation become more effective at testing?”. Or, using the #NoTesting frame, “How can our organisation become more effective at delivering quality products and services?”

Fellowship

Organisational Psychotherapy is not just about improving product quality, however. Through improved relationships, and a shift in how the organisation relates to its people (i.e. from Theory-X to Theory-Y), the quality of life at work also improves. Put another way, we all have more fun, more job satisfaction, and get to realise more of our potential at work. Further, for all the folks that matter, their several needs get better met. And, as a bonus for the organisation itself, it gets to see its people more productive and engaged. What’s not to like?

Incidentally

I’ve also written elsewhere about using the Antimatter Principle in practical ways during software development. For example, during development we eschew requirements gathering in favour of incrementally elaborating hypotheses about the needs of all the folks that matter, and then conducting experiments to explore those needs. I can envisage teams that still need testers adopting a needs-focused approach to driving testing. For example, putting into place various means by which to answer the question “how well does our product meet the needs of the people that matter to us?”.

Practical Applications

On a related note, some folks asked me about practical applications of Organisational Psychotherapy in their day-to-day work as testers. Here’s just a few applications which immediately come to mind:

  • Improving communication with the people that matter (i.e. developers, fellow testers, management, stakeholders, customers, etc.). I find NVC (nonviolent communication) skills and practice particularly useful in this context.
  • Clarifying what works and thus what to do more of (Cf Solutions Focus). This can improve team retrospectives.
  • Helping the people that matter (including ourselves) feel better about what we’re doing (Cf. Positive Psychology).
  • Understanding each other’s strengths, with a view to having the right people in the right seats on the bus (Cf. StrengthsFinder).
  • Eliciting requirements (if you still do that) (Cf Clean Language).
  • Building a community (such as a Testing CoP or a multi-skilled self-organising product team) (Cf Satir Family Therapy).
  • Improved cooperation with higher-ups (empathy, Transactional Analysis, etc.).
  • Dealing with blockers to changing/improving the way the work works.

Invitation

I’d love to hear if this post has helped put my recent Testbash session in context.

– Bob

World Class? Really?

May 2, 2018
Engineering, General, Leadership, Management, Marshall Model, Organisational effectiveness, Product development, Rightshifting, Software development
1 Comment

World Class? Really?

Some six years ago now, I wrote a post describing what might characterise a world class software / product development / collaborative knowledge work business.

In the interim, I’ve had some opportunities to work on these ideas for various clients. My consequent experiences, whilst in no way invalidating that post, have thrown up different perspectives on the question of “world class”.

Firstly, do you want it? Moving towards becoming a world class business involves a shed load of work, over many years. Do you want to commit to that effort? Even though the goal sounds noble, ambitious, attractive, does your business have what it takes to even begin the journey in earnest, let alone stick at it.

Then, do you need it? Absent powerful drivers spurring you on towards the goal, will you have the grit necessary to keep at it? Or will the initiative flounder and drown in the minutiae of daily exigencies, such as the constant pressure to get product and features out the door, to keep investors satisfied with (short term) results, etc.? And is the ROI there, in your context? If you do keep on the sometimes joyful, oftentimes wearisome path, and attain “world class” status, will the effort pay back in terms of e.g. the bottom line?

If your answers to the preceding two questions are yes, then we can get down to considering the characteristics of a world class collaborative knowledge-work business.

What might it look like, that goal state? Here’s my current take:

Context

Just in case a little context might help, here’s a variant of the Rightshifting chart which illustrates world class in terms of relative effectiveness (i.e. how effective are world class organisations relative to their peers?) The yellow area highlights those organisations (those at least circa 2.5 times more effective than the median) we might consider world class:

Fields of Competency

Any world class collaborative knowledge-work business must have mastered a bunch of different fields of knowledge. That’s not to say everyone in the organisation needs to have reached mastery (Level 5 – see below) in every one of the follow fields. But there must be a widespread acquaintance with all these fields, and some level of individual competent in each.

I suggest the following Dreyfus-inspired model for characterising an individual’s (practitioner’s) level of competency (or action-oriented knowledge) in any given field:

Level One (Novice)

The Novice level in each Field invites practitioners to acquire the basic vocabulary and core concepts of the Field. Attainment criteria will specify the expected vocabulary and core concepts. The Novice level also invites practitioners to acquire and demonstrate the ability to read and understand materials (books, articles, papers, videos, podcasts, etc.) related to the vocabulary and core concepts of the Field.

Level Two (Advanced Beginner)

The Advanced Beginner level in each Field invites practitioners to acquire the ability to critique key artefacts commonly found in the given Field. The Advanced Beginner level also invites practitioners to read more widely, and understand different perspectives or more nuanced aspects of, and peripheral or advanced elements within the Field.

Level Three (Competent)

The Competent level in each Field invites practitioners to acquire and demonstrate a practical competency in the core concepts in the Field, for example through the ability to apply the concepts, or create key artefacts, unaided.
The Competent level also invites practitioners to acquire and demonstrate the ability to collaborate with others in exploring and applying the abilities acquired in the Novice and Advanced Beginner levels.

Level Four (Proficient)

The Proficient level in each Field invites practitioners to acquire and demonstrate the ability to prepare and present examples and other educational materials appropriate to the given Field. The Proficient level also invites practitioners to acquire and demonstrate the ability to coach or otherwise guide others in applying the abilities acquired in the Novice, Advanced Beginner and Competent levels.

Level Five (Master)

The Master level in each Field invites practitioners to acquire and demonstrate national or international thought leadership in the Field. This can include: making significant public contributions or extensions to the Field; becoming a publicly recognised expert in the Field; publishing books, papers and/or articles relevant to the Field; etc.

The Fields

Any business that aspires to world class status must attain effective competencies in a wide range of different fields. The following list suggests the fields I have found most relevant to collaborative knowledge-work business in general, and software / product tech businesses in particular:

Flow

  • Flow (product development) (n): the movement of the designs, etc., for a product or service through the steps of the design processes which create them.
  • Continuous Flow (n): The progressive movement of units of design through value-adding steps within a design process such that a product design or service design proceeds from conception into production without stoppages, delays, or back flows.
  • See also: Optimised Flow Demonstration (video)

Deming

  • * Many in Japan credit Bill Deming for what has become known as the Japanese post-war economic miracle of 1950 to 1960.
  • William Edwards Deming (October 14, 1900 – December 20, 1993) was an American engineer, statistician, professor, author, lecturer, and management consultant. Deming is best known for his work in Japan after WWII, particularly his work with the leaders of Japanese industry.

Risk Management

  • Risk management is the discipline and practice of explicitly identifying and managing key risks.

    “Risk Management is Project Management for grown-ups.”
    ~ DeMarco & Lister

  • Potential benefits include:
    • makes aggressive risk-taking possible
    • protects us from getting blindsided
    • provides minimum-cost downside protection
    • reveals invisible transfers of responsibility
    • isolates the failure of a subproject
  • Note; Many Agile practices are, at their heart, about risk management.

Mindset

  • Mindset a.k.a. collective (organisational) memeplex (n): A set of memes (ideas, assumptions, beliefs, heuristics, etc.) which interact to reinforce each other.

“A memeplex is a set of memes which, while not necessarily being good survivors on their own, are good survivors in the presence of other members of the memeplex.”
~ Richard Dawkins in The God Delusion

  • The “organisational mindset” is a set of beliefs about the world and the world of work which act to reinforce each other.
  • These interlocking beliefs tightly bind organisations into a straight-jacket of thought patterns which many find inescapable. Without coordinated interventions at multiple points in the memeplex simultaneously, these interactions will prevail, as will the status quo.

Requirements a.k.a. Needs Management

  • A more or less formal approach to identifying and communicating needs
  • Any approach that ensures that everyone involved in attending to the identified needs shares a clear understanding of the required outcome(s): “doing the RIGHT thing”.

Fellowship

  • A system of organisational governance based on the precepts of Situational Leadership and with a primary focus on the quality of interpersonal relationships as a means to improved organisational health and effectiveness.
  • More generally, paying attend to the quality and effectiveness of the collaborative relationships across and through the business (and the extended value network of which it is a part).

Cognitive Function

  • Cognitive function (Neurology) (n): Any mental process that involves symbolic operations–e.g. perception, memory, creation of imagery, and thinking; Cognitive Function encompasses awareness and capacity for judgment.
  • Effectiveness of collaborative knowledge work is dictated by both e.g. quality of interpersonal relationships and degree of Cognitive Function.
  • See also: Cognitive Science

PDCA

  • PDCA (plan–do–check–act, or plan–do–check–adjust) is an iterative four-step method used for the control and continuous improvement of processes and products. It is also known as the Deming circle/cycle/wheel, Shewhart cycle, control circle/cycle, or plan–do–study–act (PDSA).
  • Based on the scientific method, (Cf. Francis Bacon) e.g. “hypothesis” – “experiment” – “evaluation”.

Statistical Process Control (SPC)

  • Statistical process control (SPC) is a method of quality control which uses statistical methods. SPC is applied in order to monitor and control a process.
  • Key tools used in SPC include control charts; a focus on continuous improvement; and the design of experiments.
  • See also: The Red Beads and the Red Bead Experiment with Dr. W. Edwards Deming (video)

Lean Product Development

  • Lean Product Development applies ideas from Lean Manufacturing to the design and development of new products (See e.g. books by Allen Ward and Michael Kennedy)
  • Aims to improve the flow of new ideas “from concept to cash”.
  • Can also help raise levels of innovation.
  • Exemplar: TPDS (Toyota Product Development System)

Don Reinertsen’s Work

  • Don Reinertsen is the author of three of the most definitive and best-selling books on product development.
  • His 1991 book, Developing Products in Half the Time is a product development classic.
  • His 1997 book, Managing the Design Factory: A Product Developer’s Toolkit, was the first book to describe how the principles of Just-in-Time manufacturing could be applied to product development. In the past 16 years this approach has become known as Lean Product Development.
  • His latest award-winning book, The Principles of Product Development Flow: Second Generation Lean Product Development, has been praised as, “… quite simply the most advanced product development book you can buy.”

Neuroscience

  • (Cognitive) neuroscience is concerned with the scientific study of the biological processes and aspects that underlie cognition, with a specific focus on the neural connections in the brain which are involved in mental processes.
  • (Cognitive) neuroscience addresses the questions of how psychological/cognitive activities are affected or controlled by neural circuits in the brain. Cognitive neuroscience is a branch of both psychology and neuroscience, overlapping with disciplines such as physiological psychology, cognitive psychology, and neuropsychology.
  • See also: Cognitive Function

Theory of Constraints

  • The Theory of Constraints (TOC) is a management paradigm originated by Eliyahu M. Goldratt.
  • TOC proposes a scientific approach to improvement. It hypothesises that every complex system, including manufacturing processes, consists of multiple linked activities, just one of which acts as a constraint upon the entire system (the “weakest link in the chain”).
  • TOC has a wide range of “thinking tools” which together form a coherent problem-solving and change management system.

Self-organisation

  • Self-organisation (n): Ability of a system to spontaneously arrange its components or elements in a purposeful (non-random) manner. It is as if the system knows how to ‘do its own thing.’ Many natural systems such as cells, chemical compounds, galaxies, organisms and planets show this property. Animal and human communities too display self-organization.

    “An empowered organization is one in which individuals have the knowledge, skill, desire, and opportunity to personally succeed in a way that leads to collective organisational success.”
    ~ Stephen R. Covey

Quantification

  • In mathematics and empirical science, quantification is the act of counting and measuring that maps human sense observations and experiences into members of some set of numbers. Quantification in this sense is fundamental to the scientific method.
  • See also: Tom Gilb

Systems Thinking

  • Systems thinking provides a model of decision-making that helps organisations effectively deal with change and adapt.
  • It is a component of a learning organisation – one that facilitates learning throughout the organisation to transform itself and adapt.
  • See also: Peter Senge, Russell L. Ackoff, Donella Meadows, etc.

Psychology

  • Psychology (n): the study of behaviour and mind, embracing all aspects of conscious and unconscious experience as well as thought. It is an academic discipline and an applied science which seeks to understand individuals and groups.

Argyris

  • An American business theorist, Professor Emeritus at Harvard Business School, and known for his work on interpersonal communication, organisational effectiveness, double-loop learning and learning organisations.
  • See also: Action Science.

Psychotherapy

  • Psychotherapy (n): interventions which facilitate the shifting of perspectives and attitudes, and thus, human behaviours.
  • See also: Organisational Psychotherapy

To the above list of Fields, I invite you to add any which may have specific resonance or relevance to your own business.

And then there are the lists of technical capabilities you need to be present in your various business functions, too.

Aside – CMMI

As an aside, CMMI also provides an extensive list of “capability areas” ( circa 128 different areas, last time I looked) focussed on engineering capabilities. Note: I find the CMMI list useful, but only as a primer, not as a full-blown recipe for success.

Summary

All the above begs the question: how to get there? And, how close are you to world class, so far?

– Bob

Means and Ends

April 26, 2018
Antimatter principle, Emotioneering, Engineering, Management, Organisational effectiveness, Product development, Software development
2 Comments

Means and Ends

How often do we try to “improve” our product and services, and the revenue and profit therefrom (i.e. the ends), and how often do we try to improve the way the work works, the way we develop those products and services (i.e. the means)?

Folks have needs related to the way the work works, in many ways just as profound as the needs they have of the products and services (features, revenues, wages, …) resulting from that work.

To illustrate what I’m talking about, here’s a short list of some of the needs folks can have related to the way the (product development) work works:

  • Ongoing information (development schedules, quality levels, costs, plans, etc.)
  • Confidence (e.g. that milestones and Due Dates will be hit)
  • Growth
  • Learning
  • A sense of purpose (are we spending our time on stuff that matters?)
  • Integrity
  • Connection (e.g. human connections, relationships between people)
  • Appreciation
  • Harmony
  • Achievement
  • Etc. (and lots more possibilities in e.g. this Needs Inventory)

This post is an invitation to apply the same considerations to the explicit and intentional design of the way the work works, as we do to the way our products or services under development work.

In my previous post, “Antimatter Evo”, I explored the twelve principles associated with the Agile Manifesto, and proposed a way to radically simplify those twelve principle down to, essentially, one (“Attend to folks’ needs”).

May I invite you to consider the impact on your development efforts of applying the same principle – the Antimatter Principle?

Does your current approach – to defining and improving the way the work works – attend to the needs of the people that matter?

Blind Spot

In the typical product development situation, each new product (or service) that enters development is handled much like all those which have gone before. Outwith major revisions to the way the work works (say, adopting a revolutionary new approach such as Agile), incremental improvements to the means of development can occur, and occasionally do. Yet with both Kaikaku (revolutionary change) and Kaizen (incremental change), change is rarely connected to better serving the needs of the “folks that matter”. Put another way, change most often serves the product and its users, and rarely the folks impacted by the way the work works.

How blind is your organisation, presently, to the ability of its development efforts to meet the relevant needs of the people involved in those efforts?

What if we applied ourselves to understanding the needs of the people that matter, as they pertain to the way the work works? What effect might that have on the social dynamic, the relationships between different people and groups, on productivity, and on the general success of our development efforts?

– Bob

Antimatter Evo

April 24, 2018
Agile, Antimatter principle, Engineering, Listening, Management, Organisational effectiveness, Product development, Software development
2 Comments

Antimatter Evo

Tom Gilb has long been known for his “Evo”(evolutionary) approach to software engineering, and more recently for his sharp criticisms of the Agile Manifesto (99% of which I agree with).

In a recent (February 2018) PPI Systems Engineering Newsletter, he authors the feature article “How Well Does the Agile Manifesto Align with Principles that Lead to Success in Product Development?”, describing in some depth his issues with the Agile Manifesto, its Four Values and Twelve Principles.

Apropos the latter, Tom comments at length on each, providing for each a “reformulation”. I repeat each of these twelve reformulations here, along with a translation to the vocabulary (and frame) of the Antimatter Principle:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Tom’s reformulation: Development efforts should attempt to deliver, measurably and cost-effectively, a well-defined set of prioritized stakeholder value-levels, as early as possible.

Antimatter translation: As early and frequently as possible, in the course of developing e.g. a new product or service, we (the development team) will identify, quantify, and subsequently measure, a well-defined set of the needs of all the people that matter, and deliver, as early and frequently as possible, stuff that we believe meets those needs.

Antimatter simplification: Our highest priority is to continually attend to the needs of everyone that matters.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Tom’s reformulation: Development processes must be able to discover and incorporate changes in stakeholder requirements, as soon as possible, and to understand their priority, their consequences to other stakeholders, to system architecture plans, to project plans, and contracts.

Antimatter translation: Our approach to developing new products or services enables the development team to discover and incorporate changes in the needs of anyone that matters, and the members of the community of “everyone that matters”, as soon as possible. The development team has means to quantify, share and compare priorities, and means to both understand and communicate the impact of such changes to the community of “everyone that matters”.

Antimatter simplification: Handle changing needs, and changing membership of the “everyone that matters” community, in ways that meet the needs of the people that matter.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Tom’s reformulation: Plan to deliver some measurable degree of improvement, to planned and prioritized stakeholder value requirements, as soon, and as frequently, as resources permit.

Antimatter translation: Plan to deliver some measurable degree of improvement to the planned and prioritised set of needs (of the people that matter) as soon, and as frequently, as needed.

Antimatter simplification: Deliver stuff as often as, and by means that, meets the needs of everyone that matters.

4. Business people and developers must work together daily throughout the project

Tom’s reformulation: All parties to a development effort (stakeholders), need to have a relevant voice for their interests (requirements), and an insight into the parts of the effort that they will potentially impact, or which can impact them, on a continuous basis, including into operations and decommissioning of a system.

Antimatter translation: Have established means through which we continually solicits the needs of the people that matter, means that are well-defined and well-understood by everyone that matters. These means provide: an ear for the feelings and needs of the people that matter, and feedback on the consequences (impact) of attending to those needs.

Antimatter simplification: Share needs and solutions as often as, and by means that, meets the needs of everyone that matters.

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

Tom’s reformulation: Motivate stakeholders and developers, by agreeing on their high-level priority objectives, and give them freedom to find the most cost-effective solutions.

Antimatter translation: Motivate everyone that matters by agreeing on everyone’s needs, and give everyone, as a group, the freedom to collaborate in negotiating the trade-offs, priorities, and most cost-effective solutions.

Antimatter simplification: Motivate people to the degree that, and by means that, meets the needs of everyone that matters.

6. Enable face-to-face interactions.

Tom’s reformulation: Enable clear communication, in writing, in a common project database. Enable collection and prioritization, and continuous updates, of all considerations about requirements, designs, economics, constraints, risks, issues, dependencies, and prioritization.

Antimatter translation: Provide communications that meet the needs of everyone that matters. Manage these needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Facilitate sharing of information, feelings, needs, etc. to the degree that, and by means that, meets the needs of everyone that matters.

7. Working software is the primary measure of progress.

Tom’s reformulation: The primary measure of development progress is the ‘degree of actual stakeholder-delivered planned value levels’ with respect to planned resources, such as budgets and deadlines.

Antimatter translation: The primary measure of development progress is the ‘degree of actual needs met’ with respect to the planned, prioritised and quantified set of needs of everyone the matters. Note: Assuming end-users or customers are amongst the set of people that matter, this demands the product or service in question is in active service with those people, such that we can measure how well (the degree to which) their needs are actually being met. And don’t forget the needs pertaining to how the endeavour is being conducted!

Antimatter simplification: Choose a primary measure of progress that meets the needs of everyone that matters.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Tom’s reformulation: We believe that a wide variety of strategies, adapted to current local cultures, can be used to maintain a reasonable workload for developers, and other stakeholders; so that stress and pressures, which result in failed systems, need not occur.

Antimatter translation: Proceed at a pace that meets the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Choose a pace that meets the needs of everyone that matters.

9. Continuous attention to technical excellence and good design enhances agility.

Tom’s reformulation: Technical excellence in products, services, systems and organizations, can and should be quantified, for any serious discussion or application. The suggested strategies or architectures, for reaching these ‘quantified excellence requirements’, should be estimated, using Value Decision Tables [45, 1, 2], and then measured in early small incremental delivery steps.

Antimatter translation: Aim for a level of technical excellence and good design – and any other quality-related attributes – that meet the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Agree on attributes of quality, and levels of quality, with respect to the means of the endeavour, that meets the needs of everyone that matters.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

Tom’s reformulation: We need to learn and apply methods, of which there are many available, to help us understand complex systems and complex relations. [1, 2, 46, 47, 48, 49] and succeed in meeting our goals in spite of them.

Antimatter translation: Aim for a level of simplicity – and any other quality-related attributes -that meet the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Spend effort only where it directly attends to some need of someone that matters.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Tom’s reformulation (A): The most useful value and quality requirements will be quantified, and will use other mechanisms, including careful corresponding stakeholder analysis [1, 51, and 52], to facilitate understanding.

Tom’s reformulation (B): The most cost-effective designs/architecture, with respect to our quantified value and resource requirements, will be estimated and progress tracked, utilizing a Value Decision Table with its evidence, sources, and uncertainty. They will be prioritized by values/resources with respect to risks [45].

Tom’s reformulation (Simplified, combined): We will use engineering quantification for all variable requirements, and for all architecture.

Antimatter translation: Choose organisational structures and methods (teams, heroes, feature teams, self-organisation, quantification, etc.) for the endeavour that meet the needs of everyone that matters. Manage these (dynamic and potentially conflicting) needs, including negotiated solutions, just as all the other needs in the endeavour.

Antimatter simplification: Agree on attributes of quality, and levels of quality, with respect to the organisation of the endeavour, that meets the needs of everyone that matters.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Tom’s reformulation: A process like the Defect Prevention Process (DPP), or another more-suitable for current culture, which delegates power to analyze and cure organizational weaknesses, will be applied: using participation from small self-organized teams to define and prove more cost-effective work environments, tools, methods, and processes.

Antimatter translation: Aim to learn as much from our work as meets the needs of everyone that matters. Manage these needs, including negotiated solutions, just as all the other needs in the endeavour. 

Antimatter simplification: Pursue improvement, with respect to the means and organisation of the endeavour, that meets the needs of everyone that matters.

Summary

The key insight that emerges from this exercise in translation is this:

Once we have a more-or-less formal and established approach for identifying who matters and their needs, with respect to the endeavour at hand – and then tracking, negotiating and managing the evolving community of “everyone that matters” and their needs – much of the minutiae of the Twelve Principles, and debates thereon, evaporates.

In a nutshell: we must attend not only to the needs in the context of the particular product or service under development, but also to the needs of everyone that matters in the context of the means (conduct, organisation) of that development effort.

– Bob

Pillars

March 8, 2018
Antimatter principle, Engineering, Organisational effectiveness
1 Comment

Pillars

I was about to name this post “Pillars of TOC”, but after second thoughts I believe these pillars are equally useful outside of their immediate Theory of Constraints context.

Do you need to be able to think more clearly? Or maybe you know someone who would benefit from clearer thinking?

Goldratt asserts the pillars described below as foundational to “clear thinking”:

  • Inherent Simplicity
  • Every Conflict Can Be Removed
  • People Are Good
  • Never Say I Know

Pillar: Inherent Simplicity

This first pillar is a choice. An intention to look at situations as if they were always inherently simple. As if the nature of reality itself is simple (and harmonious).

“Reality is simple and harmonious.”

If we choose to proceed as if this were true, then we will be less likely to get trapped in looking for sophisticated explanations and complicated solutions. We will be less likely to channel our attention towards just those things we allow ourselves to see.

“The first and most profound obstacle is that people believe that reality is complex, and therefore they are looking for sophisticated explanations for complicated solutions. Do you understand how devastating this is?”

~ Goldratt, Eliyahu M.. The Choice, Revised Edition (Kindle Locations 213-215).

For clear thinking, we must choose to proceed as if we accept the idea of Inherent Simplicity, as a practical way of viewing reality, any reality. We may even go so far as to choose this as our approach to life in general.

“The biggest obstacle is that people grasp reality as complex when actually it is surprisingly simple.”

~ Goldratt, Eliyahu M.. The Choice, Revised Edition (Kindle Locations 219-220).

So what exactly do we mean by Inherent Simplicity? In a nutshell, Inherent Simplicity is the cornerstone of all modern science, as stated by Newton: “Natura valde simplex est et sibi consona.” We may translate this as “nature is exceedingly simple and harmonious with itself”.

Note: Goldratt states that with the Theory of Constraints, he takes a “Hard Science” perspective in all situations.

In practice, this means examining the cause-effect relationships within a given situation. And, contrary to our intuition, where we would expect some form of combinatorial explosion of complexity to result, Inherent Simplicity (and Newton) tells us that the system will converge, and common causes will inevitably appear as we drill down. If we drill down deep enough, we’ll find just a very few, or maybe even just one, root cause. So the result of systematically examining the cause-effect relationships in a situation leads us not to enormous complexity, but to wonderful simplicity.

If you doubt this, take a look at this article explaining the relative simplicity of two systems.

Hint: If I’m a scientist or a manager, I’m not so much interested in how difficult the system is to describe, but more in the difficulty of controlling and predicting its behaviour, especially when changes are introduced. The scientist or manager’s definition of complexity is: “the more degrees of freedom the system has the more complex it is.”

We’re not claiming that reality is not overwhelmingly complex; we acknowledge it in full. But what we are claiming that we can see things more clearly, think more clearly, when we choose to proceed on the basis that reality is exceedingly simple.

Note: We may begin to see how this perspective renders the idea of “complex adaptive systems” irrelevant.

Pillar: Every Conflict Can Be Removed

Let’s come back to the earlier proposition about Inherent Simplicity, that “Reality is simple and harmonious (with itself).”

We may choose to interpret “harmonious with itself” to mean that there are no contradictions in nature. In the material world. In “reality”.

“There are no conflicts in reality.”

For example, if we measure the length of a rod, by two different methods, and get two different answers, we don’t compromise. We don’t say “let’s split the difference and use the average between the two methods”. The contradiction between the two methods signals us that somewhere along the line we have made an erroneous assumption of some kind. And so we’ll go looking for that flawed assumption, and never accept a compromise. Such is the strength of our belief that there can be no contradictions in nature.

But this pillar is about conflicts, not contradictions. A conflict can occur any time we have opposing requirements, such as the need for an aircraft wing to be both strong and light. All undesirable effects (in the cause-effect relationships within a given situation) stem from such conflicts.

So this pillar is about choosing to proceed such that we treat every conflict like a scientist treats a contradiction. Which means, examining the conflict to uncover the inherent erroneous assumption(s), and refusing compromise as a way out.

“Don’t accept conflict as a given.”

Note: All forms of optimising and optimisation fall into the category of “compromising”. Such a waste of everyone’s time and talents.

Pillar: People Are Good

With this pillar, we come back again to the idea of harmony. This time we’re interested in another obstacle to thinking clearly: blaming others.

“Blaming another person is not a solution.”

In fact, in many cases, blaming others points us in the wrong direction, away from a solution. Even if the person we blame were to be fired, in most cases the problem will remain. Blaming is a sure-fire way to undermine the harmony in our personal relationships.

And we need that harmony, so that we can collaborate effectively with other people (our peers, our suppliers, our customers) in finding the solutions we seek.

So, we choose to proceed with the deep conviction that harmony exists in any relationship between people (even though in most cases, by default, we don’t bother to find and implement it). We choose to proceed on the basis that

“Win-Win is always possible.”

This perspective allows us to think more clearly, and find solutions that work for all parties involved, not just one side. Yes, it’s more work, but it gives our solutions much more stickability.

And, incidentally, for effective harmonious relationships, we have to care about the people involved. We have to invest the time and effort into knowing them and their true needs (cf. The Antimatter Principle).

Pillar: Never Say I Know

When we choose to proceed on the basis that we know about a situation, we’re unlikely to seek improvements, to check for holes in our logic or understanding, or to believe that the situation can be improved.

So, let’s always proceed as if we DON’T know. This choice can help us think more clearly, examine the situation afresh, and discover different, more effective ways of doing the things that need doing.

“Every situation can be substantially improved.”

Summary

You may see the above pillars as largely philosophical, as a way of looking at the world. Personally, I choose to see them as pragmatic, as a way of interacting with the world. And, returning to the notion of harmony, we may begin to see how all these pillars complement each other, harmoniously.

Harmony: “the quality of forming a pleasing and consistent whole.”

– Bob

Further Reading

The Choice ~ Eliyahu M. Goldratt and Efrat Goldratt-Ashlag

 

The One Perfect Way to Develop Software

January 16, 2018
Engineering, Psychology, Rightshifting, Software development
Leave a comment

The One Perfect Way to Develop Software

[Tl;Dr: Being a Master of the perfect way to develop software is more of a handicap than an asset.]

Let’s imagine you’ve received a Matrix-style download of all the knowledge and skills necessary for Mastery of the perfect way to develop software. And you’ve applied this knowledge, and honed the skills, in several or many software development endeavours. And have the results to prove it.

Then you join a new-to-you organisation, and a new-to-you team, where of course you want to share your profound, highly valuable insights, capabilities, knowledge and skills with your peers, with a view to you all basking in the sweet success of the One Perfect Way.

Setting aside secondary issues such as the probability that there is no ONE perfect way, and that software development per se is maybe not what our customers are really interested in, what could possibly go wrong?

I’ll leave this question hanging. If I receive some expressions of interest, I propose to return to it in a future post.

– Bob

Further Reading

Characterizing people as non-linear, first-order components in software development ~ Alistair Cockburn

 

Learn Through Delivering

April 24, 2017
Agile, Culture change, Engineering, Organisational effectiveness, Product development, Software development
2 Comments

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 The Folks That Matter™️. 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 some or all of the Folks That Matter and these folks must be able to try them out in as near as possible to real-world situations so as to provide meaningful feedback. Does that just delivered meet their needs, totally, a lot, a little or not at all?

Cadence

Just how often might we deliver something for folks 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 the folks that matter to you 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 experiment with a change of perspective – from learning through doing, to learning through delivering – as soon as you have the opportunity?

– Bob

Tasks – or Deliverables

April 20, 2017
Culture change, Engineering, Organisational effectiveness, Product development, Psychology, Software development
Leave a comment

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

 

Nine Aspects Of Top Developers

September 4, 2015
Antimatter principle, Engineering, Product development, Recruiting, Software development
2 Comments

Nine Aspects Of Top Developers

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

Business Development

July 16, 2015
Doctrine, Engineering, Leadership, Organisational effectiveness
2 Comments

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

Out Of House FlowChain

April 14, 2015
Agile, Engineering, Flowchain, Organisational effectiveness, Product development, Software development
1 Comment

Out Of House FlowChain

When I conceived of FlowChain, some six years ago now, my immediate context was development shops with their own in-house developers, and other supporting staff.

But it strikes me that with just a few adjustments, it’s also suitable for organisations that sub-contract out most or all of their development projects to third parties.

These adjustments centre around arranging for the various third parties (assuming, in the likely case, that there’s more than one) to each contribute staff to the “Pool” (see diagram). These arrangements include:

Commercial

How will the third parties be paid? Some UK government functions use function points as a measure of “work done”, with a set price for each function point “delivered”. See: Output-based contracts. I can imagine other contractual arrangements, too.

Social

How will the third parties’ staff integrate or form healthy relationships with the in-house commissioning staff (a.k.a. product owners)? Will there be shared spaces? Regular visits to and fro? Some more technical forms of communication (Twitter, chat, video conferencing, etc.)? Remember, each backlog item is sized for two to three people working together for two to three days.

Tooling

Third parties remain free to pull items from the backlog as they see fit (just as with in-house FlowChain), and use their own tools, languages, etc.. I foresee some advantages in having a common code repository, coding and other standards, agree requirements around test suites, and so on.

Delivery Into Production

Maybe the organisation contracting the third parties has its own Ops department. In this case the interface between development (teams, third parties) and Ops would probable best be standardised and agreed (like an API). If the third parties have their own Ops folks, then they can do DevOps in their own space and time, and serve the “production” services – or even micro-services – they each operate, directly to users.

Shared Backlog

For clarity, this variant of Flowchain retains the enterprise-wide backlog, with user stories, improvement stories, etc. being prioritised by some black box (or white box) prioritisation algorithm, committee, manager, or whatever. The only real change is in how the Pool is constituted. Note: I see no particular reason why the general FlowChain principle of “ANY unassigned development folks from the Pool can coalesce around each new top backlog item” cannot stand, here.

There may even be emergent advantages in having e.g. developers from different third parties coming together to collaborate on specific backlog items. How weird would that be? Again, policy would guide folks’ actions here.

Who would “manage” the backlog?  This could be done by a small in-house staff, or itself subcontracted out to one or more third parties. Note: the backlog in FlowChain is largely self-managing, in any case, given an effective prioritisation algorithm or approach.

Flow

Flow (of e.g. software into the hands of those whose needs are being attended to) remains the key objective of the whole approach.

Growing An In-house Capability

For organisations without an in-house development capability, this approach provides a simple(r) path to establishing and growing an in-house development capability. In-house developers can be added, one by one, as and when circumstances (budgets, priorities, etc) allow. These new folks can work alongside – and learn from – third-party staff already used to Pool working, and the balance between in-house and out-of-house staff, skill sets, etc. adjusted dynamically as needs dictate.

Drawbacks

The key drawback I foresee is in the matter of dev-ops integration (DevOps). This could prove more difficult, in the case where developers, etc. are out-of-house and Ops in-house. This seems a special case of the issues of outsourcing and offshoring, generally. But I’m sure a bunch of smart developers and smart ops can work this out, especially with some help and guidance.

– Bob

No Testing

November 7, 2014
Agile, Doctrine, Engineering, NoTesting, Product development, Software development
27 Comments

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

 

 

 

 

 

Things We Could Be Doing

May 18, 2014
Agile, Doctrine, Engineering, Organisational effectiveness, Product development, Rightshifting
15 Comments

Things We Could Be Doing

I’ve spent much of my career exploring the world of knowledge-work, and especially the world of software and product development. I’ve seen many businesses, most of whom share a common view of the way work should work, the way to design products, the way to find and organise people to staff the business, and so on. I’ve seen how these common approaches fall way short in terms of results. And I’ve seen, or imagined, other, less common ways which could make a huge difference to the success and profitability of businesses everywhere.

There’s a whole passel of things we could be doing, that we’re not, presently. We could be…

Creating Environments Better Suited To Knowledge Work

Most “environments” in which I have seen folks trying to get work done are woefully ill-suited to doing effective knowledge work. Very few businesses seem to understand even the interplay between environmental factors and outcomes. And fewer yet, those who have actually created and sustained effective working environments.

Aside: By “environment” I have in mind various aspects:

  • Physical – the floor layout of the office space; the decor, lighting and general ambience; the architectural style of the office buildings; the situation of the office buildings themselves (city, parkland, countryside, wilderness); facilities (shared spaces, dining, leisure and recreation, etc).
  • Technical – webtone; the choice of hardware, OS, tools; and so on.
  • Social – how people generally relate to one another and treat each other.
  • Dynamics – High-energy or plodding; stressful or laid-back; studious or action-oriented; high-risk or safety-conscious; etc.

Reliably Designing Products Which Buyers Crave

We know now that people don’t buy products or services on rational bases. Rather, they buy on emotional bases, and then, maybe, use rationality to justify those decisions, post-hoc. Why then do so many businesses still spend so much time and effort designing their products to appeal to rational buyers?

Designing “Whole Products”

Most businesses cobble together new products and services, conducting a more or less random walk through their vertical silos for each new product development. And then stuff these new products into the existing silos in the hope that sales and profits will accrue. We could be recognising that development of new products is the lifeblood of most organisations, and organising along those lines.

Organising Around Flow

One common strategy for businesses has long been managing to reduce cost. Much more effective would be to manage (e.g. constraints) so as to improve flow (of new products to market, value to customers, or of needs, to all stakeholders).

Having Everyone On the Same Page

Most businesses I have seen have folks running around like headless chickens, hither and yon, with precious little alignment or general understanding of common goals, strategies, and so on. Many tools, techniques and other means to get and keep folks on the same page exist. Few business use any of them. Nor realise the cost and other impacts of such chaos.

Improving The Effectiveness Of Our Businesses

More-or-less random local improvements seems to be the best most businesses aspire to. We could be systematically and progressively improving our businesses on a near-continuous or continuous basis. We only have to look as far as e.g. Toyota to see the stupendous rewards this can bring in the long term.

I see very little of any of the above happening in any businesses. After all these years, I still wonder why. How about you? Would you be willing to share your perspective?

– Bob

 

 

Objectives, Proclaimed vs Practised

April 18, 2014
Agile, Engineering, Leadership, Organisational effectiveness, Product development, Rightshifting, Software development
3 Comments

Objectives, Proclaimed vs Practised

Tl; Dr: Most organisations do software development not for the outputs, but to satisfy the members of the core group, whose needs are pretty much entirely disconnected from both software quality and the evolution of an effective development organisation.

Mistaken Beliefs

“Discrepancies between objective proclaimed and objective practiced can be observed in most organizations. For example, one could mistakenly believe that the principal objective of universities is to educate students. What a myth! The principal objective of a university is to provide job security and increase the standard of living and quality of life of those members of the faculty and administration who make the critical decisions. Teaching is a price faculty members must pay to share in the benefits provided. Like any price, they try to minimize it. Note that the more senior and politically powerful teaching members of the faculty are, the less teaching they do.”

~ Russell L. Ackoff

So To Software Development

One could mistakenly believe that the principle objective of e.g. software houses and other software-producing organisations is “working software”. What a myth! The principle objective of such businesses is to provide job security and increase the standard of living, positive self-image and quality of life of those in the core group of these organisations, and provide sufficient (read: minimum) income, entertainment and other such “attractions” necessary to retain the continued attendance of the rest of the workforce. “Frontline” work such as coding, testing, designing, decision-making, etc. is a price core group members must occasionally pay to share in the benefits provided. Like any price, they try to minimise it. Note that the more senior and politically powerful the core group member, the less frontline work they do.

The Core Reason For Lameness

Here we have one answer to the question “Why are software products generally so lame?”. Note: we could also phrase this as “why does the practice of software development generally result in outputs (software, products) with such limited positive impacts (outcomes) for anyone but members of the core group?”. Or more bluntly: “Why does no one ever seem to care that we’re just continually churning out crap?”.

Just like universities, where the positive outcomes for students are more or less limited to a handy, albeit increasingly expensive qualification, in software development positive outcomes for customers and workers are more or less in the lap of the Gods (or the members of the core group, which we may choose to regards as synonymous).

– Bob

Further Reading

Who Really Matters ~ Art Kleiner

We Have The Technology…

March 7, 2014
Engineering, Organisational effectiveness, Product development, Rightshifting, Software development
1 Comment

We Have The Technology…

Did you know that some companies have applied development/engineering principles to their organisations as a whole? Very few, granted. But it does happen. I mean, they intentionally design their organisation, its structures, processes, systems (human- and technology- both), interactions, the way the work works, etc. to better meet certain business goals.

And the resulting organisational “operating systems” look very different to the copycat, zombified, cargo-culted, grow’d-like-topsy majority.

The general idea gained some attention – and then notoriety – under the label Business Process Reengineering, circa the late nineteen nineties. Of course, like many ideas before then – and e.g. Agile, Lean, etc. since – those folks of the Analytic mindset bought into the reported benefits, without realising the change in mindset that successful adoption/application of BPR required. When the expected benefits failed to appear, they both canned and vilified the idea. It wasn’t long before the whole shebang was consigned to the trashcan of history.

Why bring up the whole sorry tale once again?

I’ve been musing on what it means to be a world-class software (software) engineering organisation. What happens when we happily apply engineering principles to the development of products, but ignore those principles when it comes to how the organisation operates across the board? To the development of the organisation itself? Is that a sure-fire recipe for Organisational Cognitive Dissonance?

And if we have a cadre of folks who understand and embrace engineering disciplines and principles in the building (development) of products, why not put those talents to good use in the service of building an organisation with world-class operational capabilities? In all aspects of running the business?

Although, there’s always the possibility that an organisation espouses becoming a world-class engineering company, yet has insufficient grasp of what “world-class engineering” means to be able – or willing – to apply it in the whole-business context.

Would you be willing to share your thoughts?

– Bob