Systems Thinking, Project Management, and Agile – Part 6: “Abandon All Hope,…”

[For this series, it will help to have read “System Dynamics and Causal Loop Diagrams 101.”]

“…ye who enter here.” So reads the inscription to the Gates of Hell in Dante Alighieri’s epic poem, “Divine Comedy.” Who among us hasn’t felt on occasion that stepping across the threshold to our place of employment is like passing through the gates of Dante’s Inferno? But as the poets have told us, the way to peace is to find the path through our troubles. In this article, we’ll look into just how deeply project system dynamics can adversely affect progress and even whether or not the project is successful.

But I do want to arm the reader with a couple of rays of hope. The concluding article in this series will focus on how this system model1 can be used to good effect, how it can be used to identify problems before they grow out of control. Therein lies the path to peace. Before we get there, we need to understand several more influential feedback loops.

As the Delay to Completion becomes critical, management begins to panic. Not wanting to push the deadline out they work to influence the other three options focused on modifying the behavior of the delivery team. The end result is a team that is caught in the Work Faster, Work More, and Add People loops along with all the other associated downstream loops. The effect is compounded by the emergence of other feedback loops if teams are placed in this position for an extended period of time.

Over time, the shortcuts, hacks, and quick fixes put in place to keep the pace of progress as high as possible settle in as technical debt. They work – for now – so they don’t surface as errors for quality assurance to discover. Down the road, however, solutions hastily put in place as stop-gaps fail when later solutions require existing solutions to be more robust then they are. For example, a software method that doesn’t take advantage of multi-threading may break when a later solution needs that method to scale beyond it’s single thread capacity. The shortcut is now a defect.

Figure 1

If the technical debt remains in place for an extended period of time, it may be covered by several release layers. When it does flip to defect status due to some later stress, it can be much more time consuming and expensive to uncover. The original developer of the code may not be available or even if she is, it could take her quite a bit of time to become reacquainted with the code. This can be thought of as a form of dark debt and is reflected in the Errors Build Errors Loop (Figure 1, J).

As the teams struggle to keep up the pace of progress and reduce the Delay to Completion, work streams start to become out of sequence. One team has an easier time at crafting their solution while another, to which they are dependent on the output, hits a significant snag and is delayed several weeks. In order to stay busy, the first team starts work on something else while the second team finishes their work. When the second team delivers, the first team is not prepared to immediately shift back to their original work stream and so their deliverable is delayed even further. Meanwhile, a third team, that was dependent on the first team’s deliverable has now been delayed by the cumulative delay of the first two teams. Teams and individuals begin to take shortcuts as delivery of interim work products become out of sync with each other. The diminished focus and desynchronization of work streams leads to an increase in the Error Fraction, which in turn leads to a further Delay to Completion. This is the Haste Makes Out-of-Sequence Work Loop (Figure 1, K).

Figure 2

As the effects of the Haste Makes Out-of-Sequence Work Loop build,  team begin switching back-and-forth between work streams depending on who is making the most noise for the completion of any particular deliverable. This is the Thrash and Churn Loop (Figure 2, L). Switching from stream to stream or, in worst cases, task to task, places a tremendous burden on development teams and can do more to slow progress than almost anything else I’ve encountered in team management. Not covered in this model is the type of churn that occurs when parts of the project undergo redesign after work has begun on the existing design. Long term projects are particularly susceptible to adverse impacts from redesign as the changes are often farther reaching. The drivers behind a redesign can range from trivial (a new CTO has a personal dislike for a platform vendor) to critical (a security flaw uncovered in a core technical component.)

If all the loops described to this point in the article series are allowed to run uncorrected the system is likely to crash as the project becomes one massive firefighting effort. A key indicator for when this is happening is employee morale.

Figure 3

The increased Fatigue, the growing burden of Work/Rework to Do, the unsatisfying Task Switching between work assignments all combine to causes a decrease in team Morale. This is the Hopelessness Loop (Figure 3, M). Teams are left with a powerless feeling of being caught on a never ending treadmill. And so, stepping across the threshold to the office is like passing through the gates of Dante’s Inferno.

