Archive

Product development

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

Unappreciated Product Development Skills

Introduction

In the world of product development, hiring for the right skills is paramount. Yet, hiring managers and HR people often fail to appreciate the necessary core skills, and thus certain crucial skills often go unsought, overshadowed by more flashy competencies or specific technical abilities. While technical expertise is a nice to have, ignoring these unappreciated skills can lead to teams and departments that lack cohesion, struggle with efficiency, and miss out on a broader understanding of the development landscape.

Top Ten Overlooked Skills and Their Consequences

#SkillHiring Consequences
1The Importance of the Way the Work Works, incl subsidiarity.Teams lack a holistic view, leading to systemic issues and an inability to see beyond their immediate tasks.
2Risk ManagementTeams are reactive, rather than proactive. This leads to crisis management scenarios and frequently derailed release schedules.
3Role of VariationProjects may frequently miss deadlines or go over budget due to a lack of preparedness for uncertainties.
4Flow OptimisationTeams face frequent bottlenecks, resulting in uneven workloads, delays, and heightened stress levels.
5Feedback LoopsProducts misaligned with user needs or market demands due to a reluctance or inability to seek or respond to feedback.
6Systems ThinkingTeams operate in silos, leading to redundant efforts, inflated costs, delays, poor quality, and a fragmented product experience.
7Value Stream MappingMisaligned priorities, arising from a focus on tasks without understanding their overall product value.
8Make Things VisibleLack of transparency resulting in miscommunications, overlooked issues, and poorly informed decisions.
9Limiting Work in Progress (WIP)Overall productivity and work quality decrease due to excessive multitasking and constant context switching.
10Attending to Folks’ NeedsNeglecting this skill results in disengaged or unmotivated teams, decreasing engagement, discrationary effort and productivity, and increasing turnover rates.

Conclusion

To create a well-rounded and effective software development team, hiring managers migh choose to look beyond just technical proficiencies. By recognising and valuing these often-unappreciated skills, companies can increase the likelihood of building and maintaining cohesive, efficient, and innovative teams equipped to tackle the multi-faceted challenges of modern product development.

As the product development landscape continues to evolve, sadly, appreciation of the essential skills required to navigate it does not. Is it yet time to give these unappreciated competencies the recognition they deserve in the hiring process and beyond?

Offer

If your organisation suffers from any of the maladies listed under “consequences” in the table above, get in touch today for clear, independent advice on steps you can take to tackle the skills shortfall: bob.marshall@fallingblossoms.com

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

Velocity: Is It Really the Key to Faster Product Development?

In the fast-paced world of product development, time is often considered the most valuable asset. The need to bring products to market faster has given rise to a growing emphasis on development velocity. Companies are investing in tools, methods, and practices to make their development cycles shorter. But is engineering velocity – speed in a given direction – really the panacea it’s often made out to be? Is it even a valid metric? Let’s take a closer look.

What is Engineering Velocity?

Engineering velocity refers to the speed at which a product team completes work items, such as features, bug fixes, or other deliverables. It’s often measured in terms of story points, completed deliverables, or other similar units within a given time frame.

The intention behind tracking this metric is clear: it’s a way to quantify progress and, ostensibly, efficiency. However, the pursuit of velocity for its own sake can lead to some serious pitfalls.

The Fallacy of Velocity as a Metric

Velocity as a metric has many shortcomings that make it not only pointless but sometimes even detrimental when it comes to product development.

  1. Quality vs. Quantity: By focusing solely on the speed of development, there’s a real danger that quality can suffer. Cutting corners to increase velocity may lead to more bugs, technical debt, and products that don’t meet the needs of the Folks That Matter™.
  2. Misleading Measurement: Velocity is often tracked using arbitrary units, like story points, which can vary greatly between teams and even within a single team over time. This lack of standardisation makes velocity an unreliable metric for comparison or prediction.
  3. False Sense of Progress: High velocity may give a sense of progress, but it doesn’t necessarily mean that the right things are being built. Teams may rush to complete tasks that don’t align with strategic goals or the needs of the Folks That Matter™, leading to wasted effort and resources.
  4. Impact on Team Morale: Emphasising velocity may lead to unnecessary pressure and stress within product teams, affecting collaboration and creativity. This can result in burnout and ultimately slow down the delivery process.

