Creating a culture of trust, ownership, and data-driven continuous experimentation that fosters sustainable growth and high-performance digital product teams.

In Part I, I explored some of the most popular software development methodologies (SDM) to explain why they often fail to improve our outcomes. In Part II, I will focus on The Infinite Loop, a new but not revolutionary (on purpose) SDM.

Note: This is going to be a long post! Please note that if you don't have time (or don't fancy) to read this much, the contents of this post are also available as a more concise slide deck.

4. 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 30 years: We need a new SDM that unifies the lessons from the past 30 years. Ideally, the new SDM 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 SDM should pick and use some of the components from previous SDMs. 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 SDM 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.

4.1 Sounds good but doesn't work

Trying to convince your organisation's management team to do things such as eliminating estimates and deadlines may seem out of touch with reality. My problem with this reaction is that I have experienced first-hand what it is like to work under these principles.

4.1.1 True leadership

While I was a Microsoft MVP, I had the honour to spend a little bit of time with Anders Hejlsberg, Daniel Rosenwasser and other members of their team. I witnessed what happens when a product team tick all the boxes: True leadership, trust, clear goals and strategy, product-led, customer-centric, pragmatic engineering approach that sees technology as a tool, not a goal. The key realisation I had while observing the TypeScript team at work was that having a clear mission, vision, and strategy was extremely powerful, so powerful that as long as you had it, you almost didn't need any project management overhead. All the members of the team were aligned like a high-precision laser. It was made up of missionaries, not mercenaries. This level of alignment is rare and is only achievable by true leadership. I also witnessed master levels of customer-centric and balancing technical debt with delivering customer value.

To be 100% fair, I must disclose that the TypeScript team operates under a Scrum-like methodology and have a quarterly release cadence. However, their version of Scrum was supercharged by the best parts of Lean UX, DevOps and product-led growth. The team performs nightly beta releases, high amounts of user research, and direct conversations with customers. The team also has a quarterly release cadence, but it didn't feel like a deadline because, by the time the release date was reached, the team had already mitigated 99.99999% of all potential risks.

4.1.2 Open-source

My open-source project (InversifyJS) had the following characteristics:

• Clear vision
• Transparency
• Trust
• Open collaboration with customers
• High autonomy (100% remote, async work, documentation)
• Organic release cadence
• No sprints (No estimates, No meetings, No time boxes)
• Deep customer understanding (for developers by developers)
• One team (there are no divisions or departments)
• High code quality
• High automation

The preceding should not be a surprise, as this is how most open-source projects operate.

While working on InversifyJS, I experimented with the power of some of these ideas first-hand:

• Lean UX: I was in direct contact with my customers; I had to deal with support queries, create documentation to facilitate onboarding, and discuss feature requests. Whenever a new feature request arrived, instead of thinking about the implementation complexities, the first question that I used to ask myself was: What would be the best possible developer experience for this feature? I would design the API to delight customers and ask them for feedback on GitHub issues.

• The three ways: If the feedback was positive, I implemented a few unit tests that invoked the yet-to-be-implemented API. As expected, the tests failed. Then I proceeded to implement the feature. As soon as the tests passed, I released a new version of InversifyJS. The code had 100% test coverage, and I could change the code with a very high confidence level. Sometimes I was able to deliver a feature that was requested just a few hours before.

• Clear vision and pragmatism: Sometimes, feature requests were super smart and easy to implement. I often asked myself: How did I not think about that before? Sometimes the features were good, but they added too much complexity. I learned to say no to my customers, that listening to customers and being reactive are different things, and that we need to listen to our customer's problems but not so much to our customer's solutions. I learned that vision and strategy are not just about what is OK but also what is not OK.

Today InversifyJS has over 100M downloads on npm and seeing my customer's delight was the most fulfilling professional experience of my career to date. At that point, I realised how much we miss when we are not part of a high-performance team.

Being part of a high-performance team doesn't mean being in a group under a lot of pressure; it means being in a team that is highly motivated to achieve a goal as a team. It means being part of a winning team. Being part of a winning team can feel very good. Winning can bring a sense of accomplishment, pride, and a positive self-image. It can also boost morale and increase motivation as team members work together towards a common goal. In a winning team, everyone's contributions are valued, and everyone feels a sense of ownership and responsibility for the team's success. This can lead to a strong sense of unity and a shared sense of purpose. Being part of a winning team can have a positive impact on an individual's well-being and can help to foster a sense of community and belonging.