The ripple effect from a decrease in Morale leads to a decrease in the Workforce as employees leave the organization in search of less stressful, more satisfying work. This is the Turnover Loop (Figure 3, N). The remaining demoralized employees are even less productive and unhappy employees make more mistakes, thus increasing the Error Fraction in the system. The downstream result is that the Delay to Completion increases yet again.

If corrective action isn’t taken the law of diminishing returns becomes evident and the system collapses. The cost overruns become prohibitive and the project is cancelled. Worst case, the organization runs out of resources (money, time, or both) and goes out of business. Those are bad things. In the concluding article to this series, we look at how this model can be used to read the current state of a project’s system dynamics and explore some ways we can intervene such that the system doesn’t run out of control.

References

1The core of the model I use to assess team and organization health is based on the work of James Lyneis and David Ford: System Dynamics Applied to Project Management, System Dynamics Review Volume 23 Number 2/3 Summer/Fall 2007


Image by Myriams-Fotos from Pixabay

The Shopping Mall in Your Inbox

Ian Bogost writes in the Atlantic:

It feels like every company and organization I’ve ever transacted with sends me email every week. Some every day, even. Some multiple times a day.

I see this in action with my wife’s “free” email account hosted by one of the major players in the email provider space. She has another email account that sees none of this. Not because that address is unknown but because it’s hosted on a private email server that I run. Nothing gets through that isn’t specifically allowed by the postfix/spamassassin filters and lists. It’s quite simple, really. If either of us wants to do business with a company that requires an email, I create an email alias with the company’s name as the username. That alias is then assigned as a value to a “whitelist_to” key for spamassassin and entered into an virtual aliases database table for postfix to know the actual email account where the message should be delivered.

If we start getting messages from companies that don’t match the username, we know the original company either sold their list or has been compromised. When that happens, the alias assigned to the “whitelist_to” key is reassigned to a “blacklist_to” key and the alias removed from the virtual aliases database table. We never see another message sent to that alias.

In a very few cases, this also means changing the email address registered with the original vendor. But more often than not, the alias was set up as a one-time purchase and can safely be excluded. I have hundreds of these aliases set up.

The major email providers could implement a system like this. But their business model relies on advertising revenue and such a system isn’t in their interests. The people who have signed up for a “free” email account are, after all, part of their product. And why would they listen to their product and not their paying customers.

Speculating about a perfect world, Ian continues…

The algorithms churn until you’ve interacted with enough promotional emails that every store you like delivers perfectly timed messages that cater to your every need and desire. Fulfilled, happy, you purchase every item advertised to you. Of course, this is not actually what happens. The irony of people’s supposed desire to receive emails from their favorite companies is that more than half of consumers in the United States and Canada say they receive too much promotional email. Personalization is supposed to make relevant messages get through and irrelevant ones falter. But what “relevance” means is constantly changing. If I need new pants, an apparel ad might be welcome. If I don’t, it’s just annoying.

This is the downside of a push system. My email server is more aligned with a pull system. If w need or want something, we go look for it, usually at some place we’ve shopped before. It’s a minimalist mindset thing. The personal habits around this approach greatly minimize impulse purchases. The lack of stuff in our life reflects the success of this strategy – we have no debt, drive 20 year old cars, and replace phones only when the apps we need no longer work because Android no long supports them.

Ian continues…

The fundamental reason marketing emails are clogging up everyone’s inboxes is that email marketing represents the collective outcome of a company’s interactions with its customers and the mailbox services; it does not, in other words, represent me.

Indeed. Virtually all the email marketing from a vendor is opt-out once you’ve given them your email address. Research suggests there would be significant shift in the amount of follow-on marketing if everything was opt-in.

Quoting Helena Tse, the vice president of marketing at Bonobos, Ian observes:

She also told me that the company “continuously explores how to better our toolkit to automate and optimize the frequency business rules.” A professional proclamation such as this might elicit nods at an industry conference, but it casts me in the role of a generator of data rather than a paying customer—let alone a living person who doesn’t need so many invitations to partake of Riviera shorts.

As I said, when you give your “free” email address to a business, you’ve become part of the overall product.


Photo by Matthew Henry on Unsplash

Achieving 10x

Crossed paths with an old but still relevant conversation thread on Slashdot asking “What practices impede developers’ productivity?” The conversation is in response to an excellent post by Steve McConnell addressing productivity variations among software developers and teams and the origin of “10x” – that is, the observation noted in the wild of “10-fold differences in productivity and quality between different programmers with the same levels of experience and also between different teams working within the same industries.”

