Archive

Agility at Scale

Should We Adopt Agile?

Following on from my previous post concerning surfacing and reflecting on shared assumptions and beliefs about work, here are ten reflective questions for an executive considering flexible software development approaches:

  1. What are our priorities – speed, adaptability, innovation, quality, predictability? How should our processes align*?
  2. Do our teams thrive with more autonomy, or require structure from leadership?
  3. Are staff skills best leveraged through specialisation or multi-skilling and cross-functional collaboration?
  4. How much do we value rapid delivery versus long-term planning and building of long-term capabilities?
  5. Can our culture accept constant change versus needing firm commitments to e.g. delivery dates, feature sets, etc?
  6. Is our leadership comfortable ceding some control over how work gets done?
  7. Do our metrics reflect outcomes, outputs, value delivered, or needs met? Should we measure differently?
  8. Is transparency into work progress more valuable than formal milestones?
  9. Do we believe in Minimal Viable Products over Big Design Up Front?
  10. Are we open to new ideas or convinced our current ways of working work best? How much research have we done?

*I.E. What approach will best ensure our organisation’s processes, systems and structures are optimally configured to support our priorities and goals, around both software development and our wider business?

 

Note: Many more than these ten questions could be relevant to the headline topic. I encourage and invite you to try asking your favourite chatbot for more questions to consider.

Also note: Given the preponderance of proselytisation for the Agile approach currently found on the Internet, I would not recommend asking your chatbot “Should we adopt Agile?” directly. Unbiased and considered advice will NOT be forthcoming.

Agile Is The New Opiate Of The Masses

Over 160 years ago, Karl Marx famously declared religion to be the “opiate of the masses.” He believed faith’s promise of future redemption pacified oppressed workers to accept current suffering. Today, it is software methodology, not theology, dulling pain amidst dysfunction. Agile has become the new opiate of the masses.

New Religion

Like a new religion, Agile enchants followers with visions of empowerment, progress, and salvation. Its rituals claim to surface hidden dysfunction while promising to heal broken processes. Yet its addiction may be the deepest dysfunction of all.

New Blinders

Behind the rhetoric of transparency and adaptation lies a new set of blinders. Insisting myopically on timeboxed cycles cements local efficiencies while inhibiting long-term and system-wide change. Making work visible addresses symptoms not root causes. Embracing uncertainty masks risk and reactive thinking.

Velocity Displaces Validity

Like any local optimum, Agile optimisation constraints flexibility – “You can only make changes within the software development silo”.

Guided by output metrics not outcome objectives, velocity displaces validity and busyness disguises futility. By valorising action over purpose, standups and retros distract from the void at Agile’s core: why and to what end?

Dogmatic

The deepest irony is that a method premised on adaptation insists dogmatically upon iteration models, work crystallisation, and prescribed mindsets. In promising liberation, it imposes yet another rigid straighjacket. No prescribed framework fully grasps software’s complexities.

Summary

Might we better choose to dispense with the trappings, and orient to attending to needs, rather than process perfection? Might we choose to see method as a compass, not a map? Iterative delivery and feedback cycles can certainly guide teams. But when blindly systematised and followed slavishly, Agile risks making the “perfect” the enemy of the good enough. Behind grand sounding transformation lies mere pacification and opioid stupour. Before seeking reform through new methods, might we first get clear on folks’ needs?

The Appeal of SAFe

SAFe (Scaled Agile Framework) has become one of the most widespread scaling agile frameworks adopted by large companies and organisations. Despite numerous criticisms and many documented failures, its appeal continues to grow, with enterprises willing to invest massive sums in training and disruption to implement SAFe. This seems surprising given the minimal tangible benefits realised by most SAFe adherents.

So why does SAFe remain so appealing to large, complex bureaucracies? In a word: comfort. While marketed as a way to enable agility and leanness, SAFe appeals precisely because it does not challenge the status quo nor the entrenched beliefs held in many slow-moving, hierarchical organisations.

Criticisms of SAFe

To understand this dynamic, let’s first review common critiques levelled at SAFe:

  • Overly complex and prescriptive – SAFe has endless prescribed roles, processes, artefacts etc. This bureaucratic overhead hinders agility.
  • Hard to tailor – The intricate nature of SAFe makes customisation impractical. Organisations must reshape themselves to fit the framework.
  • Promotes “waterfall” thinking – The emphasis on upfront planning and budgets feeds an outdated sequential mindset rather than adaptiveness.
  • Reduces team autonomy – The multitude of coordination points, cadences and preset workflows leave little room for teams to self-organise.
  • Lots of overhead – The multi-layered structure requires innumerable meetings, planning sessions and documentation with little obvious value.
  • Focused on software – Challenging to integrate with hardware-based development.
  • Failure to change mindsets – By not focusing enough on culture and psychology, old ways of thinking persist.
  • Poor results for small teams – The coordination needs overwhelm lighter-weight groups.

And the big one:

  • Fails to deliver promised benefits – Despite claims around quality, speed, alignment etc., SAFe often delivers no measurable improvements.

Why So Appealing Then?

On the surface, we might be forgiven for thinking that these weaknesses would temper interest in what looks like an over-engineered, bureaucratic and exploitative approach. Yet SAFe resonates precisely because it neatly aligns with the innate orientation of lumbering enterprises.

Importantly, the traditional command-and-control assumptions underpinning these organisations are fundamentally incompatible with the collaborative dynamism essential for collaborative knowledge work (CKW) like software development. Still, decision-makers inevitably cling to what they know.

Organisational psychotherapy techniques can help transition teams to more adaptive behaviours, but this level of innovation is unknown to most executives.

Social Psychology

Instead, SAFe taps into the underlying psychology of social systems both enamoured by and resistant to change simultaneously. It allows decision-makers to signal adherence to “agile” thinking for PR purposes while actually fortifying traditional beliefs around command-and-control. It fosters the myth that adding scaffolding and rituals atop dysfunctional structures and ineffective ways of working can enable high-performance.

By wrapping waterfall-era assumptions in trendy Agile terminology yet never challenging obsolete ideas, SAFe holds tremendous appeal as it lets organisations feel as though they are evolving without actual introspection or change. For entrenched companies desperate for innovation yet terrified of losing control or certainty, SAFe’s contradictory promise proves irresistible. The disappointments come later. When admission thereto have become way to embarrasing to air.

ABC

Approaches like Agile for Big Companies (ABC – open sourced and in the public domain) aim to bridge this gap by enabling greater agility without upending incumbent structures and assumptions. Yet true transformation requires a willingness to surface and reflect upon long-held organisational axioms. For those unable or unwilling to fundamentally remake themselves, SAFe offers a tempting façade of progress.