I dream that one day the entire software industry will get a chance to experience this feeling, and I believe that we can make it happen. Now the choice is yours:

“You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in wonderland, and I show you how deep the rabbit hole goes.” - Morpheus

5. The infinite loop

The Infinite Loop doesn't try to reinvent the wheel; for the most part, it simply takes elements from other methodologies and software development principles.

The Infinite Loop proposes the creation of product-led teams that use a pull-based system and two backlogs with a focus on different but equally important objectives:

• Discovery: Contains tasks that aim to understand the business goals and user needs and design solutions to address their critical challenges before committing resources to development. However, this doesn't mean that development is not involved in the discovery phase. Developers should be engaged in direct conversations with the customer. Also, sometimes the only way to remove unknowns, especially technical unknowns, is to build a prototype that might require development resources. The goal is to ensure that we will build the right product by eliminating unknowns. When the product team gains enough confidence to commit, they work together to finalise a specification that can be included in the DevOps backlog.

• DevOps: Once users have validated our solution ideas, developers can implement the application. The development team is not pressured to hit an arbitrary deadline or an inaccurate estimate. At this point, our developers are perfectly aware of what they need to get done, they are motivated to deliver value to our customers, and we trust them and empower them to reach the right compromise between providing value and managing technical debt. The developers only need to leave them alone, so they get work done. They have a high level of ownership and are responsible for implementing, releasing and operating the code changes. They constantly search for ways to leverage automation to optimise their feedback loops and improve efficiency. The goal is to build the product right.

5.1 Why infinite?

The word "infinite" is used in The Infinite Loop to reinforce the idea that developing digital products is an infinite game. Developing a successful digital product is considered an infinite game because it is never truly "won." The goal of an infinite game is to keep the game going, with no clear endpoint and dynamic rules. This is in contrast to finite games, where the objective is to win and there is a clear endpoint with set rules.

In finite games, the focus is on winning, and this can lead to a weak sense of purpose. Organisations and individuals who play to win at all costs may sacrifice their values and relationships in the process, ultimately losing the game. This can lead to a culture of fear, where employees feel pressure to meet targets and achieve results, often resulting in burnout, low morale, and high turnover.

In infinite games, the focus is on maintaining the game and continuing to progress. There is a strong sense of purpose, and leaders inspire others to join them on a journey of unknown and infinite possibilities. A culture of trust and ownership, and a sense of shared purpose, is critical for achieving ambitious and long-term goals.

Treating the development of a digital product as a finite game is not possible in the long run because there is no clear endpoint and the rules are constantly changing. The focus on winning would eventually lead to burnout and a loss of purpose, ultimately hindering the success of the product. A more sustainable approach is to view the development of a digital product as an infinite game and focus on maintaining progress and continuously adapting to changes in the market.

5.2 A side note about the "Zone"

One of the goals of L∞P is to encourage the creation of work environments that facilitate a flow state. A flow state, also known as being in the zone, is a highly productive state of mind where a person loses track of time and is entirely focused on their work. This state is considered ideal for achieving maximum productivity and is often sought after by individuals and organisations. However, the average person experiences a flow state only rarely because their work environment and culture can often prevent it from happening.

To achieve a flow state, there are certain prerequisites that must be met:

• A strong sense of purpose and autonomy (powered by a culture of trust and ownership)
• Clear goals
• A minimal amount of unknowns
• Low levels of context switching and cognitive overload
• A minimum of 3-4 hours of quiet time each day

Having a team that regularly experiences flow state can greatly impact an organisation's success. Such a team is estimated to be 10 times more productive than an average team, making it a formidable weapon against the competition. Organisations need to create a work environment and culture that supports a flow state and maximises the potential of their employees.

5.3 L∞P Principles

L∞P proposed ten equally essential principles:

• Customer-Centric: Everyone should be in constant direct contact with customers, understand their needs, and be obsessed with delivering value to them.

• Value-Driven: The team is asked to deliver an outcome, not an output. The effectiveness and efficiency of the team is measured by the success of the customers, not by outputs (No Burn-down charts).

