Skip to main content

What is the philosophy of L∞P?

In this section, we will share what we believe are the root causes of the inefficiency and ineffectiveness of the software industry and the principles we believe should guide us while attempting to solve these problems.

Why are we still failing?​

Answering this question is a big challenge. Our collective failures cannot be attributed to a single cause. The following list contains the main reasons I believe are preventing our industry from achieving a greater rate of success:

The success of Scrum is holding us back​

Scrum has done many good things for our industry, but, at this point, it is probably holding us back. Many organizations use Scrum to describe themselves as Agile despite a total lack of agility and disastrous implementations of Scrum.

Many Scrum professionals argue that these failures are due to a lack of understanding or weak leadership, not the methodology itself. However, it is time to acknowledge the mainstream nature of failed implementations of Scrum as an indicator of something fundamentally wrong with Scrum.

The outcomes of the Software industry could have been better if Scrum had been versioned and upgraded. I would love to have something called "Scrum 2023" that introduced changes such as "story points are now deprecated".

The time for a new software development methodology has arrived. As we have already learned, according to the Standish Group's CHAOS Report, the success rate of software projects increased between 1994 and 2015 but has decreased since 2015. The main reason behind this decreased may be that Scrum is now failing to cope with the increasing complexity of software. Organizations prefer sticking with broken Scrum implementations over trying something new because cultural transformations are risky and expensive, but broken Scrum implementations are making software professionals feel disengaged and miserable. It is time we demand our organizations ditch Scrum.

Leadership is not leading the cause​

The leadership team often says they are fully committed to making the organisation more Agile. Still, the reality is that they can't let go of their old Waterfall ways:

  • Lack of a clear vision and mission
  • Lack of trust
  • Estimation and planning are valued more than discovery
  • Outputs are valued over outcomes

Metrics & practices that fail to reinforce principles​

You have to be careful with what you measure. If you measure something, the organisation's members will change how it operates to hit the desired metrics. Our metrics and practices fail to reinforce our principles and often go against them. We must use metrics and practices that strengthen and promote outcome-oriented behaviours instead of output-oriented ones.

Sales and marketing are setting the product team up for failure​

The sales and marketing teams often make unrealistic promises when the organization fails to deliver value, and customer acquisition and retention start to suffer. The product team is tasked with an impossible mission that leads to further disappointment, increased technical debt and lower quality.

Technology should be a tool, not a goal​

Seeing technology as a goal (not a tool) is a symptom of a lack of pragmatism.

How do we fix this?​

The following list contains some of the main actions I believe we must take to solve the problems described in PART I.

"Kill" Scrum​

Scrum has helped us to learn a lot, but it is time we move on. We need a new methodology that learns from the scrum ease of adoption.

Unify lessons from the last few decades​

We need a new software development methodology that unifies the lessons from the past 30 years. Ideally, the new software development methodology will self-reinforce its own principles:

  • Less planning and more doing (Agile)

  • Experimentation over planning and estimation (Lean UX)

  • Customer-centric and data-driven (Lean UX)

  • Increase ownership and remove silos to achieve agility (The three ways)

  • Align the sales, marketing and product teams (Product-led)

No need to reinvent the wheel​

The new software development methodology should pick and use some of the components from previous software development methodologies. We shouldn't need to come up with a completely revolutionary set of artefacts, ceremonies and roles. I acknowledge that there is a risk of confusion by reusing some components. Still, at the same time, familiarity could facilitate adoption, and nothing will change without adoption.

Facilitate adoption​

We have learned that extensive documentation, success stories, certifications and a high level of prescription facilitated the adoption of Scrum, especially within larger organisations. We should follow Scrum's steps when it comes to facilitating adoption.

Maximise trust & ownership​

Trust leads to ownership. Ownership leads to agility & autonomy. When you combine agility & autonomy with "Do not disturb time", you are setting the perfect conditions to achieve Flow. As we will see later, Flow is an estate of mind in which we become super focused and achieve high performance. There are many ways we can try to establish a culture of trust:

  • Set crystal clear product mission, vision and strategy

  • Provide employees with the resources and authority to make decisions and solve problems independently

  • Providing flexible work arrangements

Minimise disconnection between principles and practices​

One of the main problems with Agile methodologies is that the leadership team doesn't fully commit to the Agile principles. Some of the artefacts and ceremonies in an software development methodology can sometimes be misinterpreted or lead us in the wrong direction. For example, if we use the Burndown chart as a core metric, we can become too focused on outputs and deadlines, sacrificing customer value and quality. There are three things that we can try to prevent this from happening:

  • Implement practices that self-reinforce our principles: An example of self-reinforced practices is standing up during the stand-up meetings. This idea reinforces that the meeting should be short. We could design new artefacts, ceremonies and roles that self-reinforce our principles. For example, having a discovery backlog reinforces having an experimentation phase before anything gets into the development backlog.

  • Implement practices that are close for interpretation: Weakness in leadership means that our principles are under a constant threat of corruption. I have frequently encountered startup CEOs who have difficulty committing the word "Minimum" in Minimum Viable Product (MVP). One simple but effective way to solve a problem like this is to encourage the usage of Minimum Marketable Feature (MMF) over MVP. Simple changes like this have the potential to remove the temptation to deviate from our principles. More drastic actions like eliminating deadlines and estimates might be the only way to mitigate the change-resistant that frequently prevents Agile transformation from succeeding.