An Alternative Approach: Needs over Velocity

The key to successful product development isn’t necessarily moving faster; it’s moving smarter. Here’s what organisations might choose to do instead:

  • Focus on the Needs of the Folks That Matter™: Prioritise features and deliverables that best attend to the needs of the Folks That Matter™. Regularly gather feedback from these consitituencies to ensure that development efforts are aligned with folks’ real-world needs.
  • Emphasise Quality: Building quality products will lead to satisfaction and loyalty. Invest in e.g. ZeeDee and continuous improvement to ensure that quality is never sacrificed for speed. (Interestlingly, it’s a little appreciated fact that speed increases in proportion to improvements in quality).
  • Leverage Self-organisation: Implementing Auftragstaktik-derived practices can help teams adapt quickly to changing requirements and focus on delivering value incrementally. Emphasising collaboration, adaptability, trust, and continuous improvement can lead to accelerated product development and delivery.
  • Encourage a Healthy Culture: Foster an environment where team members feel supported and empowered. Recognise that creativity and innovation often take time and wilt under an overbearing stress on speed.

Conclusion

Engineering velocity might seem like a logical solution for bringing products to market faster, but it’s not a one-size-fits-all metric. In many cases, it’s misleading, counterproductive, and even harmful. Instead, companies might choose the smarter path:focusing on attending t folks’ needs, delivering value, ensuring quality, embracing adaptability, and building a positive team culture. By adopting these principles, organisations can develop products that not only reach the market more quickly but also resonate with the Folks That Matter™, stand the test of time, and ultimately contribute to long-term success.

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

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!

“Not Everybody Matters”: A Bold Approach to Streamlining Software Development

💡 Need to unlock your team’s full potential and supercharge your software development process? Uncover the game-changing strategy behind embracing “Not Everybody Matters”, and learn how mastering the Needsscape and understanding the Cost of Focus can catapult your project to success! 🎯💥🚀

➡ In the world of software, service and product development, catering to every stakeholder’s needs can be both challenging and resource-intensive.

Embracing the idea that “Not Everybody Matters” can lead to more effective development processes by prioritising the most critical needs and stakeholders. By focusing on the essential elements of a project, teams can allocate resources more effectively and reduce development time.

The Needsscape
The Needsscape is a concept that helps identify and dynamically prioritise the needs of various stakeholders. By carefully tracking the Needsscape, development teams can determine which needs have the most significant impact at any given moment, and align their efforts accordingly. This approach acknowledges that not all needs are equally important, and allocating resources to meet every need regardless of relative impact leads to increased costs and inefficiencies.

The Cost of Focus
The Cost of Focus is the trade-off that occurs when concentrating on one are over another. By acknowledging that “Not Everybody Matters,” development teams can make informed decisions about where to invest their time, effort, and resources. This approach might involve prioritising features that have the highest value for the majority of users or focusing on the needs of specific subsets of the audience.

The concept of “Not Everybody Matters” in software development is a bold approach that encourages teams to prioritise the most critical needs and stakeholders by leveraging the Needsscape and understanding the Cost of Focus. By doing so, they can streamline the development process, maximise the value delivered, and ultimately create more successful software products.

How Peter Drucker’s Vision Has Yet To Transform the Workplace

💡 Imagine a world where creativity and collaboration reign supreme, where the collective minds of diverse individuals come together to generate ground-breaking ideas. Dive into the revolutionary perspective of Peter Drucker, the visionary who described a new way of collaborating that proposes we turn traditional work on its head.

➡ When it comes to Peter Drucker and his views on work and collaborative knowledge work, it’s really interesting to see how he differentiated between the two. Drucker is widely regarded as the “father of modern management,” and he had some pretty insightful ideas about work and the ways people collaborate.

