Archive

Tag Archives: 3366ff

Mummery

In the realm of software development, we often witness a curious spectacle: the performance of rituals and practices that, whilst appearing productive on the surface, amount to little more than elaborate pantomime. This phenomenon, which we might dub ‘mummery’, has deep roots in the industry’s power structures and misaligned incentives. Let’s delve into the causes of this theatrical approach to software development, with a particular focus on the tension between management and the boots-on-the-ground developers and testers.

The Management Muppet Show

The Illusion of Control

At the heart of many mummery practices lies management’s desire for control and predictability in an inherently unpredictable field. This manifests in the imposition of rigid processes that often fail to account for the nuanced, creative nature of software development.

Case in Point: The Scrum Straitjacket

Many a developer has found themselves forced into the constraining embrace of Scrum, not because it’s the best fit for their project or team, but because it provides management with the comforting illusion of progress through burndown charts and velocity metrics. The result? Daily stand-ups that feel more like status reports to appease the powers that be, rather than collaborative problem-solving sessions.

The Metrics Mirage

In their quest for quantifiable progress, managers often grasp at metrics that are easy to measure but may not reflect genuine productivity or quality.

The Story Point Saga

Developers and testers frequently find themselves pressured to assign story points to tasks, engaging in estimation exercises that feel more like crystal ball gazing than scientific measurement. The root cause? A managerial need for ‘data’, even if that data is fundamentally flawed.

The Compliance Charade

Ticking Boxes, Missing the Point

Many mummery practices stem from a culture of compliance, where the appearance of following best practices trumps actual effectiveness.

The Code Review Ritual

While code reviews are invaluable when done properly, they can devolve into perfunctory checkbox exercises. Developers, under pressure to meet deadlines, may perform cursory reviews, leaving substantive issues unaddressed. The root cause? A management culture that values the appearance of quality processes over their substance.

The Agile Theatre

Agile methodologies, originally intended to empower developers, have in many organisations become a top-down mandate, stripped of their original flexibility and purpose.And owned by the management, not the workers (as was the original intent).

The Sprint Planning Pantomime

Developers and testers often find themselves participating in sprint planning sessions where the ‘plan’ has already been decided by management. The root cause? A fundamental misunderstanding of Agile principles, coupled with a reluctance to relinquish control.

The Innovation Illusion

Buzzword Bingo

In an industry that deludes itself that it’s being constantly innovative, there’s immense pressure to appear cutting-edge. This can lead to the adoption of trendy technologies or approaches without proper consideration of their actual value.

The Microservices Mania

Developers may find themselves forced to refactor perfectly functional monolithic applications into microservices architectures, not because it’s necessary, but because management has bought into the hype. The root cause? A fear of appearing outdated, combined with a misunderstanding of when and why to adopt new architectures.

Breaking Free from the Mummery

Fostering Authentic Dialogue

To combat mummery, organisations need to create safe spaces for honest communication between management and development teams. This involves:

1. Encouraging developers and testers to provide feedback on processes without fear of retribution.
2. Educating management on the realities of software development, including its inherent uncertainties.
3. Emphasizing outcomes over output, focusing on delivering value rather than adhering to rigid processes.

Embracing True Agility

Rather than imposing Agile practices from the top down, organisations should empower teams to adapt methodologies to their specific needs. This might mean:

1. Allowing teams to experiment with different approaches and learn from failures.
2. Focusing on the principles behind Agile rather than rigidly adhering to specific practices.
3. Recognising that different projects and teams may require different approaches.

Surfacing Shared Assumptions and Beliefs

