Archive

Software development

Why Read My Blog

Wishing a joyful New Year to my host of regular readers – welcome back! It’s great to have you here as we continue exploring how to create truly joyful and human-centered workplaces. If you find value in my posts, please consider sharing my blog with your colleagues, friends and online communities who may be interested. Personal recommendations are so appreciated!

For new visitors, hello and thanks for finding my blog! I’m FlowChainSensei, and my passion is helping organisations transform themselves into places where people are fulfilled and joyfully engaged in their work. I draw from my 50+ years in the software business to provide practical insights into topics like:

  • Building trusting, empowered teams
  • Promoting flexible work arrangements
  • Rethinking rigid processes and bureaucracy
  • Excelling together, with compassion and humility
  • Fostering a culture of learning and growth

Thriving Workplaces

My goal is to challenge conventional thinking and offer ideas, examples, and advice to help you cultivate a workplace where people thrive. Here’s why you might choose to subscribe:

  • Gain unique perspectives for reimagining work
  • Get inspired by real-world examples and recommendations
  • Discuss/debate ideas with a community of forward-thinkers
  • Help make working together something we love to do, not have to do

Tell Your Friends, Peers, Bosses

To my regular readers, I so appreciate you being part of this community and movement. To new readers, welcome! I hope you’ll subscribe and engage. Let’s reimagine work together! And to all, please consider sharing my blog with others who may find value in rethinking work.

Win Free Books!

In my three organisational psychotherapy books I both summarise and go into much detail on many of the posts appearing in my Think Different blog. BTW The competition for free copies of my Hearts Over Diamonds +  Memeology + Quintessence books is again open.

Why Businesses Don’t Give a Rat’s Arse about Software Development

The “Jack Shit” Approach to Software Economics

Business leaders often claim to be committed to innovation and progress. But when it comes to understanding the economics, practicalities, and psychology of software development, many seem to have no fucks to give. Surprisingly, in an era where digital transformation is not optional, apathy and indifference prevails.

Why the Apathy?

On the surface, business leaders talk the talk. They use buzzwords like “Agile,” “DevOps,” and “scalability.” But dig a little deeper, and it becomes evident that there’s little understanding or even interest in the complexities of software development economics.

What’s the Cost?

This lack of attention is not without consequences. Companies face delayed projects, bloated costs, and low-quality products. All the while, they overlook the vital connection between development economics and success. Apathy towards understanding software economics is akin to saying, “I couldn’t give a rat’s arse about business success.”

Psychology Matters, Doesn’t It?

The psychological aspects of software development also suffer from this indifference. Teams become demotivated, stressed, and disengaged when management doesn’t grasp or value the complexities of their work. It’s not about methods or coding; it’s about human beings who have needs for meaning, purpose, and being valued.

Where’s the Change?

For all the talk about being agile and adaptive, the basic mindset toward software development often remains rigid and uninformed. There’s a significant gap between what businesses claim to value and what they actually prioritise.

Conclusion

For businesses to truly succeed in the digital age, this lackadaisical approach won’t cut it. A failure to understand and adapt to the economics, practicalities, and psychology of software development will only serve to hinder progress and profitability. Is it time for businesses to move beyond buzzwords and start giving more than a rat’s arse about the fundamentals of software development?

Training For All The Wrong Skills

Are We Training People For the Wrong Skills?

In business and software development, we’ve got a misalignment. We’re so wrapped up in perfecting the technical, we lose sight of the human. Developers are trained to churn out code more quickly, code that’s faster, cheaper, and more reliable, but are they learning how to solve real-world problems? Testers are trained to find bugs, but not how to prevent them. The result: technically proficient software that either nobody wants or that arrives late and over budget, or both.

Technical Matters?

Yes, quality code is essential. Yet, it’s by no means the end-all and be-all. A developer isn’t just a code-writing machine; they’re attendants. The fixation on coding and computing skills above all else turns them into technicians rather than holistic thinkers capable of understanding and meeting folks’ needs. When developers are pigeonholed into this role, organisations miss out on the broader impact their expensive developers could be making.

What About Bugs?