In Drucker’s view, traditional work is more about performing tasks and following procedures. Think of an assembly line worker, a farmer, or a craftsman. They’re doing their jobs, completing specific tasks, and usually working independently or with minimal interaction with others. This kind of work focuses on individual productivity and efficiency.

Now, when we talk about collaborative knowledge work, Drucker had a different perspective. He saw this as a way of working that involves people coming together, sharing ideas, and creating new knowledge. It’s less about following a set process and more about being creative and adaptive in solving problems. In this type of work, the interactions between people are really important, and the goal is to combine their expertise and knowledge to create something new and valuable.

So, the key difference between the two, as Drucker saw it, is the way people work together and the focus on generating new knowledge. While traditional work is more about individual tasks and efficiency, collaborative knowledge work emphasises teamwork, creativity, and innovation.

Isn’t it fascinating how Drucker’s ideas from decades ago still hold up today? It’s like he had a crystal ball for understanding how work would evolve over time! Maybe his vision will one day come to pass.

 

Some Reasons Why You Might Choose To Pay Attention To My Works

Hey there! I’m Bob Marshall, the Organisational Psychotherapist, with a passion for helping organisations transform their culture and improve collaboration. If you’re wondering why you might choose to pay attention to my insights, just let me say that my unique approach can bring profound benefits to all kinds of organisations, especially those involving collaborative knowledge work.

My blog at https://lnkd.in/dytkA2A is packed with insights and stories from my five decades of experience. I draw on this experience, including founding Europe’s first 100% Agile software house and heading Falling Blossoms, the world’s first Organisational Psychotherapy provider. My posts highlight the importance of nurturing productive relationships and fostering a people-oriented culture.

One post that stands out is about the Antimatter Principle, which emphasises attending to folks’ needs to create a thriving, collaborative work environment.

Another post discusses Flow•gnosis, an innovative approach to developing software-intensive products and services.

When you read my posts, you’ll also learn from my decades in both technology and business, including roles at Sun Microsystems, and many other organisations, large and small. This deep understanding of the tech landscape allows me to provide invaluable counsel and therapy to ambitious, progressive technology and digital business organisations.

Moreover, those who have worked with me have nothing but praise for my approach and the results it has brought to their organisations. Time and again, I’ve helped clients create a more humane, people-oriented, and productive work environment that has led to outstanding success.

As the author of “Hearts over Diamonds”, “Memeology”, and “Quintessence”, and the originator of Rightshifting and the Marshall Model, my posts regularly and freely share the foundational knowledge that has contribute to the success of so many of my clients. So, if you want to see a real difference in your organisation, don’t miss out on the wisdom and insights shared on my blog, books, white papers, etc.

Join me on this transformative journey towards elevating your organisation’s performance, and also creating a meaningful, fulfilling work environment that nurtures innovation, everyone’s personal growth, and long-lasting success. Get down with the opportunity to be part of a paradigm shift that’s redefining the way businesses thrive!

🔔🔔🔔🔔

Don’t miss out on the latest insights and strategies for transforming your organisation and its culture! If you find this post valuable, make sure to follow me on LinkedIn, and don’t forget to ring the bell 🔔 to receive notifications whenever I share new content. Ready to unlock your organisation’s full potential? Take action now and reach out for a chat, or visit my blog more transformative ideas. Together, let’s embark on this journey towards unprecedented success! 🔔

And Now For Something Completely Different…

Have you thought about what lies beyond the Agile horizon? Well, it’s something completely different. Companies are now shifting focus towards systems thinking and addressing whole-organization issues. With the changing demographics of the workforce, it’s essential that companies adapt accordingly. It’s no longer about processes, but about embracing culture changes to truly thrive in this dynamic landscape. Companies need to foster a more joyful, inclusive, and collaborative environment that promotes engagement, innovation and adaptability. Exciting times ahead, right?

 

Software Development: It’s Not Even Slightly About Tech Skills and Coding Practices

💡 What’s the undervalued secret sauce of software success? You’re in for a wake-up call as we reveal the overlooked ingredients that make or break software success in the business world.

