The biases of the Agile Manifesto and Agility

The Agile Manifesto, published in February 2001, is 23 years old. It was essential for changing the way we make software.

It was created and signed by 17 people who had some things in common: They were all men, white, and software developers at on-demand software development consulting companies.

I’m also a white man, so I don’t feel qualified to talk about possible biases that this lack of diversity may have caused to the Agile Manifesto.

However, I worked my entire career for more than 30 years with software development at companies that built digital products, that is, that had internal software development teams to develop and maintain products that were used by the company to achieve its strategic objectives while solving problems and needs of your customers.

That’s why I say that the Agile Manifesto has a strong process bias. That’s why the manifesto says:

We are uncovering better ways of developing software by doing it and helping others do it.

Note that the focus is on “discovering better ways”, that is, a clear focus on the process.

If it were rewritten as follows:

We are uncovering ways of developing better software by doing it and helping others do it.

The focus becomes not only the process but also the result of this process, the software, which is the digital product. And this is the focus of product management.

I reaffirm the importance of the Agile Manifesto and its values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Without this, it is impossible to make good software.

However, to help us increase the chances of delivering successful digital products, we must also have a Product Culture with its 4 values:

• Deliver early and often: you can’t want to innovate and make new products by making monthly or quarterly deliveries of code.
• Focus on the problem: understand the problem well and only then think about possible solutions. Test different hypotheses to see which solves better and faster.
• Result delivery: what a product development team has to deliver are results. Product, app, feature, algorithm are not the goal, they are means to deliver results. When we talk about delivering results, we are talking about delivering results for the company, which owns the software, and for the software user, who wants to have her problem solved or need met.
• Ecosystem mindset: it’s the focus on the customer, only with a boost. Every company has more than one customer, and you need to understand these different types of customers and their relationships.

Which are the complement to help us deliver increasingly better software.

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products