The Slashdot conversation has two main themes, one focuses fundamentally on communication: “good” meetings, “bad” meetings, the time of day meetings are held, status reports by email – good, status reports by email – bad, interruptions for status reports, perceptions of productivity among non-technical coworkers and managers, unclear development goals, unclear development assignments, unclear deliverables, too much documentation, to little documentation, poor requirements.

A second theme in the conversation is reflected in what systems dynamics calls “shifting the burden”: individuals or departments that do not need to shoulder the financial burden of holding repetitively unproductive meetings involving developers, arrogant developers who believe they are beholding to none, the failure to run high quality meetings, code fast and leave thorough testing for QA, reliance on tools to track and enhance productivity (and then blaming them when they fail), and, again, poor requirements.

These are all legitimate problems. And considered as a whole, they defy strategic interventions to resolve. The better resolutions are more tactical in nature and rely on the quality of leadership experience in the management ranks. How good are they at 1) assessing the various levels of skill among their developers and 2) combining those skills to achieve a particular outcome? There is a strong tendency, particularly among managers with little or no development experience, to consider developers as a single complete package. That is, every developer should be able to write new code, maintain existing code (theirs and others), debug any code, test, and document. And as a consequence, developers should be interchangeable.

This is rarely the case. I can recall an instance where a developer, I’ll call him Dan, was transferred into a group for which I was the technical lead. The principle product for this group had reached maturity and as a consequence was beginning to become the dumping ground for developers who were not performing well on projects requiring new code solutions. Dan was one of these. He could barely write new code that ran consistently and reliably on his own development box. But what I discovered is that he had a tenacity and technical acuity for debugging existing code.

Dan excelled at this and thrived when this became the sole area of his involvement in the project. His confidence and respect among his peers grew as he developed a reputation for being able to ferret out particularly nasty bugs. Then management moved him back into code development where he began to slide backward. I don’t know what happened to him after that.

Most developers I’ve known have had the experience of working with a 10x developer, someone with a level of technical expertise and productivity that is undeniable, a complete package. I certainly have. I’ve also had the pleasure of managing several. Yet how many 10x specialists have gone underutilized because management was unable to correctly assess their skills and assign them tasks that match their skills?

Most of the communication issues and shifting the burden behaviors identified in the Slashdot conversation are symptomatic of management’s unrealistic expectations of relative skill levels among developers and their inability to assess and leverage the skills that exist within their teams.


Image by alan9187 from Pixabay

Cook’s Theory of Performance Evaluation

The ideas presented here evolved from a post titled “Evaluate people at their best or their worst?” on John Cook’s blog. In order to make this post a little tighter, I’ll refer to John’s ideas as “Cook’s Theory of Performance Evaluation” and describe it as follows.

John identifies three ways a person’s performance can be evaluated:

  1. How good are they at their worst?
  2. How good are they on average?
  3. How good are they at their best?

Cook observes that schools evaluate performance using the first two benchmarks and markets use the third benchmark. To illustrate, consider the following assignment grades for a student in a hypothetical course:

Assignment Score
1 100
2 90
3 92
4 87
5 100
6 45
7 90
8 100
9 95
10 100
Average: 89.9
Result: B+

Graphically, this looks like:

The student’s worst performance pulls the grade average down and results in a B+ for the course. Performance evaluation in markets, however, is only interested in how well you do, that is, your best. Consider the following sales volumes for a fictional author for each of ten books:

Book Copies Sold
1 1,000
2 2,500
3 900
4 1,100
5 3,400
6 1,000,000
7 42,000
8 6,500
9 2,750
10 3,100
Result: Bestseller!

Graphically, this looks like:

Number 6 must have been some story. But as they say, you can’t argue with success and this author will forever be known as a bestseller. Subsequent flops won’t change that.

So there you have Cook’s Theory of Performance Evaluation. The consequences of this theory when played out in real life are noted by Cook:

We all want others to see the best in us. There are ethical and economic reasons to look for the best in others. But years of education can incline us to look for the worst in others and in ourselves.