• Product-Led: Remove silos between marketing, sales, customer success, and the product team.

• Trust & Ownership: The product team is tasked with leading the customer to success and having total freedom to come up with the optimal solution.

• Flow-Friendly: There must be at least 50% allocated focus time on the calendar every day.

• No Estimates & Time Boxes: Use a pull-based system. Focus on one work item at a time. Discovery over planning.

• Explicit Policies: Use templates for agendas and artefacts to prevent deviation from your processes. Aim for self-reinforcing practices and principles.

• Clear Goals: The entire organisation should understand the business mission, vision, principles, and strategy.

• Data-Driven: The decisions, direction, and work items are backed by data.

• Pragmatic: making decisions based on what is best for the project rather than just optimising for individual preferences or technical ideals.

5.4 L∞P Roles

"If you want to go fast, go alone; if you want to go far, go together" - African proverb

L∞P tries to balance collaboration and working as a team, so we can attempt to achieve goals that are bigger than ourselves (go far) with focus and alone time so we can get into the zone and be super productive (go fast). When we work together, our goal should be to remove unknowns and enable autonomy; then, we can go our separate ways and get stuff done.

The L∞P team structure is designed to ensure all disciplines are aligned and work without silos. Instead of having separate teams for product development, sales, marketing, and other functions, there is one cross-functional team in charge of discovery and development. This team integrates with sales and marketing by aligning goals and strategies around the product.

• The Product Manager is a key role in this structure, taking on both the roles of product owner and scrum master. The Product Manager is responsible for leading the team and making decisions that impact the product, as well as ensuring that the product is delivered on time and within budget.

• Sales is another important role in the team, responsible for identifying and closing deals with potential customers. The Sales team works closely with the Product Manager to understand the customer needs and ensure that the product meets those needs.

• UX plays a crucial role in the product-led growth organisation, responsible for the design and usability of the product. The UX team works closely with the Product Manager and Engineering to ensure that the product is easy to use and meets the customer's needs.

• Architecture and Engineering work together to build and maintain the product, ensuring that it meets the technical requirements. The Architecture team is responsible for creating the blueprint for the product, while the Engineering team implements the design.

• Marketing is responsible for promoting the product to the customer, and is an integral part of the cross-functional team. The Marketing team works closely with the Product Manager and Sales to create a marketing strategy that aligns with the product goals and supports the product-led growth strategy.

5.5 The product manager (PM)

The role of the project manager is the most critical one in the product team. The PM is often seen as the proving ground for future CEOs, as the success or failure of a product falls on their shoulders. It's therefore important that the PM role is reserved for the best talent, with a combination of technical expertise, deep customer and business knowledge, credibility among stakeholders, market and industry understanding, and a passion for the product.

A PM must be smart, reactive, and persistent, with a deep respect for the product team. They should also be comfortable with using data and analytics tools to inform their decisions and drive the success of the product. The PM's main task is to ensure that only the most valuable work items reach the backlog, guiding the product team towards building solutions that deliver the greatest impact and customer value.

In addition to the PM role, the PM is also often responsible for the product owner role, ensuring that the product backlog is always aligned with the product vision and strategy. They must have a strong understanding of customer needs and market trends, and be able to work closely with the development team to prioritise work items and drive the product forward.

5.6 L∞P Artefacts

In this section, we are going to take a look at the L∞P Artefacts. We will mention common artefacts from other methodologies, clarify why we will not use them, and introduce some new ones.

• ✅ Mission and vision: The product mission and vision should be clearly articulated and documented. The team should not only know what the product aims to be but also what it is not aiming to be.

• ❌ Product backlog: We don't use a Product backlog because we use ✅ Discovery and ✅ DevOps backlogs instead. We do this to reinforce the idea that experimentation and discovery are fundamental steps replacing estimation and planning.

• ❌ Sprint Backlog: We don't use a Sprint Backlog because we don't use time boxes. We use a pull-based system. We use a Work board and Work-in-progress limits to track our current focus.

• ❌ Definition of done: We don't use a definition of done (DoD) because it is not a concept open for interpretation. Done means live and used by actual customers.

• ❌ Product Increment: We don't use a Product Increment because we don't accept the idea of something being "potentially releasable". We release everything; if we are not going to release it, we don't build it.