Finding bugs is a red herring – what if we could prevent them in the first place? Testers are often pigeonholed into merely identifying issues rather than participating in a more proactive approach. This approach costs time, money, and may even reduce the software’s overall quality because the focus is on fixing, not preventing. The need for speed in bug-finding diverts attention from other valuable forms of contribution, like feature development and needs validation (making sure the product meets the real needs of all the Folks That Matter™.

What’s the Cost?

When we narrow our focus to speed, efficiency, and defect detection, we end up inflating costs and extending delivery times. Software development isn’t just about churning out lines of code or ticking off a testing checklist. It’s a more nuanced art that blends technical skills with an understanding of the needs of all the Folks That Matter™.

Where’s the User in All This?

In the chase for technical mastery, it’s easy to forget the end-user. Products, at their core, are intended to make lives easier, to attend to folks needs. When developers and testers are not trained to master these things, we end up with products that are high on features but low on utility.

So What’s the Solution?

If we’re to correct this misalignment, we need a cultural shift. We might choose to reorient our training and development programmes. For developers, this means less emphasis on speed and more on understanding who matters, and then discovering and meeting these folks’ needs. For testers, a shift from just finding bugs to a more holistic approach to quality via defect prevention (Cf. ZeeDee) would be transformative.

Where Do We Go from Here?

The technical aspects of software and product development are, without a doubt, essential. But they aren’t the whole story. By shifting our focus to include all the needs of all the Folks That Matter™, we can create products that not only work but makes a difference. The first step? Acknowledging that we’ve been training for all the wrong skills.

Are Managers Killing Their Golden Geese?

Cognitive Function Rules

Cognitive function encapsulates the mental processes needed for problem-solving, abstract thinking, and quick decision-making. In the realm of software development, high cognitive function is indispensable for understanding complex algorithms, creating efficient code, delivering quality, and solving intricate problems.

Why Does Cognitive Function Matter?

When cognitive function is at its peak, developers can perform their tasks not just quickly but also effectively. It enables them to come up with innovative solutions, debug issues proficiently, and contribute meaningfully to a project’s success.

How Do Managers Disrupt Cognitive Function?

Routine managerial practices like frequent check-ins, status reports, micromanagement, and unclear objectives can negatively impact a developer’s cognitive function. Added to this, loaded work schedules and harsh deadlines contribute to stress, which further degrades cognitive performance.

What About Toxic Behaviour?

Abusive and toxic conduct from managers goes beyond disrupting cognitive function. This behaviour often leads to severe emotional stress, causing long-term harm – including brain damage – that manifests as burnout, poor performance, and staff turnover.

What’s the Consequence?

When cognitive function suffers, the ripple effect is felt throughout the team and the organisation. There’s a decline in product quality, an increase in mistakes, and a noticeable lag in delivery timelines. In such a scenario, managers are essentially killing the very geese (developers) that lay the golden eggs (software).

Is There a Remedy?

Creating a more nurturing work environment can help. Managers might choose to adopt practices that allow for focused work, respect individual needs, and most importantly, eliminate toxic and abusive behaviours.

Will Change Happen?

The ball’s in the managers’ court. The cognitive well-being of their software developers—and by extension, the quality and success of their own wellbeing—depends on how they choose to adapt their management styles.

A Question of Flow

A New Take on Flow?

When we hear about flow, it’s often linked to a psychological state of focus and immersion. But flow isn’t just a psychological state popularised by Mihaly Csikszentmihalyi. There’s another kind of flow that plays a critical role in organisations. This type of flow refers to a well-coordinated series of actions, events, or processes that work in harmony – flow as a smooth succession of actions that take place within an organisational setting

Why Should You Bother?

Paying attention to flow in your organisation is not just an academic exercise; it’s a practical necessity. Improved flow means fewer bottlenecks, quicker turnarounds, and more satisfied employees. Given these benefits, can you afford to overlook the importance of achieving good flow?

Is Structure the Solution?

While structure might seem constraining, it offers a foundation upon which flow can thrive. Roles and responsibilities are clearer, and tasks follow a more predictable pattern. However, there’s a limit to the benefits of structure. Could too much structure curtail creativity and inhibit the capacity for innovative solutions? How much structure is “just enough”?

How Tech Can Contribute

Modern technology provides tools that make it easier to achieve flow. Automated systems can handle repetitive tasks, freeing humans to focus on complex challenges. Additionally, real-time data analytics can identify potential bottlenecks before they become major issues. But what’s the cost of getting your tech choices wrong?

Humans in the Equation

A finely tuned system isn’t just about technology or well-drafted processes. The human element—morale, motivation, and collaboration—also plays a pivotal role. When employees work well together, the flow is more natural and less forced. How can we foster a culture that encourages this kind of harmony?

What Metrics to Use

Choosing metrics for gauging flow involves more than just picking numbers to track. Do task completion times, takt times, employee engagement levels, or customer satisfaction rates resonate with your organisational goals? How do you know if you’re focusing on the right measures to sustain or enhance flow?

Ready to Make a Change?

Embarking on the journey to improve organisational flow is a complex but rewarding endeavour. It involves continuous assessment, involving multiple stakeholders, and making frequent adjustments. Are you willing to commit the necessary time and resources to achieve a state of optimal flow?

Flow, in this organisational sense, is a multifaceted concept. By asking the right questions and taking a balanced approach, you can create an environment where flow becomes a natural aspect of your operational landscape. So, are you prepared to rethink what flow means for you and your organisation?

A Question of Flow: Extending into the Software Realm

Does Software Development Redefine Flow?

In the complex landscape of software development, flow takes on nuanced dimensions. Beyond well-coordinated actions and processes, here it’s about managing interdependent systems, handling data, and synchronising multiple contributors. How does the concept of flow evolve when applied to software?

What Are the Stakes for Software Projects?

The relevance of flow extends far beyond general organisational theory when we delve into software projects. It’s not just about speed but also about code quality, user experience, and sustainable development. How does focusing on flow lead to more resilient and robust software systems?

How Does Architecture Influence Flow?

In software development, the architecture itself can facilitate or hinder flow. Modular designs and well-defined APIs can dramatically streamline the work process. How could architecture be leveraged to enhance flow, without compromising quality?

Are DevOps and CI/CD Flow Enablers?

DevOps culture and Continuous Integration/Continuous Deployment (CI/CD) pipelines are revolutionising the flow in software development. They merge development and operations, automating much of the workflow. Is the automation brought by these practices always beneficial, or could there be drawbacks?

Can Open Source Cultures Teach Us About Flow?

The open-source community often exhibits a unique kind of flow, built on collective intelligence and decentralized collaboration. Can traditional organisations learn from this paradigm?

What About Flow in Remote Teams?

The rise of remote work presents new challenges and opportunities for achieving flow in software development. How do time zones, cultural differences, and virtual communication affect flow? Can they be harnessed to enhance it instead?

Is Ethical Software Development Compatible with Flow?

Rapid development cycles and the pursuit of flow might conflict with the need for ethical considerations in software design, such as accessibility and data privacy. Can a balance be achieved where ethical imperatives don’t disrupt the flow?

Are We Ready for the Future of Software Development Flow?

As technologies like AI and quantum computing mature, they’ll inevitably impact the flow of software development. Will we adapt our notions of flow to these advancements, or will the concept of flow itself undergo a transformation?

By integrating these big-picture considerations, we can explore new frontiers of flow in both traditional organisations and software development landscapes. The question remains: Are we ready to adapt and evolve?

Cultivating Code

Creating an effective software development environment requires more than technical skills or product roadmaps. As developers and development leaders, our roles encompass a broad range of responsibilities. The following sections delve into these multifaceted aspects – aspects that contribute to an environment where software development – and software developers – will flourish.

The Distinction

Developing software and leading its development are fundamentally different. While the former focuses on the practicalities of building solutions, the latter revolves around creating a conducive environment for such work to take place.

But what makes for an environment particularly well suited to software development? Let’s dive in.

Fostering Communication

As developers, we often delve deep into code, sometimes forgetting the world outside – sharing ideas, discussing problems and collaborating on solutions. But communication is the linchpin that holds everything together. In a leadership role, we must create an atmosphere where communication is fluid, open, and encouraged. This includes not only daily stand-ups or periodic meetings but also an open-door policy where team members feel they can approach us with their ideas or concerns. We set the tone, the language, and the pace for how communication happens.

Autonomy and Responsibility

Developers perform best when given the freedom to make decisions related to their tasks. They need autonomy to implement creative solutions. Responsibility accompanies this autonomy; it drives developers to perform their best, knowing that their decisions have an impact.

One of the core drivers for any developer is the freedom to solve problems in unique ways. As development leaders, we should ensure that our teams have the autonomy they need to make decisions about the code they write, the solutions they design, the tools to use, the way the work works, and even the technologies they wish to implement. But with great freedom comes great responsibility. Our role is to instil a sense of mission or purpose – the organising intent – that complements this autonomy. We need our team members to lean in to and own their decisions, fully, leading to a greater commitment to quality.

Note: Organising Intent refers to a clearly articulated objective or vision that guides the actions and decisions within a software development team. A clearly stated organising Intent provides team members with the ‘why’ behind their tasks. By understanding the broader goals and implications, team members are better equipped to make autonomous decisions that align with the overarching aims of the organisation. This intent serves as a unifying principle, enabling more effective coordination and fostering a shared sense of purpose.

Emotional Well-being

It’s essential for developers to feel mentally and emotionally supported. An environment that actively addresses burnout, stress and provides a good work-life balance contributes to better productivity and job satisfaction.

Work isn’t just about ticking off tasks from a to-do list; it’s also about the emotional and mental state of the team. As leaders, it behooves us to create a supportive environment that acknowledges the human aspects of work. From attending to folks’ needs, through acknowledging achievements, however small, to actively addressing burnout and stress, we have to consider emotional well-being as an integral part of the development process.

Continuous Learning and Cognitive Functioning

As developers, we understand that learning doesn’t stop once we leave the classroom; it’s an ongoing process essential for staying relevant. As development leaders, fostering a culture of continuous learning is a two-fold task. On one hand, it involves providing opportunities for skill enhancement. On the other, it requires an understanding of cognitive functioning, ensuring that our teams can absorb new knowledge under optimal conditions.

Cognitive dissonance, the psychological stress experienced when confronted with new information that conflicts with existing beliefs, can be a powerful motivator for growth. Rather than shying away from this discomfort, we can use it as a tool to encourage team members to re-examine old ways of thinking and adopt new, more effective methods.

The human brain operates best under specific conditions. Too much stress, for example, can trigger amygdala hijacks, where the emotional part of the brain interferes with rational thinking. Such episodes can halt learning and creativity dead in their tracks. As leaders, recognising the signs of stress and understanding how to defuse it are vital for creating an environment conducive to cognitive functioning and, by extension, continuous learning.

Our role, then, extends beyond merely finding resources. We must also cultivate an environment that encourages personal growth, helping our team members navigate the tricky psychological landscape that comes with collaborative knowledge work. In this way, we create a fertile ground not just for learning new technologies or ways of working, but for fundamental personal and emotional growth.

Feedback Loops

Regular feedback is essential for both the product and the team. Leaders might choose to establish short feedback loops with customers and among team members, allowing for agile adjustments and quicker improvements.

Feedback is the compass that guides development. As developers, we often look for immediate feedback from our code compilers or debugging tools. But as leaders, we establish feedback mechanisms that encompass not just the product but also the team, and all the Folks That Matter™. Regular team reviews, client feedback, and even self-assessments are tools we can use to ensure we’re always moving in the right direction.

Summary

Leading software development isn’t about barking orders from an ivory tower. It’s about cultivating a field where the seeds of software development can grow into robust solutions which meet folks’ needs.

Being at the helm of software development is not about mere management, nor even simple leadership. It’s an act of cultivation. As development leaders, we’re gardeners tending to our social  gardens, providing them with the right soil, the right amount of light, and the essential nutrients they need to grow and flourish. From facilitating open communication to caring for the emotional well-being of our team, our actions set the stage for creating effective, sustainable software solutions.

Why I Blog

The Wisdom of Experience: A Vocation for Helping

I discovered years ago that my life’s vocation is to help people. Blogging serves as an extension of that purpose, albeit in a less direct manner. It’s something I can do when not directly interacting with people, in person. Over 50 years in software development and its management have given me a rich blend of experiences. I’ve learned from both triumphs and setbacks, taken on diverse roles, and adapted to technological shifts. This extensive base of lived wisdom forms the foundation of my blog. It’s not merely about underlining what’s essential for success; it’s about offering insights that could, even obliquely, guide someone to make better decisions or reconsider their challenges.

Against the Grain

I find that key topics that have the potential to bring meaningful change in the realm of software development are often sidelined or ignored in mainstream discourse. Whether it’s the weight of soft skills, the dynamics of organisational culture, or novel approaches to the way the work works, these subjects frequently miss the limelight.

Crystalising Thoughts

Writing isn’t just about sharing; it’s also about clarity. The very act of putting thoughts into words enables me to fine-tune my own understanding, making blogging both an external and internal refinement process.

The Loop of Impact

Introducing perspectives that diverge from the norm creates an environment ripe for dynamic feedback. Through interactive elements like comments and discussions, both the reader and I have the opportunity to refine our understanding, thereby fostering continual growth in the software development sector. Whether you avail yourself of these opportunities or not is up to you.

On Being Selective

Topics are chosen for their high potential to promote the surfacing and reflecting on collective assumptions and beliefs within organisations. Although not every reader will align with my specific focus, the ensuing conversation among differing viewpoints contributes to a more nuanced, comprehensive understanding of our field.

Summary

To put it simply, the blog opens a space for neglected yet crucial topics in software development and general management. Through it I aim to initiate dialogue and encourage mutual growth, not just deliver a monologue. Although helping people is a core part of my ethos, this blog’s main role is to provoke conversations that enrich us all.

Positive Relationships and Collaborative Knowledge Work

Why Relationships Matter in Collaborative Settings

In sectors such as software development, and management, where collaborative knowledge work is the norm, the quality of relationships isn’t just a social nicety—it’s a business imperative. Positive interpersonal connections amplify collective intelligence, increase productivity, and enhance the overall quality of work. In contrast, strained relationships lead to communication breakdowns, reduced morale, and compromised results. Hence, any team that aims for excellence might choose to focus, at least in part, on fostering positive relationships.

The Heart of the Matter: Caring Deeply

Before diving into the nuts and bolts of relationship building, it’s important to highlight a fundamental principle: genuine care for those with whom you’re working. In the context of collaborative knowledge work like software development, or management, compassion might not be the first thing that comes to mind. However, a deep sense of care and understanding for your fellows is what turns a group of individuals into a cohesive unit. Compassion fosters a supportive environment where people feel valued, not just for their technical skills but for who they are as individuals. This, in turn, leads to a sense of shared purpose and mutual respect, driving the team to higher levels of achievement.

For those sceptical about the role of compassion in a professional setting, the book “Compassionomics” provides compelling evidence. It delves into the science behind compassion and demonstrates how this emotional intelligence skill significantly impacts relationship building and, ultimately, success.

Having set the stage with the importance of deep care and compassion, let’s delve into the specific strategies to build and maintain positive relationships in collaborative settings.

Master the Art of Listening

Listening is more than just a passive act; it’s an active skill. This is especially crucial in collaborative knowledge work where understanding each other is key to solving complex challenges. Effective listening reveals not only what team members are saying but also what they’re thinking or possibly avoiding saying. Technical teams and management teams may choose to regard this deeper level of communication as critical for addressing challenges and finding solutions collaboratively.

Cultivate Self-Awareness

In a team setting, knowing oneself is as vital as knowing one’s craft. Being aware of one’s own strengths, weaknesses, and emotional responses can help navigate team dynamics more effectively. This level of insight allows one to contribute where most effective, and defer when deferral plays to someone else’s strengths.

Uphold Respect as a Core Value

In any collaborative effort, people bring a diverse set of skills and perspectives to the table. The concept of respect goes beyond mere tolerance of this diversity; it involves valuing and leveraging these different skills and viewpoints to enrich the project. In software development, where cross-functional teams often collaborate, respecting different disciplines—be it engineering, UX design, or quality assurance—is vital for project success.

Make Room for Personal Space

Even in high-stakes environments, it’s crucial to understand that everyone needs space to operate effectively. Overcrowding can lead to burnout, reduced productivity, and deteriorated relationship quality. Allowing for ‘breathing room’ can also offer team members the chance for independent thought, which they can later bring back to enrich the collective effort.

Be Consistent in Communication

Effective communication is a key element of successful relationship building. In a fast-paced, deadline-driven setting, regular check-ins can be the lifeline that keeps projects on track. This doesn’t just mean status updates, but also sharing feedback, insights, and even acknowledging small wins. It keeps everyone aligned on goals and expectations, reducing the room for misunderstandings or conflict.

Embrace Adaptability

The nature of collaborative knowledge work, particularly in tech, is dynamic. Flexibility and willingness to adapt are not just desirable traits but beneficial practices for maintaining positive relationships amidst change.

Summary

In collaborative knowledge work, the importance of maintaining positive relationships is amplified due to its direct impact on productivity and outcomes. By incorporating principles like effective listening, self-awareness, respect, personal space, consistent communication, and adaptability, you can lay down a robust foundation for a successful collaborative environment.

Further Reading

Trzeciak, S., & Mazzarelli, A. (2019). Compassionomics: The Revolutionary Scientific Evidence that Caring Makes a Difference. Studer Group.

Improving Without Measuring

The Mirage of Measuring Productivity

Most organisations regard metrics as the Holy Grail of productivity. But what if we’re wasting our time, trapped in a Sisyphean cycle of measuring, adapting, and then measuring again, without achieving improvement? Metrics often mislead us. The more relevant question is: How do we truly make a difference?

The Complexity of Social Systems in Software Development

To get to the heart of the issue, we have to confront the chaos that comes with human beings working together. People aren’t variables in an equation; they’re living, breathing agents of unpredictability. In such an environment, even if we find a metric that looks promising, the inherent complexity could render it meaningless.

Deming’s Caveat: “The Most Important Figures are Unknown or Unknowable”

Before we take another step down the rabbit hole of productivity metrics, let’s pause to reflect on a pertinent insight from W. Edwards Deming, the father of modern quality management. He stated,

The most important figures that one needs for management are unknown or unknowable.

If one of the most influential minds in quality management and productivity warns us against an over-reliance on metrics, it’s worth taking note.

Why Metrics Often Fail in Social Systems

Metrics tend to misfire when applied to the inherently chaotic world of human interaction. It’s not a mechanical system with predictable outcomes; it’s more of an organic entity with complex, non-linear interactions. So, when metrics disappoint, it’s not the numbers that are at fault but our misplaced expectations of their ability to capture reality.

Turning to Systemic Improvements: The Untold Chapter

If we heed Deming’s advice, our focus shifts from trying to measure the immeasurable to creating conditions for productivity to flourish. When we step back from the Sisyphean task of trying to pin down productivity with metrics, as per Deming’s counsel, we make room for a paradigm shift.

Instead of fixating on measured outcomes, the focus turns towards the fertile ground from which these outcomes naturally emerge. Here’s how this shift fundamentally changes our approach to productivity. (Cf. Quintessence).

Systems Thinking: The Big Picture

Deming was a strong advocate for systems thinking. This perspective urges us to see the workplace not as a collection of isolated variables but as a holistic system. Individual performances are interrelated, affected by the entire system, including leadership styles, workplace culture, communication pathways and a host of other memes. By optimising the system as a whole, we inherently create conditions for better productivity.

Quality of Interactions Over Quantity of Output

If we’re not bogged down by the numbers, we can invest time and energy into what really matters, such as the quality of interactions among team members. High-quality interactions naturally lead to high-quality output. Team members who communicate clearly, collaborate effectively, and feel psychologically safe are more likely to be productive.

By heeding Deming’s advice, we engage in a more holistic, humane, and, ironically, effective approach to boosting productivity. We may not have a neat vanity metric to showcase in the next board meeting, but the signs will be everywhere—in the engagement of the team, the quality of the work, and the satisfaction of your clients.

Improving Without Measuring: Sounds Like Heresy, Doesn’t It?

Here’s the part where some people might think we’re heading into taboo territory. How do we know we’re making progress if we’re not measuring it? The key is to focus on systemic improvements that are intuitively beneficial, such as:

  • Surfacing and reflecting on collective assumptions and beliefs
  • Attending to folks’ needs
  • Enhancing communication channels
  • Making things visible
  • Reducing work-in-progress
  • Emphasising learning and personal development
  • Promoting psychological safety

By attending to these areas, we’re likely moving in the right direction, even if we can’t quantify it.

Feedback Loops: Your New Best Friend

Feedback loops provide insights without the narrow focus of traditional metrics. They allow teams to observe patterns, adapt, and continuously learn. These can range from daily stand-ups to sprint reviews, to customer feedback sessions. The idea is to keep the feedback continuous and actionable.

Holistic Approaches: Taking a Cue from Organisational Psychotherapy

Improving productivity in complex systems requires less of a mechanical approach and more of a therapeutic one. Techniques like organisational psychotherapy aim to uncover underlying issues at the collective subconscious level. By addressing these foundational aspects, we’re more likely to see a genuine shift in productivity.

So, Are We Moving the Needle?

The perennial question still stands: How do we know we’re improving? But maybe we’ve been asking the wrong question. The more relevant question is: Are we creating an environment where improvement is not just possible but inevitable? And what does that environment look like?

So, let’s leave behind the vanity of metrics and embrace the nuanced, often messy journey of actual improvement. The numbers may not make it to a glitzy PowerPoint presentation, but the positive change will be palpable. And isn’t that what really matters?

Your Journey with “The Team Fruit Bowl”

When Words Turn Into Conversations

First off, a colossal ‘thank you’ for the many folks who have been embracing my most recent book, “The Team Fruit Bowl“. The level of engagement and enthusiasm around this project has been genuinely heartwarming. But enough about me, let’s talk about you. How are you finding your journey through the book?

The Palette of Emotions

Are you laughing, pondering, or perhaps furrowing your brow as you turn the pages? Emotional reactions can be the most candid feedback. Do you feel it hits the mark when discussing team dynamics and organisational culture?

Navigating by Your Stars

If a book can be thought of as a ship setting sail, then your feedback serves as the North Star, guiding its voyage. Your thoughts, critiques, and even queries can illuminate new territories to explore in the topics of tembuilding and organisational psychotherapy. So, what’s lighting up your sky?

Request Line is Open

Any particular topics or questions you’re itching to see explored further in subsequent editions, works or talks? This isn’t a monologue; it’s an ongoing dialogue, and your voice is the missing ingredient. Let’s make this journey not just insightful but also collaborative.

I look forward to hearing your insights, reflections, and even criticisms, if you’ve got ’em. After all, it’s your engagement that turns the book from a solo endeavour into a full-blown orchestra.

Cheers!

The Deming Way to Measuring Software Developer Productivity

Many software folks pay lip service to Bill Deming and his work. Few if any pay any attention to the implications. Let’s break the mould and dive into how the great man himself might look at software developer productivity (a subset of collaborative knowledge worker productivity more generally).

This isn’t just a thought experiment; it’s an invitation to rethink our existing assumptions and beliefs about productivity.

Why Traditional Metrics Don’t Cut It

If Deming could peer over our shoulders, he’d likely be aghast at our fascination with shallow metrics. Lines of code? Bugs fixed? DORA? SPACE? These are mere surface ripples that fail to delve into the depths of what truly constitutes productivity. Deming was a systems thinker, and he’d want us to look at productivity as an outcome of a complex system. It’s influenced by everything from the quality of management practices to the clarity of project goals, and yes, even the standard of the coffee in the break room.

Aside 1

Let’s not get too hung up on staff productivity and the measurement thereof.

Deming’s First Theorem states that:

“Nobody gives a hoot about profits.”

A corollary might be:

“Nobody gives a hoot about software developer productivity.”

Which, drawing on my 50+ years experience in the software business, rings exceedingly true. Despite all the regular hoo-hah about productivity. Cf. Argyris and espoused theory vs theory in action.

Aside 2

While we’ve on the subject of measurment, let’s recognise that measuments will only be valid and useful when specified by and collected by the folks doing the work. I’ve written about this before, for example in my 2012 post “Just Two Questions“.

Aside 3

Let’s remember that the system (the way the work works) accounts for some 95% of an individual’s productivity. Leaving just 5% that’s a consequence of an individual’s talents and efforts. This makes it clear that attempting to measure individual productivity, or even team productivity, is a fool’s errand of the first order.

Here’s the Deming Approach

So, how would the statistician go about this? Hold on to your hats, because we’re diving into an eight-step process that marries statistical rigour with psychology and humanistic care.

1. Understand the System

First things first, get to grips with the holistic view. Understand how a line of code travels from a developer’s brain to the customer. This involves understanding the various elements in the software development lifecycle and how they interact.

2. Define Objectives

Random metrics serve no one. Deming would urge us to link productivity measurements to broader business objectives. What’s the end game? Is it faster delivery, better quality, or increased customer satisfaction?

3. Involve the Team

The people on the ‘shop floor’ have valuable insights. Deming would never neglect the developer’s perspective on productivity. Involving them in defining productivity criteria ensures buy-in and better data accuracy.

4. Data Collection

We’ve got our objectives and our team’s perspective. Now it’s time to roll up our sleeves and get to work on data collection. But this is Deming we’re talking about, so not just any data will do. The focus will be on meaningful metrics that align with the objectives we’ve set.

5. PDSA Cycle

Implementing the Plan-Do-Study-Act (PDSA) cycle, any changes aimed at boosting productivity would be introduced in small, incremental phases. These phases would be assessed for their effectiveness before either full implementation or going back to the drawing board.

6. Feedback Loops

You’ve made changes; now listen. Feedback from developers, who can offer a real-time response to whether the changes are working, is invaluable.

7. Regular Reviews

Productivity isn’t a static entity. It’s a dynamic component of a system that’s always in flux. Regular reviews help recalibrate the process and ensure it aligns with the ever-changing landscape.

8. Leadership Commitment

Finally, if you think increasing productivity is solely a developer’s job, think again. The leadership team must be as committed to this journey as the developers themselves. It’s a collective journey toward a common goal.

The Long Game

Deming never promised a quick fix. His was a long-term commitment to systemic improvement. But the fruits of such a commitment aren’t just increased productivity. You’re looking at more value for your business and greater satisfaction for both your developers and customers. So, let’s stop paying lip service to Deming and start actually embracing his philosophy. After all, a system is only as good as the assumptions and beliefs that shape it.

Reflection Demands Self-Examination

Navigating the complex world of software and product development is a journey filled with twists and turns. When it comes to retrospectives, reflection and adaptation are more than just buzzwords; they’re essential tools. But there’s a hidden secret: reflecting without digging deeper into shared beliefs and assumptions is like trying to read a book with 90% of the the pages missing.

The Reflection Trap

Reflecting on what we’ve done is a vital step. Reflection, and acting upon those reflections, is how we learn from our mistakes and our successes. But if we stop at the surface, if we don’t ask ourselves why things happened the way they did, we’re missing a crucial part of the story.

The Missing Piece: Assumptions and Beliefs

Beneath the surface of every decision, every action, and every outcome, there are hidden assumptions and beliefs. These are the unseen forces guiding our choices. They can be our best allies or our worst enemies, depending on whether we recognise them or not.

Why We Need to Adapt

Adapting is more than just changing our actions; it’s about changing our assumptions and beliefs. To truly grow, we need to understand the why behind what we do. We must question our underlying beliefs and confront our assumptions.

Imagine you’re part of a team that keeps missing deadlines. You could tweak your schedules, but if you don’t question why it keeps happening, you might never address the root cause. It could be a belief that everything must be perfect, even if it takes longer. Without confronting that belief, you’ll keep missing those deadlines.

The Road Ahead: Surfacing then Reflecting. Understanding then Adapting

As you explore the world of software and product development, or any path you choose, remember that reflecting is only the first step. Go deeper. Ask why. Understand your assumptions, challenge your beliefs, and then adapt.

The process might be more complex, but the rewards are greater. By engaging with these deeper levels of understanding, you’ll find yourself more aligned with your goals, more resilient in the face of challenges, and more capable of innovative thinking.

Reflecting without understanding what’s beneath is like seeing only part of the picture. Embrace the full journey of reflect and adapt, and you’ll unlock doors to a more fulfilling and successful career in software development or whatever path you choose. It’s not about following a set path; it’s about understanding your path and shaping it as you go. Are you ready for the adventure?

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].

