Cargo Cult Agile

Your team will have Sprints, with planning, estimation, review and retrospective meetings. There is a Scrum Master who will run these meetings. During planning the Product Owner will outline the tickets that need to be completed this Sprint. You will be using git, code reviews, pull requests, and ensure your code has unit tests. Sounds like the perfect Agile process doesn't it? Not necessarily. You might be doing Cargo Cult Agile.

What is a Cargo Cult?

Back in World War II the Americans arrived in the South Pacific and cut runways into various islands for aircraft to land on. The aircraft came with all kinds of goods that the indigenous people had never seen before. When the war ended and the Americans left the indigenous people thought that if they replicated the form of the runways planes would arrive with wonders onboard. So they cut runways into the forest and built towers to emulate the air control towers. Needless to say no planes full of cargo ever arrived.

So what is Cargo Cult Agile?

Cargo Cult Agile is when you follow the form of the processes without understanding and implementing the core philosophy of Agile, and expect excellent results. It is when you have all the ceremonies of Scrum for example, and use best practices in terms of software development hygiene, but fail to implement key Agile principles.

Specifically the key principles include rapid iteration and tight user feedback. The fundamental reason for this is that users are the ultimate fitness criteria for software. No matter how many unit tests software has if it does not meet the needs of users it is not high quality.

Do you have all the ceremonies of Scrum, but lack stories coming directly from users? Are your Sprints planned long in advance with specific features and deliverables? Is communication with actual users during development discouraged or impossible? If so you might be doing Cargo Cult Scrum.

From a cursory view it may look very similar to Agile, but in fact the Sprint has been co-opted into what is more like the waterfall model where each feature is delivered in a linear fashion with no opportunity input from users for refinement.

The Importance of User Feedback

In war no plan survives contact with the enemy. In software no plan survives contact with the user. When people actually use your software you will receive feedback to modify the software towards a better fit to user needs.

Waterfall was based on the idea that you can capture all the needs of the user, along with all the edge cases that come along with writing software for the real world, in a set of static requirements. You might see this in user stories that try to be too prescriptive, describing how to solve something rather than describing the problem to solve, or worse stories that are really just technical tasks, disconnected from users.

In a real Agile team users or user proxies are always available. We should be showing users how things look and getting their feedback with quick iterations. At the very least we should be showing a test version to beta test users before code makes it to production.

User Proxies

The reality is that often developers won't have direct access to users. Products with thousands of users cannot be based on the needs of a small number of users. In cases like this there needs to be a proxy for the user, someone who does have access to users, but is also a user themselves who has experience not only with the software but with the domain of the users. If you are writing health software seek out a health professional who will have a deep knowledge of the health industry. If you are writing software for a taxi service get a taxi driver or a taxi dispatcher. User proxies are not project managers, they are there to provide critical feedback to developers, and to help write user stories that make sense from a user point of view. This proxy is often called the Product Owner.

The job of the User Proxy is to engage with actual users, along with the business, to write the user stories. They are also there to negotiate with the development team in setting story priorities for each sprint.

Sometimes it is acceptable to have more than one user proxy. With internal software it may be each division of a company has different functionality and priorities. Each may write their own stories which are brought to planning meetings. And each one will be available to developers for input during development.

Rapid Iteration to Users

Are you releasing to users often? With Agile you need both selection and iteration. It is through both that adaptation occurs. Agile is all about fostering an evolutionary approach to development rather than faith in detailed up front design.

Change should be small and incremental, not large wholesale modification. Small regular changes that are tested by users will always be better adapted than large wholesale changes made on much longer time frames.

With Cargo Cult Agile the connection with users may be remote or perhaps not even present. Typically waterfall is based on requirements documents that is distantly related to users. The design documents will be based on the requirement documents, and the implementation based on design. Just like Chinese Whispers each stage of waterfall introduces the opportunity for error, omission and misalignment.

If you are not releasing often to actual users you won't be Agile, even if you are following other development practices which are beneficial. Without user feedback and iteration to users you are not employing the core philosophy of Agile.

Drivers of Cargo Cult Agile

It is possible to adopt systems like Scrum, with all the associated roles and meetings while senior management continues to treat teams in a traditional way, with fixed resources, fixed deadlines and fixed deliverables. Teams may adopt the form of Agile, the practices of Scrum, but continue to be treated like a waterfall project from above. With Agile the objective is to maximize business value, and to ensure tight alignment between resource investment and outcomes.

It does not mix well with arbitrary deadlines, fixed feature sets, and the kind of thinking where more detailed planning equals more certainty.

To adopt Agile it needs to be supported from the very top, from senior management. They need to understand how Agile works, and that the name of the game is adaptation over fixed project schedules with fixed deliverables.

The reality is that waterfall never was fixed schedule, fixed deliverables or well adapted to users. Schedule overruns always occur with waterfall because without robust user involvement there will always be a raft of modifications and bug fixes once code gets near production. This will blow out costs and schedule.

In other words if you try to do some form of waterfall approach you will fall into a form of evolutionary process anyway. So why not start that way, and exploit evolutionary mechanisms early?