Please Think Responsibly

The daily standup, the sprint planning meetings and the t-shirt sizing are all signs that you have an agile organization right?  They went through the motions too:

A cargo cult is a belief system among members of a relatively undeveloped society in which adherents practice superstitious rituals hoping to bring modern goods supplied by a more technologically advanced society. …. The name derives from the belief which began among Melanesians in the late 19th and early 20th centuries that various ritualistic acts such as the building of an airplane runway will result in the appearance of material wealth, particularly highly desirable Western goods (i.e., “cargo”), via Western airplanes

I love agile and if done right it is an incredibly powerful tool for building software.  It allows for iteration and flexibility when the final outcome is not necessarily known.  It is an important tool, and like all tools, needs the right application.  It is well suited for building tools where the process of building is important for the process of discovery.  Cooking is agile, baking is not.  Software is agile, bridges are not.

That said, I have only ever worked for one company that did development using an agile methodology.  Most companies aren’t, and you probably aren’t.  If I had to guess, you and your teams are going through the motions of agile with the same words and ceremonies but I’d guess that you have some sort of hybrid between agile and waterfall where goals need to be defined ahead of time and shifting focus is considered a change request.

You can change this by going back to the principles first laid out in the agile manifesto.

1. Individuals and interactions over processes and tools – The best products are effortless to use.  You can achieve this by 1) starting with the customer and working backwards 2) Being your own editor to ensure that your product does exactly what the customer needs – nothing more, and nothing less and 3) Focusing on creating a frictionless experience.  End users don’t have the time or attention to learn something new so the the easier it is to understand and use, the most likely it will be adopted (regardless of how slick the business case looks).
2. Working software over comprehensive documentation – Shipping software is the goal – the process isn’t.  I once worked at a company that had a rigorous process for application design.  First, a UX designer made wireframes.  Next, a visual designer took the wireframes and created visual compositions.  Finally, the two deliverables were sent over to the development team which promptly ignored them and did their own thing.  The thing is, the development team was the team that actually made the software, everyone else was just making pictures.  The company spent an incredible amount of money building images that collected dust on a desk.  We were able to increase our development velocity by 3X and reduce our overhead 2X when we decreased the team size and focused on building working applications.  Of course, you can over index the other way.  Most companies use the Minimum Viable Product (MVP) mindset as an excuse to do a sloppy job.  If you are light on documentation, and sloppy on implementation you aren’t going to have working software and won’t accomplish your goals.  The goal is “working software” not “software”.
3. Customer collaboration over contract negotiation – If you treat all stakeholders as customers you can create a new business partnership where shared goals can be accomplished together, rather than trying to negotiate or make concessions.  Ultimately many pieces of software are designed by committee rather than with the customer in mind and a meeting full of managers making concessions to further their careers on their team is the worst way to design something the customers love.
4. Responding to change over following a plan – The flexibility provided by an Agile methodology is the key to unlocking value.  Organizations are inherently allergic to this because it creates uncertainty and organizations are biased toward predictability (hence the endless planning and roadmap cycles).  If you need to create a business case and project brief in order to even consider moving forward with a project it doesn’t matter how many sprints and stand-ups you have, you are not agile.  Embracing the ambiguity and planning for flexibility are key to using agile most effectively and will allow for an organization that moves at the speed of customers.

Is agile even right for your product?  Use the pace layering model to understand the type of project you are working on and to determine the right development methodology.  Agile is best used by innovation projects and differentiation projects that need to move quickly in order to keep up with a quickly changing market place driven by customer tastes.