Applying Auftragstaktik in Software Development: Fostering Fellowship Over Hierarchy

Auftragstaktik, an organisational philosophy originating from the Prussian military in the 19th century, and more recently the USMC, has found resonance in various spheres, from combat planning to corporate management. At its core, Auftragstaktik focuses on the principle of needs-oriented leadership. It’s the idea that leaders should define goals – the “commander’s intent – and provide the necessary resources, but leave the “how” to subordinates, thus enabling those subordinates’ creativity, flexibility, and autonomy.

However, an emerging question is how to apply Auftragstaktik in environments that seek to de-emphasise hierarchical management structures and instead foster a sense of fellowship. Specifically, in the world of software development, the traditional reliance on junior officer analogues such as team leaders, Scrum Masters, senior developers, or middle managers is evolving. There is an increasing push to build a more egalitarian and collaborative culture, which can sometimes appear at odds with the military hierarchy from which Auftragstaktik emerged.

Here’s how we can reconcile these two approaches and effectively apply Auftragstaktik in software development environments that prioritise fellowship over hierarchical roles:

Foster a Culture of Ownership

The beauty of Auftragstaktik is that it promotes a sense of ownership among team members by providing them the freedom to approach work in ways they find most effective. In a fellowship-oriented culture, this sense of ownership becomes even more profound. Fellowship empowers teams to not only implement solutions, but also identify problems, propose assignments, and provide feedback to others. This fosters a sense of mutual respect, collaboration, and shared responsibility that is central to a high-productivity culture.

