Posts Tagged Management Science

Love Me I’m an Agile Scrum Master

In the 1966 song, Love Me I’m a Liberal, protest singer Phil Ochs mocked the American left for insincerely pledging support for civil rights and socialist causes. Using the voice of a liberal hypocrite, Ochs sings that he “hope[s] every colored boy becomes a star, but don’t talk about revolution; that’s going a little too far.” The refrain is, “So love me, love me, love me, I’m a liberal.” Putting Ochs in historical context, he hoped to be part of a major revolution and his anarchic expectations were deflated by moderate democrats. In Ochs’ view, limousine liberals and hippies with capitalist leanings were eroding the conceptual purity of the movement he embraced.

If Ochs were alive today, he probably wouldn’t write software; but if he did he’d feel right at home in faux-agile development situations where time-boxing is a euphemism for scheduling, the scrum master is a Project Manager who calls Agile a process, and a goal has been set for increased iteration velocity and higher story points per cycle. Agile can look a lot like the pre-Agile world these days. Scrum in the hands of an Agile imposter who interprets “incremental” to mean “sequential” makes an Agile software project look like a waterfall.

While it’s tempting to blame the abuse and dilution of Agile on half-converts who endorsed it insincerely – like Phil Ochs’ milquetoast liberals – we might also look for cracks in the foundations of Agile and Scrum (Agile is a set of principles, Scrum is a methodology based on them). After all, is it really fair to demand conformity to the rules of a philosophy that embraces adaptiveness? Specifically, I refer to item 4 in the list of values called out in the Agile Manifesto:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

A better charge against those we think have misapplied Agile might be based on consistency and internal coherence. That is, item 1 logically puts some constraints on item 4. Adapting to a business situation by deciding to value process and tools over individuals can easily be said to violate the spirit of the values. As obvious as that seems, I’ve seen a lot of schedule-driven “Agile teams” bound to rigid, arbitrary coding standards imposed by a siloed QA person, struggling against the current toward a product concept that has never been near a customer. Steve Jobs showed that a successful Product Owner can sometimes insulate himself from real customers; but I doubt that approach is a good bet on average.

It’s probably also fair to call foul on those who “do Agile” without self-organizing teams and without pushing decision-making power down through an organization. Likewise, the manifesto tells us to build projects around highly motivated individuals and give them the environment and trust they need to get the job done. This means we need motivated developers worthy of trust who actually can the job done, i.e., first rate developers. Scrum is based on the notion of a highly qualified self-organizing, self-directed development team. But it’s often used by managers as an attempt to employ, organize, coordinate and direct an under-qualified team. Belief that Scrum can manage and make productive a low-skilled team is widespread. This isn’t the fault of Scrum or Agile but just the current marker of the enduring impulse to buy software developers by the pound.

But another side of this issue might yet point to a basic flaw in Agile. Excellent developers are hard to find. And with a team of excellent developers, any other methodology would work as well. Less competent and less experienced workers might find comfort in rules, thereby having little motivation or ability to respond to change (Agile value no. 4).

As a minor issues with Agile/Scrum, some of the terminology is unfortunate. Backlog traditionally has a negative connotation. Starting a project with backlog on day one might demotivate some. Sprint surely sounds a lot like pressure is being applied; no wonder backsliding scrum masters use it to schedule. Is Sprint a euphemism for death-march? And of all the sports imagery available, the rugby scrum seems inconsistent with Scrum methodology and Agile values. Would Scrum Servant change anything?

The idea of using a Scrum burn-down chart to “plan” (euphemism for schedule) might warrant a second look too. Scheduling by extrapolation may remove the stress from the scheduling activity; but it’s still highly inductive and the future rarely resembles the past. The final steps always take the longest; and guessing how much longer than average is called “estimating.” Can we reconcile any of this with Agile’s focus on being value-driven, not plan-driven? Project planning, after all, is one of the erroneous assumptions of software project management that gave rise to Agile.

Finally, I see a disconnect between the method of Scrum and the values of Agile. Scrum creates a perverse incentive for developers to continually define sprints that show smaller and smaller bits of functionality. Then a series of highly successful sprints, each yielding a workable product, only asymptotically approaches the Product Owner’s goal.

Are Agile’s days numbered, or is it a good mare needing a better jockey?




“People who enjoy meetings should not be in charge of anything.” – Thomas Sowell




The Road to Holacracy

