Agile won. The practices encouraged by Agile transformation coaches the world over are practiced the world over. I do not remember a software team in the last decade who did not gather around for their regular standup meeting. A team who did not drag Jira stories across a board, in standard “as a user” format. Who did not have Jenkins builds kicked off by every commit. Who did not ignore, if not actively block, attempts to explain how their software worked with long sentences and UML diagrams.
Oh No It Did Not.
Agile lost. The values and principles ignored by those coaches and consultants are ignored by the teams who learned from them. Ignored because they were not relevant: the coaches said “successful teams do this” so we do this. They did not say “successful teams believe this, therefore they choose to do this”, so we do not believe.
My Engineering Organization Is Agile
On some teams I have worked with, that standup is weekly, or fortnightly. It is only for “the team”, which is engineering and their manager. They sometimes “invite” somebody from “the business” to join. Particularly when they want to blame “the business” for not giving clear requirements.
It is an interesting phrase, “the business”, especially when used by engineers to label the group of non-engineers in the organisation. It implies that everybody else is engaged in getting customers and making money, while engineering is a cost centre funded presumably through altruistic motives.
But here is the thing. Had they not heard of agile, that team would not even have fortnightly standups. They would have trickledown briefings from their manager, who would get their information from their own manager. So the team is more connected with each other and its work. Agile won.
Again
I have been on teams where yes, there is a nightly build, but it usually fails, and is never in a state where we would want to show it to a customer. The question is whether it failed more than last night, and whether the tasks to fix things will get done before the ship date.
Had they not heard of agile, these teams would not even have that level of insight into the quality of their software. The build expert would do the build in the “integration phase”, after feature complete but before code complete. Only then would they discover the failures. Agile won.
And Again.
I have worked on teams where the work is organised as user stories in a Jira board, and the product owner is expected to think of all the stories upfront. The stories should be in priority order by the time the engineers see them, should be in the standard format, and should have clear acceptance criteria in Given-When-Then format. Do not call it a functional specification, but that is what it is.
The “team” (by which I mean the loudest person on the team) critiques the backlog once per sprint, in a grooming session. While “grooming the backlog” may seem like an elaborate ritual in which a Tudor monarch has their turds cleaned, it is in fact…well, it is that, without the monarch. Engineers complain that stories are too big, under specified, or too risky. Highly important stories are deprioritised in favour of easy, comprehensible, deckchair-rearranging tasks that got lower values in the Arbitrary Fibonacci Sweepstakes.
Had they not heard of Agile, none of this discussion would happen. The whole backlog would be signed off at the start, then the whole team would enter the death march until either everything gets finished, or exasperated managers fire the lot of them. Agile won.
“Agile” “Project” “Management”.
This is the issue on being a senior developer, so why am I talking about agile? Agile is a set of values, principles, and practices for making software, not a project management framework.
In fact, in most situations, the agile software development values seem antithetical to the existence of projects. We do not want to scope a project, because we respond to change over following a plan. Our team will not write a statement of work, because we collaborate with customers over negotiating contracts. We will not write down the requirements, because working software is better than comprehensive documentation.
Pushing a second layer of “in fact” onto the stack, the agile manifesto does not say any of that. It says we value comprehensive documentation, following a plan, negotiating contracts, and processes and tools. What it says is that there is more value in working software, responding to change, customer collaboration, and individuals and interactions.
Agile Software Construction.
As a senior developer, a significant part of your role is to set expectations for how the software team and the experts in the rest of the organisation interact, and indeed to take a lead on that interaction yourself. You are a role model for the junior developers, and you are the point of contact for people from other departments.
If you want your team to run its project a certain way, or not as a project at all, it is your responsibility to take the lead. You must embody the principles you wish to see, and encourage the practices that support those principles. Whether your team is real agile, trademark Agile, or fauxgile, is on you.
In Theory, The Theory Works.
Agile software development started life as all of these things: as values (probably similar to the four in the manifesto), principles (the twelve that are below the fold on the manifesto website) and practices (see XP, Crystal, FDD, DSDM). All of these things exist today, but in different concentrations.
As Alan Francis once said to me, an idea is like strawberry jam. As you spread it, your strawberries stay in big lumps and your jam goes everywhere. Agile is like a three-tiered strawberry jam: practices are easier to see and adopt than principles, which are in turn easier than values. So we have plenty of people who have adopted practices they have learned about from “agile”, and maybe see the principles, even where they do not share the values. I still argue that they are better off than they were before, and that those of us who use software are better off as a result.
Conclusion
Agile software development has nothing to do with project management. It has everything to do with a defining set of values and principles that can guide you in making software. How you get there is up to you, and the people you work with.
If this is a disappointingly damp take on agile for you, then agile has won! Given two decades, it has moved the needle on the industry so far that an idea that was once shocking and controversial is now something everybody does. Even if they do not agree how and do not know why. Now the context is different, so it is time to tell new stories that help the people who are stood here, not the people who were there in 2000.
Cover photo by Holger Link on Unsplash.