One of the most insidious causes of mummery in software development is the presence of unexamined, often conflicting assumptions and beliefs about how work actually happens. To combat this, organisations might choose to actively surface and reflect upon – through e.g. dialogue – these underlying assumptions and  beliefs:

  1. Conduct Assumption Archaeology: Regularly hold sessions where team members, including management, developers, and testers, articulate their beliefs about how and why work gets done. This might reveal surprising differences in perspectives, such as:
    • Management assuming that productivity is directly proportional to hours worked, while developers know that creative problem-solving often happens during downtime, and away from the desk.
    • Testers believing that catching bugs is a sign of their effectiveness, while developers might see it as a failure of their process.
    • The role of Quality and the purpose, practices of “QA”.
  2. Create a Shared Mental Model: Once assumptions are surfaced, work together to create a shared understanding of the software development process and its place in the wider business. This might involve:
    • Mapping out the actual flow of work, including informal processes and communication channels that may not be part of the official methodology.
    • Identifying points of friction or misalignment between different roles’ perceptions of how work should proceed.
  3. Challenge the “Should” Mentality: Encourage questioning of established practices by asking “Why do we do this?” rather than assuming “This is how it should be done.” This can help distinguish between purposeful processes and mere theatre.
  4. Recognise the Complexity of Knowledge Work: Consider whether software development is not a linear, predictable process that many assume it is. Help all stakeholders to participate in this dialogue.
    • Creative breakthroughs can’t be scheduled.
    • The most valuable work often can’t be easily quantified or tracked.
    • Learning and experimentation are essential parts of the process, not just “wasted” time.
  5. Align Incentives with Reality: Once there’s a shared understanding of how work really happens, adjust incentives and metrics accordingly. This might mean:
    • Valuing quality and customer satisfaction over lines of code or story points completed.
    • Recognising and rewarding collaborative problem-solving rather than individual heroics.
  6. Continuous Reflection: Implement regular retrospectives not just on the work itself, but on the team’s evolving understanding of how they work. And on the assumptions and beliefs shared across the organisation. This keeps the conversation about shared assumptions alive and prevents new forms of mummery from calcifying.

By actively working to surface and align assumptions about how work works, organisations can choose to create an environment where mummery becomes not just unnecessary, but glaringly obvious when it does occur. This shared understanding forms the foundation for genuine, effective practices that respect the realities of software development.

Conclusion: Dropping the Act

The prevalence of mummery in the software industry is a symptom of deeper issues: conventional management and its category errors about the nature of the work, misaligned incentives, a lack of trust between management and development teams, and a misunderstanding of the creative and unpredictable nature of software development.

By addressing these root causes, we can begin to shed the costumes and scripts that hinder genuine productivity and innovation. It’s way past time for both managers and developers to step out from behind the curtain, adopt relativey effective shared assumptions and beliefs, and engage in authentic, effective ways of working. Only then can we experience the joy of delivering true value, rather than merely acting out the role of productive software teams.

High-performance Organisations Use These Shared Assumptions as a Basis For Their Policies

High-performance organisations stand out for their ability to adapt, innovate, and consistently deliver exceptional results. At the core of their success lies a set of shared assumptions and beliefs that form the basis of their policies and practices. Let’s delve into some of these key assumptions and explore how they contribute to organisational excellence.

Connecting with What’s Alive in People

High-performance organisations recognise that their most valuable asset is the relationships amongst and between their people. By focusing on folks’ needs and aspirations, these companies create an environment where individuals can thrive and contribute their best work.

Who Influences Our Decisions and Priorities?

Understanding the stakeholders who matter most is crucial for making informed decisions. Top-performing organisations have a clear grasp of whose input carries weight and use this knowledge to shape their strategies effectively.

The Collective Psyche of the Organisation

Successful companies cultivate a collective mindset that aligns with their goals and values. This shared mental model helps guide decision-making and fosters a sense of unity among team members.

A Clear Definition of Organisational Success

High-performance organisations have a well-defined concept of success that goes beyond mere financial metrics. This holistic view of achievement helps drive alignment, sustainable growth and long-term value creation.

Organisational Culture: The Invisible Force

Culture is the invisible force that shapes behaviour and drives performance. Leading organisations invest in creating and maintaining a culture that supports their objectives and empowers their workforce.

The Structure of the Organisation

Innovative companies understand that organisational structure can either hinder or facilitate success. They design flexible structures that promote collaboration, agility, and rapid decision-making.

Coevolution: Adapting to Change

In a rapidly evolving business landscape, high-performance organisations embrace the concept of coevolution. They continuously adapt their collective assumptions and beliefs to stay in step with organisational changes and market dynamics.

Human, and Humane, Relationships

Building strong, positive relationships within the organisation is a hallmark of high-performance companies. They foster a culture of trust, respect, and open communication that enhances collaboration and productivity.

Remuneration: Beyond the Pay Cheque

While competitive salaries are important, leading organisations understand that remuneration goes way beyond monetary compensation. They develop comprehensive motivational systems that align with their values and enable employees to excel.

Conclusion

In conclusion, high-performance organisations leverage these shared assumptions – and others, see my books Quintessence and Memeology for a full and detailed list – to create a dynamic, adaptable, and successful business environment. By focusing on human needs, cultivating a strong culture, and embracing change, these companies position themselves at the forefront of their industries and drive sustainable growth.