In 1960 South Korea’s GDP per capita was at the level of the poorest of African and Asian nations. Four decades later, Korea ranked high in the G-20 major economies. Many factors including a US-assisted education system and a carefully-planned  export-oriented economic strategy made this possible. By some accounts the influence of Peter Drucker also played a key role, as attested by the prominent Korean businessman who changed his first name to “Mr. Drucker.” Unlike General Motors in the US, South Korean businesses embraced Drucker’s concept of the self-governing organization.

Drucker proposed this concept in The Future of Industrial Man and further developed it in his 1946 Concept of the Corporation, which GM’s CEO Alfred Sloan, despite Drucker’s general praise of GM, saw as a betrayal. Sloan would hear nothing flattened hierarchies and decentralization.

Drucker was shocked by Sloan’s reaction to his book. With the emergence of large corporations, Drucker saw autonomous teams and empowered employees who would assume managerial responsibilities as the ultimate efficiency booster. He sought to establish trust and “create meaning” for employees, seeing this as key to what we now call “engagement.”

In the 1960’s, Douglas McGregor of MIT used the term, Theory Y, to label the contrarian notion that democracy in the work force encourages workers to approach tasks without direct supervision, again leading to fuller engagement and higher productivity.

Neither GM nor any other big US firm welcomed self-management for the rest of the 20th century. It’s ideals may have sounded overly socialistic to CEOs of the cold war era. A few consultancies promoted related concepts like shop-floor autonomy, skepticism of bureaucracy, and focus on intrinsic employee rewards in the 1980’s, e.g., Peters and Waterman’s In Search of Excellence. Later poor performance by firms celebrated in Excellence (e.g. Wang and NCR) may have further discredited concepts like worker autonomy.

Recently, Daniel Pink’s popular Drive argued that self-management and worker autonomy lead to a sense of purpose and engagement, which motivate more than rank in a hierarchy and higher wages. Despite the cases made by these champions of flatter organizations, the approach that helped Korea become an economic power got few followers in the west.

In 2014 Zappos adopted holacracy, an organizational structure promoted by Brian J. Robertson, which is often called a flat organization. Following a big increase in turnover rate at Zappos, many concluded that holacracy left workers confused and, with no ladder to climb, flatly unmotivated. Tony Hsieh, Zappos’s CEO, denies that holacracy was the cause. Hsieh implemented holacracy because in his view, self-managed structures promote innovation while hierarchies stifle it; large companies tend to stagnate.

There’s a great deal of confusion about holacracy, and whether it in fact can accurately be called a flat structure. A closer look at holacracy helps clear this up.

To begin, note that itself states that work “is more structured with Holacracy than [with] conventional management.” Holacracy does not advocate a flat structure or a simple democracy. Authority, instead of being delegated, is instead granted to roles, potentially ephemeral, which are tied to specific tasks.

Much of the confusion around holacracy likely stems from Robertson’s articulation of its purpose and usage. His 2015 book, Holacracy: The New Management System for a Rapidly Changing World, is wordy and abstruse to the point of self-obfuscation. Its use of metaphors drawn from biology and natural processes suggest an envy for scientific status. There’s plenty of theory, with little evidential support. Robertson never mentions Drucker’s work on self-governance or his concept of management by objective. He never references Theory Y or John Case’s open-book management concept, Evan’s lattice structure, or any other relevant precedent for holacracy. Nor does he address any pre-existing argument against holacracy, e.g., Contingency Theory. But, a weak book doesn’t mean a weak concept.’s statement of principles is crisp, and will surely appeal to anyone who has done time in the lower tiers of a corporate hierarchy. Its envisions a corporate republic, rather than a pure democracy. I.e., authority is distributed across teams, and decisions are made locally at the lowest level possible. More importantly, the governance is based on a constitution, through which holacracy aims to curb tyranny of the majority and factionalism, and to ensure that everyone is bound to the same rule set.

Unfortunately, Holacracy’s constitution is bloated, arcane, and far too brittle to support the weight of a large corporation. Several times longer than the US constitution and laden with idiosyncratic usage of common terms, it reads like a California tax code authored by L Ron Hubbard. It also seems to be the work of a single author rather than a constitutional congress. But again, a weak implementation does not impugn the underlying principles. Further, we cannot blame the concept for its mischaracterization by an unmindful tech press as being a flat and structureless process.

Holacracy is right about the perils of both flat structures (inability to allocate resources, solve disputes, and formation of factions) and the faults of silos (demotivation, principal-agent problem, and oppressive managers). But with a dense and rigid constitution and a purely inward focus (no attention to customers) it is a flawed version 1.0 product. It, or something like it – perhaps without the superfluous neologism – will be needed to handle imminent workforce changes. We are facing an engagement crisis, with 80% of the millennial workforce reporting a sense of disengagement and inability to exploit their skills at work. Millennials, says the Pew Research Center, resist paying dues, expect more autonomy while being comfortable in teams, resent taking orders, and expect to make an impact. With productivity tied to worker engagement, and millennial engagement hinging on autonomy, empowerment and trust, some of the silos need to come down. A constitutional system embodying self-governance seems like a good place to start.