Another point that can be made is that in school, everyone starts out with a perfect score that for most students erodes as the class progresses. In markets, everyone starts out with essentially a zero score that for most entrepreneurs improves over time, commensurate with the individual’s effort. Money, of course, is another way to keep score in market-based performance evaluations.

If education has conditioned us to look for the worst in others and ourselves, it has also conditioned us to become demoralized when encountering even the slightest failure that diminishes our chances at succeeding. Once lost, the perfect score can never be regained, so we settle for less. The greater the failure, the less we must settle for.

Moreover, we are conditioned that we can never exceed the highest possible achievement as defined by academia. The best we can do is match it. Most come up short. This conditioning is difficult to shake and in my own experience took several years after obtaining my undergraduate degrees. Nothing like 100+ job rejection letters to cause one to reevaluate the nature and size of the door opened by a couple of college degrees.

There are other ways to evaluate an individual’s performance.

  1. How good are they compared to others (past and present)?
  2. How good are they compared to themselves in the past?
  3. How good are they compared to their personal criteria and expectations?
  4. How good are they compared to the criteria and expectations of others?

The answer to each of these questions can be radically different depending on the referential index of the questioner. “How good am I when compared to others?” is significantly different from “How good is he/she when compared to others?”

The answers to each of these questions can also be significantly influenced by various biases and prejudices. Confirmation bias, hindsight bias, self-serving bias, the Dunning–Kruger effect, the misinformation effect, self-handicapping, self-fulfilling prophecies, introspection illusion, groupthink, the affect heuristic – numerous ways an individual can skew the evaluation of their own performance.

When the performance evaluation comes from a third party, for example a university professor evaluating a student’s performance, there are a different combination of biases in play which can have an independent impact on the performance score. The fundamental attribution error, confirmation bias, the illusion of transparency, credentialism or argument from authority – more ways the individual’s eventual performance score can can be unconsciously influenced. The combination of unconscious incompetence and the Dunning–Kruger effect can have a particularly adverse effect on the student who asks questions that expose a professor’s incompetence.

Here again, the level playing field appears to be with market-based performance evaluations. An individual’s ability to understand and mitigate biases and prejudices affecting their success will have a direct impact on their performance in the market. Students, however, have less influence over these drivers when they are manifest in individuals working from a position of authority.


Image by StockSnap from Pixabay

Innovation and Limits to Growth

In a basic growth model, some finite resource is consumed at a rate such that the resource is eventually depleted. When that happens the growth that was dependent on that resource stops and the system begins to collapse. If it happens that the resource is renewable eventually the rate of consumption matches the rate of renewal and the system enters into a state of equilibrium (no growth). This is illustrated by the black line in Figure 1. In this second scenario if the rate of consumption exceeds the rate of renewal the system will again collapse.

In the Solow model of growth (neoclassical growth model) a new element is introduced: the effect of technology or innovation on the growth curve. Without innovation, in systems where technology stays fixed, growth will eventually stop. The introduction of innovative solutions to resource problems, however, has the effect of raising the upper bound to growth limits. This is illustrated by the red line in Figure 1.

Figure 1 - Innovation Boost
Figure 1 – Innovation Boost

A prevailing assumption with innovation is that it is necessarily synonymous with invention. To be innovative is to create something that has not previously existed. This is an erroneous assumption. History is filled with accounts of dominant societies furthering their success by adopting innovative discoveries made by smaller societies. The adoption of Arabic numerals by countries that had previously used Roman numerals is a striking example of a dominant society integrating an innovation from a smaller society.

The challenge for an organization, then, isn’t so much how to be innovative, rather, how to better recognize and adopt innovations discovered elsewhere. More succinctly, how to better seek out and distinguish innovative solutions aligned with the organization’s strategy from those that simply rate high on the coolness scale.

Layoffs

I’ve never been fired, but have been laid off three times over the course of four distinct careers. I’m also three-for-three for having landed in a much better place after having been laid off. So with three data points, maybe there is some truth to the street wisdom that a little adversity is a good thing.

“I judge you unfortunate because you have never lived through misfortune. You have passed through life without an opponent- no one can ever know what you are capable of, not even you.” – Seneca, On Providence, 4.3

I have also survived 17 layoffs. And I remember them all.

