Kill the Agile Manifesto!? Think Twice

The religious process djangos are the problem, not the Agile Manifesto.

Agile is everywhere. From drug development to the transformation of armed forces, everybody says they are doing agile.

Do you know where agile comes from? You’re right. Software development. The publication of the Agile Manifesto in 2001 was one of the turning points for agile software development. Its website still looks very 2001, but the core messages still hold:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

The Agile Manifesto is complemented with 12 principles of agile software, and a plea that the Manifesto is the basis for a conversation, and needs discussion and interpretation.

So far so good.

But let’s be honest: How “agile” is agile in your company? Let’s look at things that can go wrong.

Trap No. 1: Process Adherence at All Costs

The larger an organization becomes, the more processes there are. And when a process-heavy organization meets agile, things can go south. Some people speak of “dark agile”, which is why some cynical guys have created the Manifesto for half-arsed agile software development:

• Individuals and interactions over processes and tools — and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact

• Working software over comprehensive documentation — as long as that software is comprehensively documented

• Customer collaboration over contract negotiation — within the boundaries of strict contracts, of course, and subject to rigorous change control

• Responding to change over following a plan — provided a detailed plan is in place to respond to the change, and it is followed precisely

But they have a point. Lots of people claim they are doing agile, but they are still trapped in the old, linear world of processes.

Trap No. 2: No Changes During the Sprint

At Yonder, we follow the guidelines of Scrum to organize our product and development teams.

With a customer base that often changes priorities and brings up new requirements, we sometimes have to pull items into the current sprint to maintain customer satisfaction.

When this happens, people sometimes say that Scrum doesn’t allow changes to the sprint that would endanger the sprint goal.

Let me share a secret. There is a thing called reality. In the troubled times we are living in, priorities and goals can change multiple times during a sprint. Furthermore, priorities and goals are usually set by external factors you cannot control. So you will need to learn with changes to the sprint goal. What shouldn’t happen though is that changes to the sprint are made due to bad preparation, or that tickets get pulled into the sprint before they are properly specified and ready for development.

Trap No. 3: Not Involving the Business Team

Properly preparing tickets for a sprint sounds very easy, but it’s quite a laborious process that requires lots of discussion. The development team can only succeed if it is crystal-clear what they have to deliver — irrespective of whether you pull in a ticket during a sprint, or plan it well in advance.

Software is invisible, and that’s why lots of people on the business side cannot imagine or articulate what the software should do before it’s developed. So repeated discussions between the business team, the product team, and the development team are required before development work can start. And even after the development work has started, it might still be a good idea to keep the business team involved. Never forget that software is developed for customers, so the romantic idea of “throwing a ticket over the fence” and leaving the development team alone doesn’t work.

Conclusion

The religious process djangos are the problem, not the Agile Manifesto. So killing the Agile Manifesto is a bad idea. However, killing overly rigid processes is a good idea.

To take into account the dynamics of today’s world and the invisible complexities of software, there should be just one rigid process in agile software development: Never stop the discussion between the business team, the product team, and the development team.

Growing a company in troubled times is a marathon.

As a tech entrepreneur, active reserve officer, and father of three, I can help you with practical entrepreneurship and resilience advice for all aspects of life. To the point, no fluff, because entrepreneurs are busy.

When I'm not busy, I get my rest and inspiration in the beautiful mountains around Zermatt.

Join 100+ subscribers to receive my weekly newsletter for resilient entrepreneurs each Friday afternoon!

Join 100+ subscribers to receive my weekly newsletter for resilient entrepreneurs each Friday afternoon!