1 Comment

Can the Tech World Hack Intergenerational Learning?

In politically correct America, Intergenerational Learning has become a euphemism for teaching grandpa how to work his AOL account. I’m not talking about that.


In social animal species, there is evidence that it benefits a population to have lifespans far in excess of the age when individuals can reproduce. For non-social species, those of us past our sexual primes are just consuming valuable resources in a limited ecosystem. But we social animals tend to continue to add skills, memories and mental abilities to our libraries, which can then be transmitted to youngsters much more quickly than they could be acquired through experience. That’s the theory anyway. Try it on your teenager.

It seems to me that in the world of tech – particularly software – great opportunities exist for improved cross-generational learning. This is apparent in our history of programming languages and development tools. Much of my history with software involves the C language and its offspring. I’ll draw an example from that experience.

I’ve always had an uneasy relationship with C (I started with Fortran). C seemed in many ways to be the perfectly wrong combination of a high and low level language. Pointer math is indeed fun, but there is danger. In my aerospace days, I was able to get an exemption from the US Air Force on their requirement that certain C-17 avionics be programmed in a “high level” programming language such as C. I opted for Assembly instead, the reason being that Assembly compiled much smaller, allowing us to get everything on a single 87C196 Intel chip. I didn’t think that “high level” of C significantly reduced the risk of bugs that would sneak through functional testing. The Air Force bought it, and history bears me out.

But C proved to be a bit too “low level” for enterprise software development. Higher-level languages (easier to code) like PowerBuilder and Visual Basic (early 90s) and then Java and C# (early 2000s) greatly improved rapid software development while reducing the skill level required for coders to be productive. But not without impact. The C guys were on the street, along with their vast experience in good design. It is far easier to learn to code in high level languages than to design good software (what we call “architecture” in an era of terminological inflation).

Eventually, after gross cost overruns and some clumsy architecture, the new coders grew into their jobs, right about at the time when “social” became a noun and drove the creation of new software tools, database engines, and programming languages. Ruby and Python gave newbie coders a lot of rope. Maybe not enough to hang themselves, but enough to lock some large firms into maintenance-nightmare codebases that will keep on costing until they’re retired. Rapid shifts in technology that inadvertently discard tribal knowledge are well documented in other fields, e.g., energy and heavy manufacturing.

Portrait of a man holding portraits of his ancestors

We see an absence of cross-generational learning not only in programmers, but in those who create programming languages, tools, and development frameworks. VB’s syntax was a complete mess and its object orientation was an afterthought. Java cured all that, and we were glad to be done with VB’s type-promiscuity. But a generation later (in programmer years) Python repeated many of VB’s sins, along with being a scoping-rule disaster.

This problem in the world of software is exacerbated by cultural factors and the geek mystique. It extends beyond the technical realm. As Silicon Valley critic Vivek Wadhwa points out, the tech press and investors can’t get enough of the 20-year-old white male supergeek CEO myth. Incumbent in this myth is the notion that experience has negative value.

So how do we fix this? We can’t blame short-sighted downsizing and retirement for this loss of tribal knowledge. We seem to need broader knowledge, a dose of maturity or both. The problem is cultural, sociological or psychological; but the affected community is tech – not an area known for multidisciplinarity. How to fix it? Perhaps it will have to wait for the next generation. Maybe we can find some old farts who know how to do this.


Hack: withstand or manage (“I can’t just can’t hack that.”)
Hack: write code (e.g., TechCrunch NY 2013 Disrupt Hackathon)

, , ,


Management Initiatives and the Succession of Divine Generations

HerculesYesterday I commented on how corporate managers tend to move on to new, more fashionable approaches, independent of the value of current ones. I played around with using models from religious studies for understanding rivalry in Systems Thinking. Several good books interpret the rapid rise and decline of management initiatives and business improvement methods from the perspective of management-as-fashion. As with yesterday’s topic I think the metaphor of business mindset as religion also helps understand the phenomenon. In the spirit of multidisciplinary study, I’ll kick this around a bit.