Paradoxically, many of the layoffs I survived were more painful than the layoffs in which I was included. I have clear memories of people I enjoyed working with that one day were simply gone from the place I was spending more than one third of my life. The resulting crash of morale at the workplace simply added to the sense of dread and “why bother” attitude. Their absence became a reminder that we were all living under someone else’s Sword of Damocles, that we would pay the price of poor decisions made by someone else. In some instances, the nauseatingly smug expression of schadenfreude by a few well-connected corporate parasites and toxic individuals cruising the corridors just added to the sting. It doesn’t seem this is easier to deal with by those that remain after a layoff in a distributed work environment.

To say I’ve “survived” all the layoffs that occurred throughout my multiple careers, whether I was culled or not, is more than a little melodramatic. I have truly survived much, much greater losses. Layoffs are not lethal events and living according to several key Stoic principles has helped me to persevere and gain strength from the brief storms of finding work.

“To bear trials with a calm mind robs misfortune of its strength and burden.” – Seneca, Hercules Oetaeus, 231232

Reflecting on work transition experiences, I wondered what is it about having been laid off that made the next place so much better.

I have always worked hard to add value to my employer’s business. If that value was either not appreciated or the business shifted away from needing the value I was capable and willing to provide, it was a clear sign that it’s time to move on. By making this a choice, I could leave with no hard feelings and no burned bridges. Psychologically, this is more intimidating but much healthier.

Seeing the positive side of being laid off can be a little more difficult, particularly if one has been blind to the signs that every company and manager broadcasts when a layoff is eminent and is surprised when they happen. For starters, layoffs erased all the baggage I was carrying that belonged to the employer and made it much easier to strike out in a direction that suited my interests, skills, talents, and goals. Each of the three layoffs launched new, more lucrative and rewarding careers.

“Today I escaped from the crush of circumstances, or better put, I threw them out, for the crush wasn’t from outside me but in my own assumptions.” – Marcus Aurelius, Meditations, 9.13

Switching employers, even careers, more frequently than previous generations is a good career development strategy. In the dot com era, it was the only effective way to find meaningful raises and career advancement. Why toil away for a decade under Management-by-Taylorism to scratch out incremental pay increases when a salary could be increased by 10%-20% just by switching employers? Twenty-five years on, staying with the same employer for more than five years actually looks odd to many recruiters I’ve been talking to.

A friend of mine has a personal policy to commit to an employer for 1,000 days. At that point, she decides if the workplace it meeting her goals and expectations. Doesn’t matter if it’s a shortcoming of her employer or if her goals and interests have changed – a mismatch is a mismatch so it’s time to leave. I think it’s a good policy, particularly in the Age of Information and Knowledge and distributed workforces.

A policy like this builds resilience in several ways.

1. It’s important to know what it takes to persevere with the crap work that goes with just about any job. Flitting from job to job doesn’t develop this. A 1,000 day commitment is enough to show that you made it past the “honeymoon” period every job has, have worked more than a few significant problems into solutions, and generally paid your dues and demonstrated – if only to yourself – you have the chops to do the work.
2. Deciding to leave a job and doing so multiple times throughout your life builds confidence in your abilities to create your future.
3. It adds a valuable layer to your talent stack, as Scott Adams has described it.

If it was generally known that employees had this policy, employers might expand their efforts to foster cultures that allow employees who are creative and collaborative to thrive and grow. Instead of what’s more common: Cube farms propped up by career leaches that brag about having worked at the company for 25 years when in fact all they’ve done is worked one mediocre year and repeated it 24 times.

I’m done with that. Forever.

“There are those too who suffer not from moral steadfastness but from inertia, and so lack the fickleness to live as they wish, and just live as they have begun.” – Seneca, On Tranquility of Mind


Photo by Benmar Schmidhuber on Unsplash

Show Your Work

A presentation I gave last week sparked the need to reach back into personal history and ask when I first programmed a computer. That would be high school. On an HP 9320 using HP Educational Basic and an optical card reader. The cards looked like this:

(Click to enlarge)

What occurred to me was that in the early days – before persistent storage like cassette tapes, floppy disks, and hard drives – a software developer could actually hold a program in their hands. Much like a woodworker or a glass blower or a baker or a candlestick maker, we could actually show something to friends and family! Woe to the student who literally dropped their program in the hallway.