➡ Blimey, it’s no surprise that most execs – those few that are even slightly interested in software development – reckon it’s all about tech skills and coding practices. But I’ll tell you, there’s more to this picture than meets the eye. Sure, being a dab hand at coding is somewhat useful, but in the context of business operations, it’s just the tip of the iceberg.

You see, the nitty-gritty of software development, especially in a business setting, also involves top-notch communication, teamwork, and adaptability.

And let’s not forget, building strong interpersonal relationships is a piece of cake for no one, but it’s a skill developers need to master to keep things from going pear-shaped.

A good understanding of the customer’s needs and the company’s goals is also crucial. After all, you can’t score a winner if you don’t know where the goalposts are. So, execs might choose to realise that there’s more to software development than just cranking code. And much more to hiring than the recruitment of code toads.

A successful software development team is the whole package. It’s not just about having a bunch of coding whizzes; it’s also about fostering a culture where everyone’s on the same page, working together as a community to bring work to fruition. Otherwise, businesses might find themselves up a creek without a paddle.

Beneath the Agile Mirage: Unmasking the Lipstick-Smeared Swindle of Modern Software Development!

💡 Prepare to embark on a thrilling exposé, where we unravel the tangled web of Agile’s alluring illusion, and reveal the startling truth lurking beneath its glossy veneer – a revelation that will leave you questioning everything you thought you knew about software development!

➡ You know, there’s an old saying that goes, “You can put lipstick on a pig and call it Agile, but it’s a waste of your time and annoys the pig.” It’s such an apt description of the Agile approach to software development, don’t you think? I mean, people talk about how Agile is the be-all and end-all solution to software development woes, but in reality, it’s just one big lipstick-covered pig.

Even when organisations follow Agile to the letter, it never seems to work out as expected. The whole system is supposed to be about flexibility and adaptability, but so often it just ends up being a convoluted mess. Sure, you have all these meetings, sprints, and stand-ups that give the appearance of progress, but it’s really just a bunch of people running in circles.

And let’s not even get started on the endless stream of buzzwords and jargon that’s constantly thrown around in Agile environments. It’s like some twisted game of corporate Mad Libs that doesn’t actually result in any tangible improvements.

So yeah, you can slap a coat of Agile lipstick on your development pig, but don’t be surprised when it doesn’t magically transform into a streamlined, efficient machine. More often than not, you’ll just end up with a frustrated pig and a whole lot of wasted time.

The Future is Now: Unleashing the Full Potential of Cutting-Edge Software Development Culture

For software developers, understanding the role of business culture in the development process can seem entirely irrelevant. Yet, business culture sets the tone for the company’s shared assumptions and beliefs about how work should work, and it can have a significant impact on the efforts, and quality-of-life of software developers.

One example of where the impact of business culture is particularly visible is in the thorny question of permitting or forbidding developers to talk with users and customers.

In many organisations, the relationship between software developers and users/customers is seen as strictly separated. In such cases, developers are not allowed to communicate with users/customers, and all communication is done through customer support teams or business analysts. This is primarily driven by the belief that developers cannot be trusted, and must focus solely on the technical aspect of the product, leaving customer interactions to others.

However, in some organisations, the opposite is true. Developers are actively encouraged to engage with users and customers, and they are seen as a vital link between the technical side of the product and the needs and desires of the customers. This approach is often driven by a culture that values transparency, customer satisfaction, and continuous improvement.

The impact of these differing business cultures on the role of software developers is significant. When developers are not allowed to talk to users/customers, they are limited in their ability to truly understand the customer’s needs and desires. This can lead to products that are technically sound but miss the mark when it comes to user experience and customer satisfaction. On the other hand, when developers are encouraged to talk to users/customers, they are more likely to create products that are not only technically sound but also meet the needs and expectations of the customers.

It is important to consider how changing the business culture can change the nature of what developers are allowed to do.

In conclusion, software developers play a crucial role in the development process, and it can help to understand the impact of business culture on their efforts. The question of permitting or forbidding developers to talk with users and customers is just one example of how business culture can impact the development process. By considering the impact of business culture and making changes as necessary, companies can ensure that their developers are empowered to create the best products possible and drive better business results.

