For part 2: https://www.coveros.com/what-is-agile-part-2/
For part 1: https://www.coveros.com/what-is-agile-part-1/
Where I have seen agile implemented properly, practices were followed that were non-intuitive but effective. A couple examples will help:
It is a known statistic (2015 Chaos report) that the smaller the project, the higher the likelihood of success – by a significant margin.
” It was clear from the very beginning of the CHAOS research that size was the single most important factor in the resolution of project outcome.”
— 2015 Chaos Report
Relatedly, brain experts have shown that human minds typically have a small capacity for short-term memory, and do not function well with multitasking.
Therefore, agile promotes small teams, working on the simplest possible thing, on small timeframes. This means that it becomes possible to wholly understand a thing. Interactions with the team resembled that of dealing with a vendor and their product. The ethos is “small is beautiful”.
The minimum number of tools and frameworks are used, in order to remove cognitive load. Overloaded teams have a much harder time producing quality work than teams that are appropriately loaded. It turns out that software is actually a really hard thing to get right. By having more reasonable load, teams can focus on quality instead of quantity.
A second example: business experts have shown that team members who have a strong sense of empowerment and autonomy are likelier to have innovative solutions, and to have higher morale. Disenfranchised employees tend to have higher stress and lower morale, and burn out more often.
Therefore, per agile, teams are allowed to have significant autonomy with their environment and process. Keeping the overall company mission in mind, they often rebuke attempts to directly control their actions or tools, and they are supported in doing so. This stands in stark contrast to the typical command-and-control management style, wherein a manager gives an order and expects it to be carried out expediently, exactly as requested. Management of these agile teams required a nuance and appreciation for the productivity that results from empowerment.
These examples – smaller projects, simple work, and empowered teams, reflect several of the principles in the Agile Manifesto:
From the values:
- Individuals and Interactions over processes and tools
From the principles:
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
(See the Agile Manifesto for the entire list of 4 values and 12 principles)
Bundling these ideas together, taking them to their logical conclusions, and considering the supporting concepts, leads to agile.
Succinctly stated, and to repeat, agile is simply a name attached to a bundle of practices that have shown to be far superior in industry than the ideas that stemmed from early era industrial practice, which themselves originated from a culture of mass production and low-skilled factory workers. That simply doesn’t describe the work environment surrounding software development.
The question is: knowing this, how is it possible to jump the gap? The fact is, agile is a very sociological thing. It can only exist when the right combination of elements work together. Unfortunately those elements are rare and fleeting.
It has been my good fortune to have seen it functioning in its ideal state throughout an entire company – but that company was founded and run by a developer who believed in his people and in the tenets of Extreme Programming.
Separately, I have seen it come together on a team in a typical corporate environment, but the leader of that team was dealing with stress as a result of the contrast between the inside and outside cultures.
In both situations, agile eventually degraded into a lower form.
In the first case, the company grew larger and the founder sold it, leading to an organizational shift to traditional corporate governance. In the second, the team’s lead quit in frustration, and the subsequent manager had no inclination to maintain an agile culture, causing its loss.
It’s a rare thing to see real agile, and it requires vigilant tending and careful appreciation of the myriad aspects that make it up. In small ways, you can create pockets of good practices that can be very empowering. If you start or run a company, you have the chance to make those pockets into enduring company-wide cultures. But I won’t lie and say it’s easy. It’s a constant battle.