Then that went away. Keyboards soaked up our coding thoughts and stored them in places impossible to see. We could only tell people about what we had created, often using lots of hand waving and so much jargon that it undoubtedly must have seemed as if we were speaking a foreign language or retelling a fish-that-got-away story. “I had to parse a data file THIIIIIIIIIS BIG using nothing but Python as an ETL tool!”

Yawn.

This is at the heart of what burned me out on writing code as a profession. There was no longer anything satisfying about it. At least, not in the way one gets satisfaction from working with wood or clay or fabric or cooking ingredients. The first time I created a predictive inventory control algorithm was a lot of fun and satisfying. But there were only 4-5 people on the planet who could appreciate what I’d done and since it was proprietary, I couldn’t share it. And just how many JavaScript-based menu systems can you write before the challenge becomes a task and eventually a tedious chore.

Way bigger yawn.

I’ve since found my way back into coding. A little. Python, several JavaScript libraries, and SQL are where I spend most of my time. What I code is what serves me. Tools for my use only. Tools that free up my time or help me achieve greater things in other areas of my life.

I can compare this to woodworking. (Something I very much enjoy and from which I derive a great deal of satisfaction.) If I’m making something for someone else, I put in extra effort to make it beautiful and functional. To do that, I may need to make a number of tools to support the effort – saw fences, jigs, and clamps. These hand-made tools certainly don’t look very pretty. They may not even be distinguishable from scrap wood to anybody but myself. But they do a great job of helping me achieve greater things. Things I can actually show and touch. And if the power goes down in the neighborhood, they’ll still be there when the lights come back on.

Good Intentions, Bad Results

In The Logic of Failure, Dietrich Dörner makes the following observation:

In our political environment, it would seem, we are surrounded on all sides with good intentions. But the nurturing of good intentions is an utterly undemanding mental exercise, while drafting plans to realize those worthy goals is another matter. Moreover, it is far from clear whether “good intentions plus stupidity” or “evil intentions plus intelligence” have wrought more harm in the world. People with good intentions usually have few qualms about pursuing their goals. As a result, incompetence that would otherwise have remained harmless often becomes dangerous, especially as incompetent people with good intentions rarely suffer the qualms of conscience that sometimes inhibit the doings of competent people with bad intentions. The conviction that our intentions are unquestionably good may sanctify the most questionable means. (emphasis added, Kindle location 133)

That sounds about right. To this I would add that incompetent people with good intentions rarely suffer the consequences of imposing their good intentions on others.

The distinguishing feature of a competent individual with good intentions and an incompetent individual with good intentions is the ability to predict and understand the consequences of their actions. Not just the immediate consequences, but the long term consequences as well. The really competent individuals with good intentions will also have a grasp of the systemic effects of acting on their intentions. People with a systemic view of the situation are deliberate in their actions and less likely to act or react emotionally to circumstances. Doesn’t mean they will always get it right, but when they fall short they are also more likely to learn from the experience in useful ways.


Photo by Michael Dziedzic on Unsplash

There Will Never Be an Agile 2.0…

…for the simple reason there was never an “Agile 1.0.”

Claiming to have crafted “Agile 2.0” would be like publishing the “Declaration of Independence 2.0” or “The Laws of Thermodynamics 2.0.” The Agile Manifesto is foundational. It is a statement of first principles that underpin a mindset from which a mountain of tools, techniques, frameworks, and practices have been created.

As to methods, there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.Harrington Emerson

As a tool, its utility comes from providing a stable base from which we can clarify complicated problems. Much of the 2.0 stuff I’ve read adds complexity and complication to a simple set of values and principles. In this regard it reflects research that shows people are more likely to add to solutions rather than subtract.

It’s this notion of a stable base that flummoxes people seeking to assign versions to Agile. First principles are often unassuming, their beauty and brilliance is masked by their seemingly simple codification of how things best work. Neither are first principles about absolute truths. First principles can have first principles. The first principles by which I use a wood plane are different from the first principles used by the tool manufacturer when milling the steel for the blade. My first principles of use inherit and extend the manufacture’s first principles of milling steel.