Revolutionise Your Development: The Benefits of Ditching Version Control

Avoiding the use of version control in software development may seem like a daunting task, but there are several advantages to doing so.

First, it can save time and resources. Without version control, developers do not need to spend time committing changes, merging branches, or resolving conflicts. This can lead to faster development and fewer delays in the project.

Secondly, avoiding version control can also simplify the development process. With fewer tools and processes to worry about, developers can better focus on the needs of the Folks That Matter™, and on meeting those needs. This can lead to improved customer satisfaction, fewer bugs and a more streamlined development approach.

Thirdly, avoiding version control can also lead to greater flexibility in the development process. Without the constraints of version control, developers can work on code in any way they see fit. This can lead to more creative solutions and a more efficient development approach.

Lastly, avoiding version control can also lead to greater collaboration among team members. Without the need to constantly merge branches, developers can work on different parts of the codebase at the same time, leading to faster development and a more efficient workflow.

In conclusion, while version control is a powerful tool in software development, there are advantages to avoiding its use as well. By doing so, developers can save time and resources, simplify the development process, increase flexibility, and improve collaboration among team members.

Unlocking the Secrets of the Heart: How Emotioneering is Revolutionising the Way We Create New Products

Emotioneering is a term coined by marketing expert Martin Lindstrom in his book “Buyology” to describe the use of neuro-marketing techniques to tap into consumer emotions in order to increase product appeal, revenues, and profits. While the concept of using emotions to sell products is not new, the use of neuro-marketing techniques such as functional magnetic resonance imaging (fMRI) and electroencephalography (EEG) to understand consumer emotions is a relatively new concept.

Despite the potential benefits of emotioneering, it appears that many companies are not yet using these techniques to increase their product appeal, revenues, and profits. There are a few reasons for this.

First, the use of neuro-marketing techniques is relatively new and not yet well understood by many managers and executives.

Second, many managers and executives may not see the value in investing in emotioneering as they may not understand how it can benefit their business. They may not be aware of the potential impact that emotions can have on consumer behavior and may not realise that tapping into consumer emotions can lead to increased product appeal, revenues, and profits.

Finally, some managers and executives may be hesitant to use emotioneering because they are concerned about the ethical implications of using neuro-marketing techniques to manipulate consumer emotions. They may be worried that using these techniques could be seen as unethical or manipulative, which could damage their company’s reputation.

Despite these challenges, it is likely that the use of emotioneering will increase in the future as more companies become aware of its potential benefits and as the spread of neuro-marketing techniques increases. This will help to alleviate concerns about the ethical implications of emotioneering and will ensure that companies are able to use these techniques to increase product appeal, revenues, and profits in a responsible and ethical manner.

Waiting In The Wings

What’s going to the next big thing in terms of approaches to software delivery? And when might we expect the transition to that next big thing to become apparent?

“The future’s already here – it’s just not evenly distributed.”

~ William Gibson

The Days of Agile Are Numbered

We can argue about how much life the Agile approach to software delivery has left in it. What’s beyond dispute is that there will be something after Agile. And I propose it will  look much different from Agile. I find it inconceivable that Agile is so perfect that there’s no room for improvement. Even though – ironically, give the exhortations to “inspect and adapt” – many in the Agile supply chain don’t want to talk about it AT ALL. Why rock the boat and derail the gravy train?

Customers and users, however, are waking up to the inadequacies of presently lauded approaches. And current upheavals in organisations, such as remote working and the scramble for talent, are accelerating these folks’ dissatisfaction.

Holding You Back

What’s prolonging the transition towards any new approach? Basically, it’s the prospect of the serious pain that comes with the adoption of effective new approaches. SAFe’s transient popularity illustrates how many organisations prefer an ineffective approach, with the illusion of change, rather than an effective approach that actually brings benefits. Any significant uplift in software delivery and product development performance implies a much different approach to running technology organisations, including, not least, different styles of management.

Your View?

What’s your view? What promising new approach(es) do you see waiting in the wings? And if there’s nothing with a recognisable name or label, what characteristics will a new approach have to have to boost it into consideration?

– Bob