The fad nature of strategic management initiatives and business process improvement methodologies has been studied in depth over the past two decades. Managers rapidly acquire strong interest in a new approach to improvements in productivity or competitiveness and embrace the methodology with enthusiasm and commitment. The recent explosion of tech/business hype on the web, consumed by small business as well as large, seems to increase frequency and amplitude of business fashions. Often before metrics can be established to assess effectiveness, enthusiasm declines and the team becomes restless. Eyes wander and someone hears of new, even-stronger magic. Another cycle begins – and is exploited by high-priced consultants ready to help you deploy the next big thing. Cameron and Quinn, in Diagnosing and Changing Organizational Culture give a truly dismal report card to nearly all organizational change initiatives.

Each successive cycle increases the potential for cynicism and resentment, particularly for those not at the top. Barry Staw and Lisa Epstein of UC Berkeley showed a decade ago that bandwagon application of the TQMS (Total Quality Management System) initiative in the 1990s did not correlate with increased profits, but correlated very well with decline of employee morale and increases in CEO compensation. Quite a few top managers were highly rewarded for spearheading TQM but retired with honors before TQM’s effect (or lack of it) was known.

TQM, Six Sigma, ISO9001
Google Ngram for TQM, ISO 9001 and Six Sigma over a 20-year period

The skepticism given TQM by many professionals was shown by a poster seen in many cubicles in those days. It contained a statement attributed to Petronius (incorrectly attributed to Petronius, probably derived from Robert Townsend’s Up the Organization!):

We trained hard but it seemed that every time we were beginning to form up into teams we would be reorganized. I was to learn later in life that we tend to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralization 

Having been a consultant in those days, I was painfully aware of what the TQMS and ISO 9001 fads had done for how consultants were viewed by hard-working employees. The last data I’ve seen on use of consultants in strategic initiatives (Peter Wood, 2002) showed that most firms used outsiders to justify and implement such programs. In the management-fashion metaphor, consultants are both the key fashion suppliers and its advertisers, skilled at detecting and exploiting burgeoning sales opportunities.

In a little over twenty years of working with large corporations, I got to witness many process, quality, and management initiatives:

Three of these stand out – Statistical Process Control and DFMA, because, in their most technical interpretation at least, they produced measurable results; and TQMS, because it was embraced with unparalleled gusto but flopped miserably. Despite the negative views of these initiatives in the ranks, I have little reason to find fault with them; they may have all been successful in due time with due commitment. In general, it was the initiatives’ frequency that demoralized, much more than the content. Today’s business fads are less intrusive and less about the organization. But that could change.

In the TQMS years I was at Douglas Aircraft in Long Beach, then rival of Boeing in Seattle. Douglas employees, both wary and weary of TQMS, read the acronym as “Time to Quit and Move to Seattle.”

As a religious parallel, I’m interested in the way ancient religions grew tired of their gods and invented new, oddly equivalent ones to replace them. At some point the Egyptians seemed to feel that Amun-Ra’s power had faded, though he had replaced the withered Nun. Isis and Osiris took Amun-Ra’s place. In the Greek world Asclepius and Hercules/Melkart replaced the Olympian gods. In Rome Mithras replaced Helios, both solar deities. Divine succession may have something to do with the eventual realization that the gods failed to do man’s bidding. The ancients were perhaps a bit more patient than modern business is.

In the 1990s, corporate messianic expectation surged. Religious parallels abound in the TQM literature, e.g., Robert J Bird’s observations on Transitory Collective Beliefs and the Dynamics of TQM Consulting, in which he quotes a Business Forum article stating that TQM “will change our lives as much as the advent of mass production”. The long, slow route of continuous improvement wasn’t yielding fast enough. Leaders looked to consulting firms in the sky to deliver immediate bottom line salvation. When it didn’t materialize, a new generation of humbler, more earthly gods emerged. Agile, Scrum, Targeted Innovation, and the seven habits of highly effective business secularists.

Closely related to messianic expectation is the concept of sacred scapegoats (see René Girard and Raymund Schwager). In ancient times, when a tribe grew impatient with their king or priest, they threw him into a sacrificial pit, imagining that his sins, their sins, and the current bad times would go along for the ride. A new king was chosen and hopes for renewal were celebrated. Our New Year’s Eve parties retain a hint of this motif. Kings got wise to this risk and introduced the practice of delegating a mock king for a day, selecting some hapless victim/king from the prison. The mock king was both venerated and condemned, then went down the well with the collective sins of the tribe. The real king survived to usher in the new year.

Applying this model to continuous improvement dynamics, it may be that there’s more than mere fashion to the speed with which we replace business methodologies. Their adoption and dismissal might simply be part of a stable process of coming to terms with unrealized goals, unreasonable as they might have been in the first place, and throwing them down the pit.


History does not repeat itself, but it does rhyme. – Mark Twain

, , , , ,

Leave a comment