The Agile Manifesto identified elements in software development that are non-reducible. To be clear, there are other first principle elements not included in the Agile Manifesto and the Agile Manifesto doesn’t apply to every conceivable context. Twenty years of experience of applying it’s four values and twelve principles to other areas of business have revealed this to be true. They are not, nor will they ever be, an absolute truth. As our understanding of why they work so well improves, so will the underlying principles. Frankly, I’m impressed they have held up this well this far into the Internet Age. And I certainly don’t expect them to withstand every challenge or be as durable as the Declaration of Independence of the Laws of Thermodynamics.

So when I read someone’s declaration of “Agile 2.0,” the first thing I want to know is if their proposal precedes the first principles established by the Agile Manifesto or are they trying to do something else. So far, it’s always been the something else. There may be some interesting thoughts related to an alternate framework or perhaps a change to common practices, but I’ve yet to see anything revolutionary or even evolutionary.

A second thing I look for: Is the author working to falsify any of the principles and have they done a good job of presenting their argument. Again, this hasn’t happened. Mostly I read a lot of complaints about wording or ambiguity or history or stuff that is little more than efforts to tag the foundation with a personal style of graffiti.

I’ve yet to see Agile’s next evolutionary phase. I hope someday I will.


Image by 은주 송 from Pixabay

Cargo Cults in Management

 

I first read about cargo cults in Richard Feynman’s book, “Surely You’re Joking, Mr. Feynman.”

I think the educational and psychological studies I mentioned are examples of what I would like to call cargo cult science. In the South Seas there is a cargo cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they’ve arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas–he’s the controller–and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential, because the planes don’t land. (p. 310-311)

I was a newly minted biochemist and Feynman’s unique perspective had a significant impact on my critical thinking skills. It established a “cargo cult” sensor in my brain. As my career developed and branched out into other areas of interest, the ubiquity of cargo cult thinking became apparent.

In the work place, “cargo cult” thinking may not necessarily be a bad thing. As a tool, it can be used as an “as if” frame for working out the solution to complex problems or gaining insight into black boxes. By assembling all the known and visible elements and arranging them to match the form as best as possible its easier to see what’s missing.

If an executive’s minions are behaving in a way that reflects his or her approach to management, is that a good thing? Here is where business leaders get into trouble. Are the executive’s minions imitating or implementing?

Less common, executives attempt to adopt practices that are successful at the knowledge worker level. About a decade ago I had worked to implement an Agile software development process with a small and highly capable development team. It was a daunting task: completely re-architect and develop a poorly coded application while supporting the old application. (In 30 years, this was the first and only time I recommended a complete redesign and rewrite of a major application.) Of course, we started each morning with a “daily scrum” meeting – sometimes called a “daily stand-up” – before the team set off to immerse themselves in code. These are very quick (15 minutes or less) meetings where everyone literally stands up for the duration of the meeting. The idea is that by standing, attendees are less likely to drone on about trivial matters or issues that do not require the entire team’s input. Complicated issues are quickly identified and scheduled for more detailed meetings, if necessary.

Six months into the project it was very clear our approach was working and insofar as the coding effort was concerned, we would be successful. The senior executive to this effort seemed impressed and decided to switch to a “stand-up” meeting format for the executive team meetings. They were “stand-up” meetings in name only. Rather than a once a week meeting that virtually always extended way beyond the originally scheduled 60 minutes, I now had to attend daily meetings that went on for 45-60 minutes during which nobody stood.

There were other issues with implementing the executive team scrum meetings. The senior executive did a poor job of modeling the behavior he sought and there was very little control over the clock. Developers are smart people and they notice things like this even though they are not directly participating. Among those being managed, it does little to inspire confidence in the management staff.

Nonetheless, I like the idea of applying Agile methodologies to management meetings. After action reports, as used by the military, would also help. There is also a place for storyboards and retrospectives. But implementing these and other elements would require a significant learning effort on the part of the management team. Not because the methods are difficult to understand, but because the MBA mindset of many management teams would have to loosen up a bit for the requisite unlearning to become possible.

Rethinking the idea of “management” in the context of Agile principles and practices blends quite nicely with many of the things I’ve learned around the idea of “Management as a Service.”

References

Feynman, R. P. (1985). “Surely you’re joking, Mr. Feynman!”: Adventures of a curious character. New York, NY: Bantam Books.


Image by Free-Photos from Pixabay