Many Agilist writers and methodology creators make strong assumptions about organizational culture for Agile approaches to be successful. I’ve described some examples of these assumptions in The Lake Wobegon Assumption and Scrum applicability by project characteristics and reference Becoming Agile by Greg Smith & Ahmed Sidkey as a prime example. But these instances shouldn’t surprise us given that the principles supporting the Agile Manifesto are explicitly software product centric and do not refer to general business principles or needs.
Consider the first principle, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software,” and the third principle, “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Are these principles self-contradictory? What if the customer doesn’t want continuous delivery because the cost of continuously changing their business is too high or the constant change too disruptive to efficient operations? Why should we assume that the rhythm of businesses should be dictated by their software development cycles even when software is not their product?
Similarly consider the fourth principle, “Businesspeople and developers must work together daily throughout the project.” What if that presents too great a burden on business operations?
Finally, consider the seventh principle, “Working software is the primary measure of progress.” Is that true for all organizations or just for software product development organizations? Why should we assume that the primary measure of progress for a company be based on anything other than their product or service offerings, the satisfaction of their customers, and profitability for their stakeholders?
Unstated as a principle, yet tacitly a part of every debate on the benefits of Agile vs. Plan-based development, Agilists reject the business management expectation that software can or should be developed to a defined schedule. Instead, they provide processes that incrementally build software without any ability or intent to determine when a required body of software will be complete. More precisely, the requirement is replaced with an ability to deliver something of some expected value, although the specifics are uncertain until the end, in short, time-boxed releases. Agilists defend this outcome by indicating that plan-based approaches seldom deliver to their initially defined schedules and so seem to conclude that one should give up entirely on predicting when a software product will be complete. Unexamined and unresolved in this context is the genuine need for planning supporting activities related to the release and adoption of a software product to enable revised business operations based on the new software capabilities.
Also unconsidered in these debates is the idea that plan-based approaches are enabled to refine schedules incrementally based on new information. The concept of the “cone of uncertainty” describes an ability to create increasingly accurate schedules as more information is gained and suggests iteratively replanning based on refined information. Plan-based approaches often do this at intervals defined by progress or completion of interim deliverables. While imperfect in its ability to forecast accurately early in software development, it at least provides business management with a probabilistic ability to plan activities that must follow from software development and to forecast with increasing accuracy when those activities can take place. Plan-based project management methods have had the opportunity to schedule based on the cone of uncertainty since the early 1980’s. Early Agile methodologies like Scrum adopted the approach of iteratively replanning without ever providing a forecast of completion. Later Agile methodologies like SAFe provide some ability to forecast in larger “program increments,” although still without the ability to plan around full product completion.
With these examples in mind, we return to these key questions. Why does Agile assume that we need to remake businesses in its image? How is that customer focused? If, as the twelfth principle states, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly,” (emphasis added) then why can’t Agile adapt itself to customer organizations and cultures?