• ❌ Sprint goal: We don't use a Sprint goal because we don't have time boxes but also because our metrics are already focused on outcomes.

• ✅ Explicit work policies: We use Explicit work policies to ensure that nobody corrupts or deviates from our principles.

• ✅ User stories: We use User Stories, but we are careful to avoid including specific implementation details or technical requirements (WHAT) to keep the focus on the user's needs and goals (WHO and WHY). Stories should keep the focus on the user, enable collaboration and drive creative solutions

• ✅ Outcome metrics over ❌ output metrics: We don't use Output-based metrics like Burn-down & Burn-up charts, Lead time, Cycle time and Cumulative flow diagrams because they make people focus on outputs, not outcomes. We use outcomes-based metrics instead, like Activation Rate, Retention Rate, Lifetime Value (LTV), Net Promoter Score (NPS), Feature Engagement, Cohort Analysis & A/B Testing, Change Failure Rate, Employee satisfaction surveys, Employee turnover rate. We are careful with the activation rate because we understand that retention rate is a more reliable metric for customer value.

5.7 L∞P Ceremonies

In this section, we are going to take a look at the L∞P Ceremonies. We will mention common Ceremonies from other methodologies, clarify why we will not use them, and introduce some new ones.

• ❌ We don't use Sprints because A sprint is a time box, and we believe that time boxes lead to decreased quality and lower customer value, so we don't have any Sprint-based meetings. Including ❌ Sprint planning, ❌ Sprint review and ❌ Sprint retrospective. However, we value the principles behind the Sprint retrospective. We host a monthly ✅ Operations review meeting to reinforce a continuous improvement culture. This meeting also replaces the Service Delivery Review meeting from Kanban.

• ❌ We don't host the Delivery planning and Risk review meetings from Kanban because they strongly focus on outputs.

• ✅ We host as many User research/testing sessions as needed to validate hypotheses and generate product ideas. The entire team participates in the research phase, sales and development included.

• ✅ We block 4 hours daily in people's calendars to ensure they can get into the zone and move fast. We call this the Do Not Disturb (DnD) meeting.

• ✅ We host a daily stand-up meeting, but we use meeting agendas to ensure they don't become a checkpoint. The goal is to provide the team with clear goals and autonomy for the rest of the day.

• ✅ Every Monday, we host a Replenishment meeting to evaluate if we should bring more tasks from the discovery and development backlogs into the board.

• ✅ We host a monthly Show and Tell meeting to enable conversation across teams, share research insights, and celebrate our achievements.

• ✅ We host monthly hackathons to encourage the development team to generate product ideas and reinforce the involvement of the developers in the discovery phase.

• ✅ We host quarterly Strategy review meeting to align the product teams with the leadership's mission, vision and strategy.

5.8 L∞P and the future of work

In this section, we will learn how some of the core principles in L∞P can prepare organisations for some of the biggest trends in the future of work.

5.8.1 A trust culture prepares organisations for Remote Work

A culture of trust leads to a sense of ownership because trust creates a foundation of mutual respect and understanding between employees and their managers. When employees feel trusted, they are more likely to feel valued and appreciated, which can increase their sense of belonging and commitment to their work. This sense of belonging and commitment can then lead to a sense of ownership. When employees feel a sense of ownership, they take pride in their work and feel more responsible for its outcome. They are more likely to go above and beyond their job requirements, take initiative, and be more creative in their problem-solving.

In turn, this sense of ownership can lead to increased autonomy. When employees feel that they have a level of control over their work and are trusted to make decisions, they are more likely to feel empowered and motivated. This autonomy allows employees to work more efficiently, as they are able to make decisions and take actions without having to constantly seek approval from their managers. Additionally, when employees are given autonomy, they are more likely to feel valued and respected, which can lead to increased job satisfaction and engagement.

Therefore, having a culture of high trust is crucial for effective remote work as it creates a positive work environment that encourages ownership and autonomy, leading to increased employee motivation and productivity.

5.8.2 A data-driven culture prepares organisations for the adoption of AI

Having a data-driven culture prepares organisations for the adoption of AI** by emphasising the importance of data collection, analysis, and informed decision-making. Organisations with a data-driven culture value data as a key asset and have processes in place for data management and analysis. This creates a foundation for successful AI implementation as AI relies on large amounts of accurate and high-quality data for training and decision-making. Additionally, a data-driven culture can foster a more analytical and evidence-based approach to problem-solving, making it easier for organisations to evaluate the potential impact and limitations of AI solutions.