Value Collective Intelligence

A fellowship-oriented culture values collective intelligence above individual contribution. Similarly, Auftragstaktik can be implemented in a way that emphasises the strength of the collective team. By articulating clear needs to be attended to (cf. the Needsscape) and allowing the team to collaborate on the means to meet these needs, you draw on the diverse skills, experiences, and perspectives within the team. This maximises innovation and problem-solving capabilities.

Encourage Continuous Learning

For Auftragstaktik to work effectively within a fellowship model, an organisation might choose to promote and value continuous learning. Teams may choose to cultivate their ability to assess their strategies, learn from their mistakes, and continuously adapt. This invites the organisation to provide space for reflection, constructive feedback, and iteration.

Promote Transparency and Trust

Trust is the bedrock of Auftragstaktik and a fellowship-oriented culture. The organisation might choose to trust their teams to devise the best strategies, while team members need to trust each other to carry out their respective parts. This trust is cultivated through transparency in communication, objectives, expectations, and feedback.

Equip Your Team

Finally, for teams to take responsibility for the “how,” they need to be adequately equipped with the necessary tools and resources. This includes not only tangible assets, such as software tools, but also intangible ones such as information, knowledge, skills, budgets, and support.

Summary

In conclusion, applying Auftragstaktik in a fellowship-oriented environment requires a slight shift in focus from the traditional approach. Instead of concentrating on hierarchy and rigid roles, the emphasis should be on mutual trust, transparency, and the empowerment of the team. Such an approach would not only harness the power of Auftragstaktik but also foster a culture of camaraderie, collaboration, and collective ownership, which are at the heart of the fellowship model.