Halleluya!

What’s the Agile Promise? A Closer Look

Agile frameworks have become somewhat of a buzzword, promising solutions to a variety of organisational challenges like cost overruns, time delays, and poor-quality products. But is there any real substance behind these promises? It’s high time we cut through the hype.

Cost Savings: A Mirage?

One of the most frequently touted benefits of Agile is the potential for cost savings. The idea is that by breaking projects down into smaller tasks and focusing on an MVP, costs can be better controlled. However, evidence suggests that Agile doesn’t actually provide any guaranteed cost advantages. In fact, poorly managed Agile can result in escalating costs.

Does Agile Fix Time Management Issues?

Agile methods like Scrum advocate for time-boxed sprints and quick iterations, ostensibly to help teams manage time better. But let’s be clear: Agile does nothing to inherently solve time overruns. Teams can still fail to deliver on time, despite using Agile practices.

Is Quality Really Assured?

Though Agile methods involve constant testing and feedback loops, these practices don’t guarantee improved quality. The responsibility for quality lies in the hands of those implementing the practices, and there are plenty of cases where Agile projects have resulted in subpar products.

Does Agile Alleviate Managerial Stress?

Contrary to popular belief, Agile doesn’t make life easier for managers. The need for continuous oversight, frequent meetings, and quick decision-making often adds to managerial stress rather than alleviating it.

Where’s the Critical Evaluation?

Many organisations jump onto the Agile bandwagon without giving it adequate thought. What’s missing is a critical evaluation of whether Agile practices actually offer any benefits, be they operational or financial.

Any Real Business Benefits?

Now for the most provocative yet necessary point: Agile offers no tangible business benefits. Despite its focus on iterative processes and development, Agile practices don’t translate into increased revenue, market share, or customer satisfaction. If anything, they add layers of complexity that often have no direct business value.

Might We Deprogram Ourselves of Our Blind Faith?

The pervasive but misguided belief in Agile as a universal solution for organisational issues invites reconsideration. Contrary to its zealous promotion, Agile has no intrinsic merits that guarantee better business outcomes. Organisations might choose to drop the rose-coloured glasses and critically evaluate whether Agile brings anything to the table at all.

Why Not Managers?

The Managerial Role: Obsolete

Traditionally, managers serve as overseers, ensuring work flows smoothly and deadlines meet their marks. But in today’s business environments, we’re seeing a seismic shift. Teams are self-organising and making decisions independently. Why do we still need managers?

Do Teams Manage Themselves?

The answer seems to lean towards ‘yes’, teams can and do “manage” themselves. In settings where productivity is of the essence, the emphasis is on empowering teams to solve problems and innovate without having a managerial figure present, breathing down their necks. Collective ownership becomes the mantra, and everyone takes responsibility for the product’s success or failure.

What Happens to Accountability?

Contrary to popular belief, the absence of a traditional managerial role doesn’t mean accountability vanishes. In fact, team members often feel more accountable to each other than they might to a distant or toxic boss. Review processes become more meaningful, as peers understand the challenges and intricacies of the tasks at hand.

Is Decision-Making More Efficient?

The chain of command usually slows down decision-making. In a manager-less environment, teams arrive at decisions more quickly and can adapt to changes or unexpected challenges without having to wait for managerial approval. This can be especially vital in the fast-paced world of software development. See also: Auftragstaktik.

Does Quality Suffer?

One concern is that without a managerial figure to enforce standards, quality might slip. However, evidence suggests that the opposite happens. A sense of ownership and peer review often leads to a higher standard of work. Team members become each other’s quality control, leading to a more cohesive and well-executed end product. See also: Ensemble development.

What’s the Role of Leadership?

Leadership doesn’t evaporate in the absence of managers; it merely takes a different form. Leaders emerge naturally, guided by their expertise, communication skills, context, and the team’s respect. These leaders are often more in tune with the needs and dynamics of the team, making for a more harmonious and productive work environment.

Is This Model for Every Business?

The manager-less model isn’t just a passing fad in the software development world; it raises legitimate questions about the universal need for managers across all business types. While some argue that industries with stringent regulatory compliance or high-volume customer interactions need a managerial structure, this reasoning often serves as a convenient crutch rather than a real justification.

Firstly, regulatory compliance doesn’t inherently require a managerial role. Businesses can still adhere to laws and regulations through well-documented processes and collective responsibility. Teams can be educated and empowered to include regulators in the set of Folks That Matter™ and comply with rules without a manager acting as the gatekeeper.

Secondly, the idea that customer service businesses benefit from managerial roles is also questionable. Frontline employees are more likely to understand the intricacies and nuances of customer interactions than a removed managerial figure. Empowered teams often show better problem-solving capabilities, which is beneficial in handling complex customer concerns.

So, are managers necessary? The evidence increasingly points to ‘no’. Even outside the tech sector, rethinking the need for managers can lead to more agile, responsive, and accountable businesses.

So, Are Managers Redundant?

In the context of modern software development and certain types of businesses, managers are increasingly looking like relics of a past era. For businesses willing to take the leap, a manager-less structure offers more than just cost savings; it paves the way for innovation, efficiency, and a far more engaged workforce.

Further Reading

Zanini, M. (2021). Can we manage without managers? Retrieved on 9 September 2023 from https://www.michelezanini.com/can-we-manage-without-managers/
Zanini, M. (2014). Companies without managers better every metric. Retrieved on 9 September 2023 from https://www.cobrt-archive.com/archived-blog/2014/08/companies-without-managers-better-every-metric/

Agile Unmasked: The Ethical Sewer of Mendacious Gullibility

Unveiling the Emperor: Agile’s Non-Existent Clothes

If Agile were a bottle of snake oil peddled by a slick, moustachioed charlatan, would you still buy it? This provocative question necessitates confronting the uncomfortable fact that Agile, the beloved darling of software development, has no merits to speak of. In this exposé, we’ll look at the concept of “mendacious gullibility” through the lens of William Kingdon Clifford’s “The Ethics of Belief,” to probe why Agile has garnered such uncritical and unworthy adoration.

Note: Here, we’re talking about Agile as it commonly manifests in software development. Pursuit of agility across a whole organisation is a different kettle of fish. Cf. ABC and agility at scale.

Unpacking Mendacious Gullibility

Mendacious gullibility is a state of wilful self-deception, where the desire to believe is so strong that it eclipses the moral obligation to scrutinise. According to Clifford, beliefs without a sturdy foundation of evidence are not merely misguided, but ethically unsound. When applied to Agile, this means that adopting the concept, and practices, without critical analysis is not only ineffective but morally dubious.

