What Agile is Not
or at least what it was never meant to be
Agile is not:
1. A Better Way to Estimate
Building software is unpredictable. Agile practices mitigate this fact by establishing teams and software that can quickly and easily adapt to changes. So when something unexpected happens or something takes longer than it should, you know how to respond. The key is to respond to what is happening now, not predict what will happen in the future — “Responding to change over following a plan“1. Trying to plan everything out ahead of time is called Waterfall. We tried that already. It tended to produce rigid projects that ran past deadlines and exceeded budgets.
That’s why the agile manifesto asserts that “working software is the primary measure of progress.”2 It does not say that progress is measured by counting all the Jira tickets (and their estimates) in the backlog because that would be Waterfall again. In fact, when your backlog represents more work than the next sprint or two, it’s no more than a good-old-fashioned attempt at upfront planning — and your burndown charts are nothing more than the gantt charts of old.
The agile manifesto does not mention anything about estimates or burndown charts or story points, because agile processes don’t waste time on these things. They are not what agile is all about. Agile is a departure from this mentality - a bold declaration that estimation is not only a waste but promotes behaviors and processes that make you less agile.
2. Set in Stone
Sadly, if your experience is anything like mine, you’ve noticed that the actual tolerance for process change in most organizations is next to zero. Management is certainly open to suggestions about how to be more efficient in their system, but the process itself is untouchable, sacrosanct.
This rigidity is antithetical to the agile philosophy, where teams are “self-organizing”, where “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly,” where projects are built “around motivated individuals” who are trusted “to get the job done,”3 and most of all, where “individuals and interactions” are valued over “processes and tools,” and “responding to change” is valued over “following a plan.”4
When agile teams own their process they change it however they need. They are not forced to standardize with everyone else in the organization. And they are not forced to utilize any specific tool. Such autonomy in process allows them to respond to change — to be ‘agile’. There is no one-size-fits-all process and you should be suspicious of anyone that claims otherwise. The most terrifying words in the English language are: I am Scrum certified and I am here to help.5
3. A Way to Isolate Developers From the Customer
With the advent of Scrum came the advent of a new product role: the Product Owner. Product owners are product specialists that do not spend time with the sales and marketing teams but are instead inserted into each engineering team. Their mandate is to represent the voice and the mind of the customer.
While this alone is a reasonable duty, in Scrum, product owners assume a secondary obligation as well. They own and maintain the engineering backlog. The engineering backlog is a list of all planned work from adding buttons to dialog boxes all the way down to writing and modifying code. By owning the backlog, product owners are forced to manage and prioritize engineering details they are unqualified to understand. You can probably guess how well this works out.
As an engineer, it is wonderful to have access to a product specialist who can communicate vision, give feedback or answer customer related questions. It is especially useful when they can arrange for engineers to meet directly with potential and existing customers. However, when product specialists decide how/when new classes or functions are written or whether or not it is time to refactor difficult lines of code, it is time to politely escort them out of the kitchen. Their presence only serves to distract the cooks and decrease the quality and timeliness of the coming meal.
Worst of all, the way that Scrum conceives of the relationship between engineers and product specialists is fundamentally flawed. In Scrum, the product owner solves customer problems, and engineers, like factory workers, take those solutions and simply implement them.
While it may seem like sparing engineers from customer related details will keep them focused on what they do best, in reality it deprives them of the most crucial details of their work. Software Engineers need to understand the domain they work in. They need to feel the pain they are trying to eliminate. It is the only way they can leverage their unique capacity to automate difficult or tedious tasks, to come up with necessary creative innovations. Product owners may know what it broken, but they do not know that landscape of possible ways to fix it.
It is true that product specialists are the best judges (after the actual customer) of the value of proposed solutions, but it is the Software Engineer that is most qualified to provide those solutions. This is the most healthy relationship between product and engineering. Where Scrum would have programmers merely be construction workers, in the best reality, they are the architects as well.6
ttps://agilemanifesto.org/
https://agilemanifesto.org/principles.html
https://agilemanifesto.org/principles.html
https://agilemanifesto.org/
A paraphrasing of Ronald Reagan’s statement https://www.goodreads.com/quotes/34152-the-most-terrifying-words-in-the-english-language-are-i-m) “The most terrifying words in the English language are: I'm from the government and I'm here to help.”
To better understand why this is the case, read: https://www.developerdotstar.com/mag/articles/PDF/DevDotStar_Reeves_CodeAsDesign.pdf