Further Reading

For a complete book detailing the convergence of Auftragstaktik and Fellowship (and Aikido, too), look no futher than my awesome book, “Product Aikido“:

Marshall, R. W. (2013). Product Aikido. Retrieved from /wp-content/uploads/2013/04/productaikido041016.pdf

The Illusory Embrace of Lean Principles

Introduction: The Paradox of Lean Principles in Software Development

In the realm of software development, a profession supposedly grounded in logic, ingenuity, and attention to detail, a peculiar phenomenon has emerged: an enthusiastic, albeit superficial, adoption of Lean Product Development (LPD) principles. Yet, in the world of programming, logic often bows to corporate politics and bureaucracy, revealing the rather farcical application of Lean principles.

The Utopian Vision: The Seven Principles of Lean Product Development

A close examination of the principles that anchor LPD might suggest the perfect utopia of software development. Flow, Respect for People, Continuous Improvement, Building Quality In, Long-Term Thinking, Seeing the Whole, Visual Management, and Knowledge Transfer, all herald the dawn of a software paradise, where everything runs smoothly, people are respected, and growth is not just continuous but sustainable. However, even a cursory glance unveils a grand spectacle of lip-service, a thin veneer of fine words on the complex, and often messy, reality of software development .

The Mirage of Flow and Respect for People