Agile’s Hollow Promises: A Critical Dissection

Agile promises adaptability, collaboration, and speed. Yet, if we’re honest, these promises often fall flat. Efforts don’t necessarily become more efficient, nor do teams always feel more empowered. So, why does the belief persist that Agile is beneficial? The answer likely lies in mendacious gullibility—a collective suspension of critical thinking encouraged by self-interest, catchy jargon and snake oil testimonials.

The Real-World Consequences: Beyond Failed Efforts

The impact of this self-serving self-deception is not restricted to resources and timelines; it penetrates the ethical core of an organisation. Team morale can suffer, trust in leadership may erode, and the overall health of the business could be jeopardised. The price of mendacious gullibility is not just operational but deeply ethical.

Debunking the Agile Myth: An Ethical Imperative

For those who care about ethical governance and responsible leadership, the requirement is clear: Agile must be critically evaluated and, when found wanting, discarded.

  • Demand hard evidence rather than relying on industry buzz.
  • Challenge the proponents of Agile to provide substantive proof of its applicability.
  • Be willing to consider alternatives that may not have Agile’s glamour but offer evidence-based effectiveness.

In Closing: The Moral Duty to Question

If Clifford’s “The Ethics of Belief” serves as any guide, we must confront the disturbing idea that Agile’s universal adoption might be a manifestation of mendacious gullibility. It’s not simply that Agile is inappropriate for certain efforts; it is that Agile is fundamentally flawed, with no redeeming merits beyond its ability to lever open the wallets of the naively gullible.

Moral integrity demands more than self-deluding acceptance. As we navigate the labyrinth of methods and best practices, how about we commit to an ethical approach that values evidence over hype. And when it comes to Agile, it’s time we stop drinking the Kool-Aid.

The Fallacy of Measuring Developer Productivity: McKinsey’s Misguided Metrics

At least the execrable, and totally misinformed, recent McKinsey article “Yes, you can measure software developer productivity” has us all talking about “developer productivity”. Not that that’s a useful topic for discussion, btw – see “The Systemic Nature of Productivity”, below. Even talking about “development productivity” i.e., of the whole development department would have systems thinkers like Goldratt spinning in his grave.

The Systemic Nature of Productivity

Productivity doesn’t exist in a vacuum; it’s a manifestation of the system in which work occurs. This perspective aligns with W. Edwards Deming’s principle that 95% of the performance of an organisation is attributable to the system, and only 5% to the individual. McKinsey’s article, advocating for specific metrics to measure software developer productivity, overlooks this critical context, invalidating its recommendations from the outset.

Why McKinsey’s Metrics Miss the Mark

Quantitative Tunnel Vision

McKinsey’s emphasis on metrics ignores the complex web of factors that actually contribute to productivity. This narrow focus can lead to counterproductive behaviours.

The Dangers of Misalignment

Metrics should align with what truly matters in software development. By prioritising the wrong metrics, McKinsey’s approach risks incentivising behaviours that don’t necessarily add value to the project or align with organisational goals.

Predicated on Fallacies

McKinsey’s suggestions are riddled with fallacious assumptions, including:

  • Benchmarking – long discredited.
  • Contribution Analysis – focused on individuals. Music to the ears of traditional management but oh so wrong-headed.
  • Talent – See, for example,  Demings 95/5 for the whole fallacious belief in “talent” as a concept.
  • Measuring productivity (measure it, and productivity will go down).

The Real Measure: Needs Attended To and Needs Met

The Essence of Software Development

The core purpose of business – and thus of software development – is to meet stakeholders’ needs. Therefore, have the most relevant metrics centre on these factors: How many stakeholders’ needs have been identified? How many have been and are being attended-to? How many have been successfully met? These metrics encapsulate the real value generated by a development team – as an integrated part of the business as a whole. (See also: The Needsscape).

Beyond the Code

