As a long time Agilist, the spread of Fake Agile is a sad thing to see.
Constant refactoring is a core Agile practice! https://martinfowler.com/bliki/OpportunisticRefactoring.html
When I worked closer to production the people at the workshops also cleaned and repaired their equipment every evening, crunch time or not. They didn’t just let their machines die long term because it may buy some time in the short term to skip maintenance.
Better to just incorporate refactoring into the estimate for any given coding task and do it without explicit permission. Unless of course you're in a culture that is willing to straight up miss a deadline in order to get refactoring finished.
It should be as implicit as attending planning meetings. For some reasons PMs usually have no problem forcing people to sit through meetings but they have a problem with spending the same amount of time refactoring .
I like including refactoring in tickets, but if the refactor is consequent it's not going to work. It's not so often thankfully, I usually manage to convince the PO of the value of it, then try to not budge once it's decided
Occasional there is a bigger refactoring project, but that's my normal day.
"That wasn't true Agile" is starting to sound about as credible as "That wasn't true Communism."
Best methodology: Self-organizing teams of experienced, expert engineers. Let them develop whatever process works best for the individual team and project.
That requires two things:
1. Hiring the right people.
2. Trusting them.
The difference is that many people have worked on highly functional "real agile" teams and can tell the tale.
> Best methodology: Self-organizing teams of experienced, expert engineers.
Minor quibble: While that is of course the best scenario, it can also work quite well with a few experts guiding the less experienced. Pair programming works wonders here.
If your team is all inexperienced newbs, I don't know what can save your project :)
> Regardless of whatever that term originally meant, this is what it means now.
Perhaps. I have no interest in debating word definitions though.
Sure, but is it really the "agility" or the people making the difference?
The highly functional teams I've worked on either ignored or satirized the elements of Agile development (e.g. the "story" format, story points, any sincere effort at estimation poker) to get out of those discussions as quickly as possible. This probably bears some similarity to how the original "Agile" developers dealt with the preceding methodologies.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
So based on your description those teams were Agile in the sense meant by the manifesto.
The great Agile teams I was on had really good people on them. So, sure, they might have done great work in other environments.
Then again, this was the methodology they chose.
It also sounds like the teams you describe picked their own way of developing, which, in a Big Picture sense, is all the Agile Manifesto says: Let the team control their own work, and get out of the way.
Which, in a lawyerly and annoying, but still kinda true way, makes that team agile too :)
That’s what “Agile” is when you read the Agile Manifesto.
It seems every reasonable methodology quickly gets perverted by leadership to a top down, dogmatic dictatorship caricature of itself. Happened to OOP, Agile, will probably happen to FP. You could argue that what Lenin and friends did in Russia was also not what Marx had in mind.
But we have story points, epics, scrums, retros etc. Agile is very much more than that.
Most “no true agile” posts are really “no true scrum” because the issue is firmly in process and methodology rather than underlying principles.
In fact I’d say Scrum itself whilst designed to meet the principles doesn’t actually do so in practice.
Scrum as a base methodology isn’t too bad either but as always management prefers precise plans and a lot of Agile consultants are happy to feed that. Saying “let people make up whatever process they want” is actually quite profound because it often goes complete against what management wants.
If this is clear and understood, congratulations, you basically understand the gist of the French historian Michel Foucault's criticism of modernity (it supposes origins and progress when no such thing actually exists, so how do we talk about politics, history, ethics?), a criticism which would go on to inform all of contemporary Left politics, including contemporary progressivism and identity politics.
> Although there are places for some scheduled refactoring efforts, I prefer to encourage refactoring as an opportunistic activity, done whenever and wherever code needs to cleaned up - by whoever.
That is how I personally view refactoring as well. Its like a necessary sanitation ritual to keep things tidy like doing the laundry or the dishes but far more rewarding knowing that the change is more than mere maintenance, an improvement that simplifies things. Refactoring shouldn't require a scheduled event, but its the quantity of scheduled events that is visible and reinforced by the system.
1. Story points are only intended as a prognosis tool. If we produce 14p/week on average, we'll probably work through this 80p block in 5-7 weeks.
That's it.
When you start using it to evaluate teams or individuals, Goodhart's law sets in, and it all turns to garbage.
2. The reason you don't count refactoring or bug fixes as points is that they don't add user value. If you spend all your time fixing bugs you created earlier, you are not being productive to the customer. It's easy to get caught up in polishing your toys instead of delivering things the customer is paying for.
Though what's often unstated/forgotten ignored, is that refactoring and leaving the code in at least as good a shape as you found it, is an integral part of what calling a story "done" should mean.