Take the concept of ‘Flow’ – a vision of value gliding seamlessly from concept to market, buoyed by concepts like Just-In-Time delivery and Decentralized Decision-Making. Yet, in software development, flow is often obstructed by dependencies, delays, and what essentially constitutes red tape, disguised as mandatory protocols and ceremonies. The notion of ‘Just-In-Time’ is perhaps more accurately framed as ‘Just-in-Time…well, almost never.’

Respect for people, the idea that humans are the crown jewels of an organisation, is an exquisite principle, presented as an antidote to the dull, dehumanising industrial complexes of the past. Yet, software development organisations are haunted by the specters of burnout, unreasonable deadlines, and an entrenched culture of overwork. The narrative of respecting people often comes as an attractive facade, hiding the ugly reality beneath.

The Irony of Continuous Improvement

The LPD principle of ‘Continuous Improvement’ or Kaizen, promises a culture of experimentation, reflection, and learning. In practice, however, the pell-mell sprints toward deadlines and deliverables leaves no room for reflection or learning. This culture is often sacrificed at the altar of corporate impatience.

‘Building Quality In’ and ‘Long-Term Thinking’ are noble endeavors in theory but are frequently at odds with the prevailing pressures of the executive suite. Quality is often reactive, not preventative, with emphasis on inspection, and patching issues after release rather than investing in more fundamental preventative measures. And in a world mesmerised by quarterly reports, long-term thinking dissolves under the assault of short-term financial objectives.