Evaluating how well needs are attended to and met requires a focused approach. It includes understanding stakeholders’ requirements, effective collaboration within and across teams and departments, and the delivery of functional, useful solutions. (Maybe not even software – see: #NoSoftware).

Deming’s 95/5 Principle: The Elephant in the Room

The System Sets the Stage

Ignoring the role of the system in productivity is like discussing climate change without mentioning the Sun. Deming’s 95/5 principle suggests that if you want to change productivity, you need to focus on improving the system, not measuring individuals, or even teams, within it.

The Limitations of Non-Systemic Metrics

Individual metrics are the 5% of the iceberg above the water; the system—the culture, processes, and tools that comprise the working environment—is the 95% below. To truly understand productivity, we need metrics that evaluate the system as a whole, not just the tip of the iceberg. And the impact of the work (needs met), not the inputs, outputs or even outcomes.

The Overlooked Contrast: Collaborative Knowledge Work vs Traditional Work

McKinsey’s article advocates for yet more Management Monstrosities, where the category error of seeing CKW – collaborative knowledge work – as indistinct from traditional models of work, persists.

The Nature of the Work

Traditional work often involves repetitive, clearly defined tasks that lend themselves to straightforward metrics and assessments. Think of manufacturing jobs, where the number of units produced per time period or per resources committed can be a direct measure of productivity. Collaborative knowledge work, prevalent in fields like software development, is fundamentally different. It involves complex problem-solving, creativity, and the generation of new ideas, often requiring deep collaboration among team members.

Metrics Fall Short

The metrics that work well for traditional jobs are ill-suited for collaborative knowledge work. In software development, such metrics can be misleading. The real value lies in innovation, problem-solving, and above all meeting stakeholders’ needs.

The Role of Team Dynamics

In traditional work settings, an individual often has a clear, isolated set of responsibilities. In contrast, collaborative knowledge work is highly interdependent. This complexity makes individual performance metrics not just inadequate but potentially damaging, as they can undermine the collaborative ethos needed for the team to succeed.

The Importance of Systemic Factors

The system in which work takes place plays a more significant role in collaborative knowledge work than in traditional roles. Factors like communication channels, decision-making processes, and company culture (shared assumptions and beliefs) can profoundly impact productivity. This aligns with Deming’s 95/5 principle, reinforcing the need for a systemic view of productivity.

Beyond Output: The Value of Intellectual Contributions

Collaborative knowledge work often results in intangible assets like intellectual property, improved ways of working, or enhanced team capabilities. These don’t lend themselves to simple metrics like ‘units produced’ but are critical for long-term success. Ignoring these factors, as traditional productivity metrics tend to do, gives an incomplete and potentially misleading picture of productivity.

A Paradigm Shift is Needed

The nature of collaborative knowledge work demands a different lens through which to evaluate productivity. A shift away from traditional metrics towards more needs-based measures is necessary to accurately capture productivity in modern work environments.

Quality and Productivity: Two Sides of the Same Coin

The Inextricable Link

Discussing productivity in isolation misses a crucial aspect of software development: quality. Quality doesn’t just co-exist with productivity; it fundamentally informs it. High-quality work means less rework, fewer bugs, and, ultimately, a quicker and more effective delivery-to-market approach.

Misguided Metrics Undermine Quality

When metrics focus solely on outputs they can inadvertently undermine quality. For example, rushing to complete tasks can lead to poor design choices, technical debt, and an increase in bugs, which will require more time to fix later on. This creates a false sense of productivity while compromising quality.

Quality as a Measure of User Needs Met

If we accept that the ultimate metric for productivity is “needs met,” then quality becomes a key component of that equation. Meeting a user’s needs doesn’t just mean delivering a feature quickly; it means delivering a feature that works reliably, is easy to use, and solves the user’s problem effectively. In other words, quality is a precondition for truly meeting needs.

A Systemic Approach to Quality and Productivity

Returning to Deming’s 95/5 principle, both quality and productivity are largely influenced by the system in which developers work. A system that prioritises quality will naturally lead to higher productivity, as fewer resources are wasted on fixing errors or making revisions. By the same token, systemic issues that hinder quality will have a deleterious effect on productivity.

Summary: A Call for Better Metrics

Metrics aren’t the problem; it’s the choice of metrics that McKinsey advocates that demands reconsideration. By focusing on “needs attended to” and “needs met,” and by acknowledging the vital role of the system, organisations can develop a more accurate, meaningful understanding of holistic productivity, and the role of software development therein.Let’s avoid the honey trap of measuring what’s easy to measure, rather than what matters.

Afterword

As with so much of McKinsey’s tripe, the headline contains a grain of truth – “Yes, you can measure software developer productivity”. But the nitty-gritty of the article is just so much toxic misinformation. Many managers will seize on it anyway. Caveat emptor!

The Orwellian Agile Community

Agile development has promised to be the panacea for a host of problems that software development teams face. Yet it has devolved into approaches characterised by rigidity, misinformation, and top-down control. As we navigate the murky waters of agile adoptions, and Scrum, Kanban, etc. implementations, two Orwellian statements echo and reverberate:

  1. “The further society drifts from truth, the more it will hate those who speak it.” (Widely attributed to George Orwell, although its direct origin is debated)
  2. “The past was erased, the erasure was forgotten, the lie became the truth.” (From Orwell’s “1984”)

These quotes invite us to pause and reflect on some of the deeply rooted issues within the agile community.

Drifting from Truth

As agile approached take the corporate world by storm, we’ve seen the predominance of ‘agile theatre’. This is where the word ‘agile’ is on everyone’s lips, but its principles aren’t in their actions. Teams may host daily stand-ups or retrospective meetings, yet fail to embrace a culture of openness and adaptability.

So, what happens when someone calls out these inconsistencies? Often, they’re sidelined or labelled as ‘not a team player’. This mirrors the sentiment of the first Orwell quote: the further the agile community drifts from the core agile tenets of transparency, inspection, and adaptation, the less it appreciates individuals who remind it of its original values and goals.

Note: While this quote is widely attributed to Orwell, its direct origins are a subject of debate.

Erasing the Past, Embracing the Lie

Agile practices have also seen shifts that compromise their foundational principles. For instance, “being agile” now often means “doing Scrum” or “implementing Kanban”, with little regard for the contextual needs of an organisation. Past failures are conveniently forgotten, and the cycle of ‘new agile initiatives’ is continuously rebooted, with no one daring to question the perpetual loop of erasure and overwriting.

This phenomenon resonates with the second Orwellian statement. We erase our past failures and adapt convenient narratives. The lie—that we’re fully agile—becomes our truth.

Will There Ever be an Agile Reckoning?

Is it time we revisit the principles that make agile a truly transformative approach? Rather than ostracising those who call out our flaws, might we choose to view them as allies in refining our approach? And instead of erasing our failures, might we choose to inspect and adapt, using them as valuable lessons?

In a world where the ‘Agile Industrial Complex’ has all but erased the ideals of the original Agile Manifesto, taking a leaf out of Orwell’s books might be our best hope to navigate through the fog. And remember, just like in Orwell’s world, the pursuit of truth starts with critical thinking and the courage to challenge prevailing narratives

The Software Crisis: A 50+ Year Conundrum Waiting for a Paradigm Shift

When the term “Software Crisis” was coined in the late 1960s, the software industry was grappling with issues of complexity, reliability, and maintainability. The rate at which technology was evolving seemed to outpace the ability to efficiently and effectively manage software projects. Yet, half a century later, we still find ourselves confronting the same challenges.

The Persistent Nature of the Crisis

Most industries undergo evolutionary shifts, which often transform the landscape and resolve the challenges of the past. However, the software domain remains an anomaly. Instead of outgrowing its initial issues, we find them compounded by the enormous scale and scope of contemporary software development. Despite more advanced tools and platforms, software bugs, project overruns, and scalability issues remain pertinent.

So, why is the software crisis still with us?

The Inherent Complexity of Software

Software is, in essence, abstract and malleable. Unlike constructing a building or manufacturing a car, where there’s a tangible product, software development involves attending to folks’ needs through weaving intricate patterns of logic. As the Needsscape evolves, it becomes increasingly challenging to untangle and reweave the strands.

Furthermore, software isn’t limited by physical laws. While you can keep adding lines of code, each new line tends to increase complexity in a non-linear fashion.(See also: #NoSoftware)

The Economic Incentives

There’s an underlying economic motive to maintain the status quo. Major software corporations, consultancy agencies, educational establishments, and even management gain from the ongoing software crisis.

  • Software Companies: Continuous updates, patches, and new releases mean ongoing revenue. “Perfect”, bug-free software from the outset would reduce the push for upgrades and extended support.
  • Consultancy Firms: A continuing crisis ensures a constant demand for experts to guide, integrate, and sustain various approaches. (Ever seen consultants hired to obviate the Software Crisis?).
  • Educational Institutions: The ever-evolving landscape necessitates continuous learning, translating to enrollment in courses, certifications, and further studies.
  • Management: The status quo often validates management hierarchies and roles. Shaking up the software development paradigm challenges established management statuses and command & control dynamics, which many in management roles find unsettling. Where’s the leadership??

The Need for a New Paradigm

While we’ve seen enhancements in methods and technologies, they don’t directly tackle the root causes of the software crisis. A paradigm shift is essential, but what should it emphasise?

  • People: Centralide the role of people in the software process. Recognise that while tools and technologies are marginally relevant, it’s people and teams who breathe life into software. We might choose to prioritise their well-being, motivation, and skills.
  • Relationships: Emphasise collaboration and communication. Siloed teams and heroic individuals exacerbate challenges. Cross-functional cooperation and fostering an environment where diverse perspectives converge can lead to better solutions.
  • Collective Assumptions and Beliefs: Challenge and revisit the shared beliefs and assumptions in the organisation. Often, outdated paradigms persist because they go unquestioned. By reassessing and updating these, we can pave the way for innovative approaches.

#Quintessence

The enduring software crisis mirrors the challenges inherent in software development and the economic frameworks that have crystallized around it. While vested interests might resist change, history reminds us that transformation is both inevitable and necessary. When the software industry finally experiences its paradigm shift, it will not only resolve its longstanding crisis but also unleash unprecedented avenues for innovation.

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/quintessence/ [Accessed 18 August 2023].

The Human Element

In today’s world of rapid technological evolution and market fluctuations, achieving agility at scale has become a prime objective for many organisations. Conventionally, discussions around “agility” gravitate towards processes, technical practices, and organisational structures. However, could it be that we’re missing the crux of the issue? What if the true secret to achieving agility at scale isn’t about the technicalities or structures at all, but rather, psychology and group dynamics?

The Human Element

Every organisation is made up of people. These people, with their diverse backgrounds, experiences, motivations, and fears, come together to form a collective entity. The interplay of these psychological factors and group dynamics becomes the pulse of the organisation.

When we talk about agility, we’re essentially discussing adaptability – the capability to change course quickly in response to new information, challenges, or opportunities. This adaptability isn’t derived from tools or processes; it’s nurtured by the collective mindset of the organisation’s members.

Key Psychological and Group Dynamics Factors

  1. Group Norms and Culture: The implicit rules, assumptions and beliefs that guide behaviour in a group can either promote or hinder collaboration. Most often, especially in big companies, such shared assumptions and beliefs hinder. A culture that values inclusivity, respect, and mutual support will likely facilitate better collaborative outcomes.
  2. Trust: One of the foundational pillars of agility is trust. In an environment where team members trust each other, the flow of information is more fluid. People are more willing to share bad news early or provide candid feedback, which aids quick course correction.
  3. Safety to Fail: Agility thrives in environments where individuals are not penalised for making mistakes, but rather encouraged to learn from them. The psychology of safe environments promotes experimentation, innovation, and risk-taking – all critical for agility.
  4. Shared Vision and Purpose: When a group has a shared vision and understands the ‘why’ behind their actions, decision-making is streamlined. A shared purpose psychologically aligns individuals, inviting them to be more proactive and collaborative.
  5. Open Communication: The flow of information and feedback loops are crucial for agility. When team members feel they can communicate openly, without fear of repercussion, they are more likely to address issues promptly, paving the way for adaptive responses.
  6. Inclusion and Diversity: A diverse team brings in multiple perspectives. The varied viewpoints and cognitive approaches play a crucial role in ensuring that the team doesn’t become myopic and can adapt to a wide array of challenges.

So, Why Do We Often Overlook The Human Element?

Organisational structures and technical practices are tangible. They can be drawn on charts, implemented through software, or outlined in manuals. It’s easy to gravitate towards what’s tangible and measurable. Psychological factors and group dynamics, on the other hand, are less tangible, making them harder to define, see, measure, and manage.

Moreover, investing in the ‘soft’ aspects of organisational culture doesn’t always show immediate ROI. It requires patience, consistent effort, and commitment.

And most initiatives to deliver Agility at Scale are facilitated by left-brained engineering and software folks whose understanding of people, psychology, and group dynamics is, to be charitable, limited.

The Way Forward

While it’s essential to have effective technical practices and suitable organisational structures in place, we might choose to recognise that they are but tools in the hands of people. For an organisation to achieve true agility at scale, it must prioritise the psychological well-being and leverage healthy group dynamics among its members.

I invite you to shift your focus from the tangible to the intangible, from the external to the internal. Only by understanding and nurturing the human elements can organisations unlock unprecedented levels of agility, innovation, and success.

The ABC Difference

ABC (Agility for Big Companies) takes this message to heart. Implementing ABC means paying attention first and foremost to the psychology and groups dynamics of the organisation. From this foundation, effective technical practices and suitable organisational structures emerge. ABC avoids having the tail wag the Agility at Scale dog.

Credibility and Trust in Business Change: A Climate Change Analogy

In the evolving landscape of business change and culture transformation, a new dimension is emerging that calls out for our attention: the importance of credibility and trust. Often, we tend to regard facts and evidence as the cornerstones of decision-making. But often, credibility and trust hold more weight. To understand why, let’s take a closer look at the parallels between this business phenomenon and the world’s approach to climate change and climate denial.

Climate Change: A Global Phenomenon

Climate change has become an undeniable reality, with a multitude of facts, evidence, and scientific data pointing towards the rapid alteration of our planet’s environment. However, the denial of climate change still persists.

Why?

The reason is, facts alone are not enough. Credibility and trust play a vital role in influencing public opinion. The world’s best climate scientists may have the data, but if the public doesn’t trust them or find them credible, the facts become meaningless. Similarly, in the business world, even the most well-documented approaches and tools can falter if credibility and trust are missing.

Trust and Credibility in Business Change

  1. Building Relationships: In both climate change and business transformation, building relationships is key. Just as climate scientists must engage with policymakers and the public, businesses must foster relationships with the Folks That Matter™ to gain trust and build credibility.
  2. Communication is Key: The language and way facts are presented can often make or break the trust. In climate discussions, complex data needs to be conveyed in an accessible manner. In business, the organisation must communicate changes in a way that resonates with employees at all levels.
  3. Transparency and Honesty: Transparency in sharing information, even when it’s uncomfortable, builds credibility. In the same way, climate scientists being open about uncertainties helps in building trust. Businesses must also be open and honest about the reasons for change and the potential challenges ahead.
  4. Influence and Influencers: Trusted influencers have the power to shape opinions. Just as influential figures can change the narrative around climate change, strong influencers in a business can promote a culture that embraces change.
  5. Long-term Vision: Both combating climate change and executing successful business transformations require a long-term vision. The focus on immediate profits or short-term gains can lead to the erosion of trust and credibility.

Conclusion

The connection between climate change and business transformation offers a rich perspective on the intricate dynamics of trust and credibility. Both contexts teach us that facts and evidence, while necessary, are not sufficient.

The lesson for businesses is clear: to effect successful change, they might choose to focus on building trust and credibility as much as, if not more than, gathering facts and evidence. The road to change, be it in our global climate or corporate culture, is a journey of building faith, trust, and relationships. Just as with climate change, it’s a path that requires honesty, clarity, and above all, credibility.

How to Build an Auftragstaktik Business Team

The term “Auftragstaktik,” German for “mission command,” emphasises decentralised command, individual initiative, and flexibility. Adopted by the Prussian Army in 1806 and the United States Marine Corps in the 1980s, the principles behind Auftragstaktik have now been translated to the business world. Let’s explore how these principles can be used to create an agile and responsive business team.

A Brief History of Auftragstaktik in Military Context

The Prussian Model

Generals Gerhard von Scharnhorst, Helmuth von Moltke the Elder, and Karl von Clausewitz championed Auftragstaktik in the 19th century. This strategy empowered junior officers to make decisions on the spot, allowing for quick adaptation to changing battlefield conditions. The Prussian victory in the Franco-Prussian War (1870-1871) is often attributed to this approach.

USMC Adoption

The US Marine Corps embraced Auftragstaktik during the development of Maneuver Warfare in the latter half of the 20th century. Recognising the importance of adaptability, initiative, and decentralisation of decisions-making, the USMC has effectively implemented these principles in complex military operations.

Key Principles and Their Application in Business

1. Decentralised Command

Military Context: Leaders provide objectives and resources, allowing subordinates to devise their own approaches.

Business Application: Similar to software development, businesses define overall goals and essential parameters, then trust teams and their members to decide the best way to achieve the objectives.

Example: Spotify’s “squads” system encourages teams to find innovative ways to meet company goals, fostering creativity and ownership.

2. Individual Initiative

Military Context: Lower-ranking officers and soldiers take the initiative to adapt to changes.

Business Application: Team members are empowered to make decisions and act independently.

Example: 3M’s policy allowing employees to work on personal projects – originating 1948 – has spurred innovations such as the Post-it Note.

3. Flexibility and Adaptation

Military Context: Adaptation to unexpected changes is vital on the battlefield.

Business Application: Successful businesses must pivot and adapt to new market conditions, requirements, or technologies.

Example: Netflix’s transformation from DVD rentals to streaming shows its ability to adapt swiftly to industry changes.

4. Clear Communication and Understanding

Military Context: Communicating the commander’s intent is crucial.

Business Application: Clear communication of intent, goals, and constraints ensures alignment and collaboration within teams.

Example: Zappos implements a “Holacracy” system, clarifying roles and responsibilities.

5. Trust and Collaboration

Military Context: Trust between commanders and subordinates is key.

Business Application: Trust between management and teams enables collaboration and innovation.

Example: Southwest Airlines fosters trust, leading to high employee satisfaction and customer loyalty.

Conclusion

Building an Auftragstaktik team in business requires adopting principles such as decentralized command, individual initiative, flexibility, clear communication, and trust. These principles can help business teams become more responsive, innovative, and resilient.

Real-world examples from companies like Spotify, 3M, Netflix, Zappos, and Southwest Airlines showcase how the lessons learned from the Prussian and USMC military’s adoption of Auftragstaktik can create effective business teams. This approach offers a valuable roadmap for today’s dynamic business landscape, equipping teams with the agility at scale to navigate the complexities of modern markets.

The Mountain Goat Principle in Agility at Scale Adoptions

Agility at scale is designed to help organisations respond to the unpredictable nature of today’s business environment. One such approach, the Mountain Goat Principle, takes inspiration from the agility and adaptability of mountain goats, providing insights that can be applied to agility at scale adoptions.

The Mountain Goat Principle is part of Tom Gilb’s methods for evolutionary (Evo) project management. It involves incremental development, rapid adaptation, and constant reassessment of goals, just as mountain goats skillfully navigate challenging terrains.

The Mountain Goat Principle Explained

Mountain goats are known for their ability to climb steep, rugged terrains with grace and precision. This extraordinary skill is the result of their continuous adaptation, ability to assess risks, and immediate response to changes in the environment.

Tom Gilb applied these characteristics to project management, where he proposed an approach of incremental development, focusing on delivering the most valuable increments first. Like the mountain goat’s step-by-step approach, the Mountain Goat Principle encourages tackling a project in smaller, more manageable increments and adapting quickly to any changes or obstacles. And maybe pausing from time to time to evaluate the best path forward.

Applying the Mountain Goat Principle to Agility at Scale

1. Incremental Development

At a larger scale, applying the Mountain Goat Principle means breaking down complex organisational projects into smaller, more manageable parts. By focusing on delivering the most crucial increments first, organisations can achieve greater adaptability and respond swiftly to changes.

2. Constant Assessment and Adaptation

Just as mountain goats continuously assess their terrain, organisations must constantly evaluate their progress and adapt as needed. This involves regular monitoring, feedback, and fine-tuning to ensure alignment with business objectives.

3. Risk Management

Mountain goats expertly navigate risks by assessing and responding to their surroundings. Similarly, organisations may choose to identify potential risks and develop strategies to mitigate them. This proactive approach to risk management enables a more resilient and responsive organisation, with less risk of catastrophic failure.

4. Collaboration and Communication

Mountain goats often travel in groups and rely on social cues to navigate their environment. Organisations adopting the Mountain Goat Principle might choose foster a collaborative culture where communication is encouraged, and insights are shared across the organisation.

5. Emphasizing Value

By focusing on the most valuable increments, organisations can deliver high-impact results early in the project. This value-driven approach promotes efficiency and ensures that the most critical objectives take priority..

Conclusion

The Mountain Goat Principle offers a unique perspective on agility at scale, emphasising incremental development, adaptation, risk management, collaboration, and value delivery. By applying these principles, organisations can navigate the complex and often unpredictable business needsscapes with grace and effectiveness, just like the agile mountain goats navigating their rugged landscapes.

In a world where change is the only constant, the Mountain Goat Principle provides an inspiring and practical guide to embracing agility at scale. It encourages us to learn from nature, take calculated risks, and adapt continuously to thrive in the face of uncertainty and bewildering choice.

ABC White Papers – #1 Adoption

ABC, short for Agility for Big Companies, is all about helping big companies stay quick on their feet and adapt to changes fast. In the ABC set of white papers, the first of which features in this post, we’ll explore what ABC is, how it works, and why its open source model is a breath of fresh air in the Agility at Scale space.

ABC White Paper 1 – Adoption

Adopting ABC: The Agility for Big Companies Approach to Enterprise Agility

Introduction

Achieving enterprise agility is a high priority for many organisations today. While the Agile model has some effectiveness in small teams, scaling agility across large organisations poses unique challenges. Agility for Big Companies (ABC) offers a tailor-made approach to addressing these complexities and helps big companies harness the benefits of enterprise agility.

The Challenge of Scaling Agility in Large Enterprises

Large enterprises face various hurdles in adopting agility at scale. The difficulties include: managing the cultural shift, aligning various teams, and maintaining coordination across geographically dispersed groups. Balancing the agility of small teams with the need for oversight and control also presents a significant challenge.

The ABC Solution

ABC offers an elegant solution that simplifies adopting agility at scale and adapts the principles of agility to suit the unique needs of big companies. It emphasises:

  1. Easy Adoption: ABC provides a structured, AI-assisted approach that simplifies the adoption process. Recognising that change in big companies can often be complex and daunting, ABC has been expressly developed to make this transition as seamless as possible. By offering clear, practical guidelines and roadmaps, ABC reduces uncertainties, instils confidence, and minimises resistance to the new approaches. Its carefully crafted processes ensure that every stakeholder understands their role in this transformation, enabling them to contribute effectively and align with the agility at scale vision.
  2. Enhanced Flow and Continuity: ABC places a high emphasis on maintaining a continuous flow of work. By streamlining operations and breaking down silos, ABC facilitates the smooth progression of tasks across an ever-decreasing number of different teams and departments. This systematic approach minimises interruptions, reduces bottlenecks, and promotes a constant rhythm of productivity. It ensures that all elements of the organisation are working harmoniously towards the same objectives, thereby maximising output and promoting efficiency. With ABC, organisations can achieve a steady, unobstructed workflow that underpins their success.
  3. Respecting the Status Quo: ABC respects existing organisational structures and cultures, recognising their unique value and the stability they provide. Instead of recommending radical, disruptive changes, ABC encourages a gradual, inclusive transition that blends the new with the existing. It considers your organisation’s unique characteristics and balances them with modern practices. This approach eases the transition, minimises culture shock, and fosters an environment of respect and understanding, resulting in higher acceptance and less resistance.
  4. Consensus and the Advice Process: ABC promotes a collaborative decision-making process that values every team member’s input. This approach recognises the importance of collective intelligence and diverse perspectives in forging a path forward. The advice process, an integral part of ABC, is a tool that seeks suggestions and insights from everyone involved, thereby building consensus. This method not only ensures the best decisions are made but also enhances commitment and alignment, as each team member feels heard and involved.
  5. Rightshifting: ABC encourages the concept of ‘Rightshifting’, that is, continuously advancing and improving competence over time. The goal is not just to adopt agility at scale but to excel in it, driving the organisation and its teams towards increasing effectiveness. ABC promotes a culture of learning and continuous improvement, ensuring your organisation evolves, adapts and always stays ahead of the curve.
  6. Cadres: People are the heartbeat of any organisation, and ABC understands this. It emphasises the importance of nurturing interpersonal and interdepartmental relationships, developing skills, and building strong, diverse teams. ABC recognises that your organisation’s success lies in the hands of its teams and encourages the cultivation of a supportive, growth-oriented environment. In this way, ABC ensures your adoption is people-centric, thereby boosting team morale, enhancing collaboration, and ultimately driving productivity.
  7. Control and Oversight: While ABC champions the autonomy of self-organising teams, it also recognises the need for effective control and oversight. By providing a framework for checks and balances, ABC ensures that accountability is maintained and that the adoption meshes with the organisation’s strategic goals. This balanced approach facilitates innovation and problem-solving at the team level while ensuring overall coherence and direction at the organisational level.

ABC in Practice

ABC enables quick, low-cost, low-disruption adoption and ensures quick results through AI-powered assistance tools. These tools analyse your organisation’s unique attributes, predict potential hurdles, and provide data-driven advice to facilitate a smooth and easy transition.

Conclusion

ABC offers a viable route to achieving enterprise agility. With its unique approach to adopting agility at scale, ABC paves the way for big companies to stay competitive and resilient in a fast-paced business landscape. ABC does more than just solve the problem of adopting agility in large enterprises; it redefines how these organisations can harness the power of agility at scale. By putting a simplified adoption process at its core, ABC is truly making the adoption of agility at scale as simple as ABC.

About ABC

Agility for Big Companies (ABC) is designed specifically for large enterprises. Leveraging AI and open source, ABC simplifies the process of adopting agility at scale, reducing costs and ensuring a smooth, disruption-free transition. ABC is built on decades of experience successfully working with major corporations, making it a trusted solution for achieving enterprise agility.

 

A public, online version of this white paper is also available.

 

The Philosophy of “Fail Early, Fail Often”

The mantra “Fail early, fail often” has become a guiding principle across various innovative and creative fields, but let’s understand that this philosophy’s aim is not to fail, but to learn. By recognising that

“Learning has only happened when behaviour has changed”

we can see that failure is not an end in itself but a means to an end. Let’s explore this concept in the context of business, design thinking, entrepreneurship, and the cultural shift towards iterative learning.

Learning Through Failure: A Definition

In the context of “Fail early, fail often,” failure is not an objective but a pathway to learning. But what does learning really mean? As succinctly put: “Learning has only happened when behaviour has changed.” This definition underscores that genuine learning isn’t just about acquiring knowledge; it’s about transforming that knowledge into actionable changes in behavior. It’s about adaptation, growth, and tangible improvement.

Applying the Philosophy in Various Fields

1. Business: In the broader business context, this philosophy encourages companies to see failures in strategy, products, or execution as opportunities for learning and growth. It promotes an approach where mistakes lead to insights, refinements, and strategic pivots. By fully embracing that “Learning has only happened when behaviour has changed,” businesses can become more resilient, innovative, and responsive to market dynamics.

2. Software Development: In iterative development, failures are not mistakes but learning opportunities. A bug or a flaw in the code is a chance to inspect, learn, adapt, and improve. With each failure and subsequent adaptation, the software evolves.

3. Design Thinking: Design thinking emphasises empathy, experimentation, and prototyping. Here, failing early and often is part of a process of continuous refinement and learning. A design that doesn’t adequately meet folks’ needs is not a failure but a lesson, leading to changes in approach and better solutions.

4. Entrepreneurship: For entrepreneurs and startups, every failure is a step towards understanding the market, the product, or the business model. Adapting to these failures, changing behavior in response to lessons learned, aligns perfectly with the understanding that true learning is evidenced by changed behavior.

The Cultural Shift: Learning as a Change in Behaviour

This shift towards embracing failure as a learning tool has profound cultural implications. It fosters an environment where innovation, creativity, and continuous growth thrive. Here’s how:

  • Encouraging Experimentation: Organisations embracing this philosophy promote a culture of experimentation and risk-taking, knowing that failure is not a dead-end but a catalyst for change and learning.
  • Building Resilience: By viewing failure as a learning opportunity, teams become more resilient and adaptable, capable of transforming setbacks into progress, fully embodying the idea that “Learning has only happened when behaviour has changed.”
  • Fostering a Chaordic Mindset: This approach nurtures a mindset where challenges are opportunities for growth and improvement, reinforcing that genuine learning results in changed behavior, not just theoretical understanding.

Fear of Failure in Big Companies

Larger corporations often struggle with the fear of failure, and this can manifest in several ways:

  • Risk Aversion: Big companies avoid taking risks due to the potential negative impact on personal status, their established reputation, market position, or shareholder value. This aversion stifles innovation and slows response to market changes.
  • Bureaucratic Hurdles: A complex hierarchy and decision-making process slows down experimentation. The fear of failure leads to endless deliberations, committees, and approvals that hinder agility and creativity.
  • Cultural Barriers: Organisational cultures emphasise success to the point where failure is seen as unacceptable. This can create a stifling environment where employees are afraid to try new things or propose innovative ideas.
  • Short-term Focus: A focus on quarterly results and immediate profits discourages long-term investments in research, experimentation, culture change, and innovation. If failure is not an option, the approach to growth becomes conservative and incremental rather than bold and transformative.

However, even large corporations can learn to embrace the philosophy of “Fail early, fail often” by understanding that “Learning has only happened when behaviour has changed.” By fostering a culture that sees failure as an opportunity for learning, big companies can become more agile, innovative, and resilient.

Conclusion

The philosophy of “Fail early, fail often” is a reminder that failure is not something to be feared or avoided but embraced as a valuable tool for learning. By recognizing that “Learning has only happened when behaviour has changed,” we shift our focus from failure to the transformative power of learning.

In software development, design thinking, entrepreneurship, and beyond, this approach fosters a culture of innovation, resilience, and continuous growth. It’s not about celebrating failure; it’s about embracing the learning that comes from it and recognizing that real growth and innovation happen when we allow ourselves to fail, learn, and change our behavior accordingly.

The next time you face a setback or a “failure,” remember that it’s an opportunity to learn, adapt, and grow. Embrace the process, and let the philosophy that learning is manifested in changed behavior guide your journey to success.

Testing the Waters: Opensourcing the ABC Framework

The big company world has been swept up in the pursuit of agility at scale, with frameworks such as SAFe, LeSS, and DAD leading the charge. However, a growing number of voices within the community have expressed dissatisfaction with these current approaches, leading some to label it as simply “agility bandwagoning.”

Is this discontent just unfocused griping, or is it emblematic of a community genuinely frustrated with the trend of adopting agility without understanding its core values? The recent decision to open source the ABC framework (Agile Beyond Conformity) is an interesting move that may provide answers by way of a public experiment.

Agility at Scale: The Landscape

Critics argue that the current approaches to agility at scale are more about fitting a trend than delivering on the principles of enterprise agility But is this frustration justified, or merely resistance to change?

A Fresh Approach

The ABC approach aims to offer a unique alternative that bypasses the perceived pitfalls of existing approaches. Open sourcing ABC is a way to allow the community to directly shape its development, providing insight into whether the dissatisfaction with current agility strategies is substantive.

Open Sourcing ABC: Engaging with the Community

Open sourcing is about more than free access. It’s about collaboration and embracing diverse thought. By making ABC available to all, the creators are setting the stage for:

  1. Community Contribution: This invites critics to become part of the solution.
  2. Transparency: Unlike commercial approaches, open sourcing ABC ensures that all discussions and developments are publicly visible.
  3. Experimentation: ABC can become a space for innovation, real-world feedback, and continuous refinement.

Conclusion: A Bold Step or Just a Test?

The open sourcing of ABC is more than just a test of the waters; it’s a bold statement that challenges the current landscape of agility at scale. It’s an invitation to reshape how we think about agility, moving away from mere conformity and towards a more meaningful transformation.

Only time will reveal if ABC becomes a significant force in the industry or merely a probe into the community’s sentiment. Regardless, its open sourcing stands as a symbol of innovation and a break from the trend, potentially guiding the future of agility at scale in a direction truly aligned with the needs of big companies.

Announcing the Open Sourcing of ABC (Agility for Big Companies): A Success-Driven Approach

The quest for success in today’s complex business environment often leads companies down paths that promise agility but fall short in delivering tangible results. Approaches like SAFe, LeSS, and DAD have left organisations yearning for something more substantial, more aligned with the pursuit of genuine success.

Introducing ABC (Agility for Big Companies): A New Pathway

Today, I am proud to unveil the open sourcing of ABC (Agility for Big Companies), a growing compilation of documents and guidance designed to foster success at scale. What sets ABC apart is not just its innovative approach but its open source, evolving nature. It’s a living community effort that will continue to grow and adapt to the ever-changing needs of big companies.

Success, Leadership, and an Evolving Repository

ABC’s approach focuses on aligning agility with the real-world needs of large companies. It subtly enhances leadership influence and fosters an environment where success is achievable and sustainable. It’s not just about a static set of guidelines; it’s about a community effort in making an ongoing journey towards excellence.

Read Through the ABC Document Repository

The ABC Google Docs Document Respository is now open to everyone to read. You’ll find insights, strategies, and tools to help drive success, all within a repository that is intentionally unfinished and ever-evolving.

You might find the Working Drafts document ABC – A Reading Path one handy place to start.

If you’re interested in just reading, great! But if you want to contribute to this growing movement, I invite you to request commenting or editing access. Your active participation (subject to review) will help shape the ABC approach, adding to its richness and relevance.Most of the current content is unfinished, and will benefit from many eyes, comments and edits.

24x7x365 Support and Collaboration

I’m here for you 24x7x365, ready to support, listen, and collaborate. Together, we can build an approach that not only resonates with the demands of big companies but also reflects our collective wisdom and desire to improve the world.

Join the Movement

The open sourcing of ABC is an invitation to join a movement that celebrates success and provides real agility at scale (not just hollow promises). With your insights, your participation, and your commitment, we can create an approach that’s not only about agility but also about a fulfilling pathway to success that continues to evolve.

Your success, our success. An unfinished journey, a shared vision. Let’s make it happen. Together.

And please share with your friends!


I’m Here for Everyone

Contact me through the WordPress comments section (below), or email, for support, insights, and to request active membership of this dynamic and evolving community.

Google Meet, etc. chats are also possible, by arrangement.

Remember the ancient African proverb:

“If you want to go fast, go alone. If you want to go far, go together.”