5.9 Scaling the infinite loop

This section will look at strategies that can help organisations scale their operations under the L∞P framework.

5.9.1 Multiple product teams

You can create multiple product teams with different focuses. The following list details some of the most common strategies:

• User personas: Create one team for each UX persona. For example, you can have one team focused on making the product great for startups while you have another focused on helping large multinationals.

• Subsets of features: If your product has different modules, this could be a promising approach for your organisation. For example, imagine that you are developing an end-to-end CRM solution. You could have a module for customer support and another for sales or marketing. You could have one product team for each of the modules.

• Stages: The stages here refer to phases in a customer's lifetime. Different product teams could focus on each of the following stages:

  • Acquisition: This step is dedicated to attracting and acquiring new customers.
  • Activation: This step is dedicated to converting newly acquired customers into engaged and loyal ones.
  • Retention: This step is dedicated to keeping its existing customers satisfied and engaged so that they continue to do business with the company over a long time.

5.9.2 Loop of Loops (LoL)

Loop of Loops (LoL) can be used to coordinate and manage the dependencies between multiple Infinite Loop teams working on a large, complex project. It is a way to scale the Infinite Loop beyond a single team to handle the communication, coordination, and integration challenges that arise when multiple teams work together. The Loop of Loops typically involves the PMs from each Infinite Loop team meeting regularly to discuss and resolve cross-team dependencies.

In this approach, the PMs communicate what their teams are working on, what they need from other teams, and what roadblocks they are facing. This helps to ensure that all teams are aligned on the project goals and are making progress towards the same end goal. The Loop of Loops also acts as a forum for cross-team coordination and problem-solving. For example, if one team is blocked on a certain aspect of the project, they can bring the issue to the Loop of Loops meeting to find a solution with the help of other teams. The Loop of Loops is also a place for sharing information and updates, such as customer insights and changes in priorities.

5.9.3 Platform engineering

A platform engineering team is a group of software engineers, developers, and other technical experts who are responsible for building and maintaining the technical infrastructure that supports the development and deployment of software applications. The primary goal of a platform engineering team is to create a stable, scalable, and efficient platform that enables other teams within an organisation to build and deploy applications quickly and reliably.

A well-functioning platform engineering team can bring several benefits to an organisation, including:

• Increased efficiency: A platform engineering team can streamline the software development process by providing a stable, scalable, and efficient infrastructure for building and deploying applications. This can help reduce development time and improve the overall efficiency of the software development lifecycle.

• Increased innovation: By providing a solid foundation for software development, a platform engineering team can free up other teams to focus on innovation and new initiatives, which can help an organisation stay ahead of the curve and maintain a competitive edge.

• Improved reliability: By implementing best practices for platform design, maintenance, and operations, a platform engineering team can ensure the reliability and stability of the platform and reduce downtime for applications.

• Enhanced security: A platform engineering team can implement robust security measures to protect sensitive data and prevent security breaches, which can help protect the reputation and credibility of the organisation.

• Scalability: A well-designed platform can be scaled easily to accommodate the changing needs of the organisation, which can help the organisation stay ahead of the curve as it grows and expands.

The scope of a platform engineering team's responsibilities may vary depending on the size and needs of an organisation. Some common tasks and responsibilities of a platform engineering team include:

• Designing and implementing a scalable and highly available infrastructure for hosting applications.

• Building and maintaining a continuous integration and deployment (CI/CD) pipeline for software development.

• Developing and managing platform services, such as databases, caching systems, and messaging queues, to support the needs of applications.

• Implementing security measures, such as authentication, authorisation, and encryption, to ensure the confidentiality and integrity of data.

• Monitoring and optimising the performance of the platform and applications running on it.

• Providing support and guidance to other teams that are building applications on the platform.

6. What next?

These two posts are the very first iteration of The Infinite Loop. My goal is to develop something with enough maturity and well-documented enough to gain some industry adoption. I'm aware that this is a mammoth task but trying is free!

My first goal was to put it out there. My next goal is to get as much feedback as possible. Please use the comments or complete this survey to help me take this idea further.

Thanks for reading!