The Hollow Echo

‘Seeing the Whole’—the ability to understand the entire system, seems almost laughable when buried under layers of bureaucracy and balkanised teams. The reality is organisations have only the faintest of ideas of the broad strokes and little to no comprehension of the intricate details that weave together to form the larger system.

The principles of ‘Visual Management’ and ‘Learning & Knowledge Transfer’ too, are frequently paid mere lip-service. Dashboards and Kanban boards abound, yet they often serve as ornamental pieces rather than functional tools to guide development. Similarly, the idea of knowledge transfer often succumbs to the siloed nature of many organisations, with the promise of shared learning fading into a distant dream. “Lessons learned”, anyone?

Conclusion: Authentic Implementation of Lean Principles?

In essence, while Lean Product Development principles provide a romanticised vision of what software development could be, the stark reality often sings a different tune. The gulf between the proclaimed adoption of these principles and the realities of their faux implementations serves as a poignant reminder of the challenges that continue to plague the realm of software development. The facade is, in reality, a mirage, conjured from the collective desire to believe in a more rational, more humane, and more effective way of creating software. It’s high time to lift the veil and confront the actual realities of the Lean as actually manifest in the software development world.

“Just Leave Me Alone to Do My Thing!”

The Ubiquitous Cry Across Various Occupations and Its Implications on Collaboration and Customer Experience

I’ve many times seen a fair share of sentiments expressed by folks from various fields, and one recurring theme often surfaces: “Just leave me alone to write code!” This is a common cry from developers everywhere, highlighting a fundamental desire for solitude to focus on their craft. While the specific wording might differ, similar sentiments are echoed across several fields. Here’s a selection:

  1. Architect: “Just leave me alone to design buildings!”
  2. Graphic Designer: “Just let me create my designs in peace!”
  3. Gardener: “Just leave me alone to tend the plants!”
  4. Musician: “Just let me play my music without interruption!”
  5. Chef: “Just let me cook without interference!”

These expressions are not merely cries of frustration or appeals for solitude, but rather, they epitomise the need for creative freedom, mental space, and a conducive environment to manifest ideas into reality.

But what about the users, customers, listeners, diners – the recipients of these creative outputs?

Well, they too play a crucial role. Their feedback, whether it’s a user finding a bug in the software, a homeowner expressing preferences for a home design, a diner offering critique on a new dish, or an audience responding to a musical composition, can be instrumental in refining and enhancing the work. It’s a delicate balance – while folks need solitude for creation, they also require interaction for evaluation, improvement, and growth.

Teamwork is yet another factor, few projects are solo endeavors. Coding involves collaboration with other developers, architects work within a broader design team, chefs coordinate with kitchen staff, and musicians often play in bands or orchestras. These collaborations, despite potential clashes and disagreements, often lead to better outcomes than solitary efforts.

Recognising this balance is key to harmonizing the needs of the workers, users/customers, and teams. On one hand, folks need respect for their creative spaces and processes. They need the freedom to experiment, innovate, and express their expertise. On the other hand, others need them to be open to feedback, collaboration, and the broader perspectives that users, customers, and team members bring.

The takeaway? Let’s create environments that foster both individual creativity and collaborative synergy. Let’s respect the cry of “Just leave me alone to…”, but also remember the value of “Let’s work together on this…” and “What do you think about…?” After all, it’s through this delicate balance that we shape our built world, digital landscapes, culinary experiences, musical scores, and so much more.

Maximising the Amount of Work Not Done: The Power of Attendants in Tech Teams

The world of technology is evolving rapidly, and to keep pace, we must continually reassess how we approach our work. A concept gaining popularity in tech leadership circles is the idea of “Maximising the Amount of Work Not Done.”

Counterintuitive

While this may sound counterintuitive, it is a strategic move towards efficiency and streamlined operations. The role of the “Attendant” embodies this principle. Let’s delve deeper.

The Attendant’s role is less focused on coding intricacies and more on recognising and satisfying the needs of various stakeholders – customers, fellow team members, other teams within the organisation, senior management, and the organisation as a whole. The attendants’ goal? To find the simplest and most efficient solutions to meet these needs.

In doing so, Attendants embody the principle of maximising the amount of work not done. Here’s how:

  1. Focusing on What Really Matters: In any project, there can be a multitude of potential features, tweaks, and enhancements. However, not all are equally important or add significant value. Attendants prioritise based on the actual needs of stakeholders, focusing efforts only on work that meets genuine needs. This eliminates unnecessary tasks and promotes efficiency.
  2. Streamlining Communication: Miscommunication can lead to rework and delays. Attendants foster clear, effective communication among various parties, ensuring everyone understands the goals and requirements from the start. This reduces the chance of misunderstandings that can lead to unnecessary work and rework.
  3. Advocating for Simplicity: Attendants champion the philosophy that simplest is often best. They seek to develop solutions that meet everyone’s needs effectively without unnecessary complexity. This can drastically reduce development time, cut down on potential bugs, and increase the speed of product delivery.
  4. Preventing Over-Engineering: By maintaining a sharp focus on stakeholders’ needs and the simplest ways to meet them, Attendants help prevent over-engineering— the practice of making a product more complicated and/or feature-rich than necessary. This not only saves time and resources but also results in products that are easier to use and maintain.

Game Changer

Embracing the Attendant’s role and their commitment to maximising the amount of work not done can lead to more efficient, streamlined operations. It brings a focus on delivering value quickly and eliminating tasks that do not directly contribute to meeting stakeholders’ needs. In a rapidly evolving tech landscape, this approach is a game-changer.

Absence of Core Proficiencies and Business Acumen in Tech Businesses

In an increasingly digital world, understanding software and product development, as well as business acumen, is paramount. However, statistics indicate that a surprising 97% of managers and even 80%+ of developers lack a comprehensive, practical understanding of these areas. This disconnect negates their ability to successfully navigate and contribute to their organisation’s goals and purpose.

Despite occupying roles that necessitate people knowledge and strategic insight, many managers remain disconnected from the fundamentals of software development, leaving them ill-equipped to support their teams positively. Similarly, a significant proportion of developers lack an in-depth understanding of the development lifecycle, from design to deployment and maintenance, resulting in inefficient workflows, dysfunctional working relationships, and subpar products.

Furthermore, a limited understanding of business fundamentals can stunt an organisation’s growth. This is because it prevents individuals from appreciating the broader commercial context of their work, thereby leading to strategies that fall short of maximizing goal attainment.

The pervasive lack of understanding in these crucial areas highlights the benefits of diligent curiosity and lifelong experimentation.

The Fall of Agile Consulting and the Rise of Systems Thinking

In the shifting tides of the business landscape, staying afloat requires more than just clinging to the past. Twenty years ago, Agile consulting was the golden ticket, but now, that ship has sailed. Welcome to the era of Systems Thinking, where a holistic approach to business reigns supreme. Brace yourself for a journey into the next business revolution that’s taking the world by storm.

A Golden Era Passes

Two decades ago, in the early 2000s, the business world was going through a significant transformation of their approach to software development. Organisations were moving away from traditional waterfall (and ad-hoc) approaches and adopting Agile, shifting from a linear, sequential approach to a more iterative, collaborative one. Agile coaches, project managers, and consultants found themselves in high demand, guiding teams and organisations through the transition and reaping significant rewards. For these individuals, it was a golden era, as companies in all sectors scrambled to understand these new ways of working and better respond to change.

Terminus

However, as the saying goes, nothing lasts forever, and so it was for the Agile consulting boom. Fast forward to the present, twenty years later, and the Agile market has senesced. Most organisations are now familiar with at least the term. The consulting gold rush has tapered off; that particular gravy train has reached its terminus.

Paradigm Shifts

Today, the buzz is all about whole systems approaches and systems thinking. In this approach, businesses are considered as complex systems, an interconnected network of components rather than isolated departments or teams. This perspective encourages organisations to break down silos and consider the wider impact of decisions and changes, leading to more sustainable and holistic solutions.

With the rise of this new perspective, the focus has shifted from software and individual project management methods to an overarching, systemic focus. The challenge is now about understanding and managing complexity, facilitating interconnections, identifying feedback loops, and shifting paradigms.

Reinvention

Can the Agile consultants, coaches, Scrum masters, etc., of yesteryear evolve and learn to navigate this new landscape so as to remain relevant?

Inspect and Adapt?

In conclusion, trends come and go, and those who can adapt thrive. “Inspect and adapt”, anyone? Twenty years ago, Agile was the buzzword; today, it’s systems thinking. Who knows what the next twenty years will bring? It’s a constant reminder that the only thing consistent in business (and life) is change.

Note: If this post has given you cause for concern, I’m always happy to talk things through, one-to-one.

Agile and Beyond

Has the thought ever crossed your mind that you could be wrong, just plain wrong, about the whole Agile thing?

Ever found yourself musing on a quiet afternoon, over a comforting cuppa, if there’s a smidgeon of possibility you could be mistaken about Agile? That perhaps, despite all the hubbub, Agile wasn’t as marvellous an idea as you’ve pegged it to be?

As an observer now on the outside of your community, I can’t help but wonder at the sheer dedication with which you all have embraced Agile. However, every coin has two sides, and it’s not in anyone’s interest to overlook the flip side, is it?

There’s no shame in contemplating that members of the Agile community might’ve got it all arse about face. After all, progress lies not in being unerringly correct, but in learning from our miscalculations and adapting accordingly?

Feel free to comment your thoughts below or reach out privately if this little question has ever tickled your curiosity.

Here’s to open dialogue and continued learning!