I always get nervous when “refactoring” shows up on the backlog and then gets deprioritized. In my mind it should never show up as a separate task and then it should never get ignored . It should just be a normal part of the workflow for professional development that gets done without much fuzz. Most long term technical debt can be reduced a lot by proactively refactoring small things that for some reason don’t work well.
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.
This has been my experience. Carving out time for refactoring explicitly is only beneficial when your stakeholders, PM's, etc. understand its importance completely. Usually, at least one person up the chain says "it's already working and we have more important things to focus on. Put it on the backlog indefinitely."
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.
“Better to just incorporate refactoring into the estimate for any given coding task and do it without explicit permission.”
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 .
In my teams we take tickets for meetings, which makes product owners very aware of their impact on delivery.
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
Sarcasm not needed. I've probably done this during a meeting. I definitely code if it's an all hands on deck meeting that gets hijacked by technical discussions that aren't relevant to my work.
“Real agile” relies on a thorough suite of tests, a stable team that understands the domain and the codebase, and clear explanations of problems rather than a shopping list of solutions. Most teams don’t work in such an environment, so safe refactoring is impossible. Instead it’s just a whole series of shotgun surgery appointments.
Every "Agile" shop I've worked in was awful and has been doing it wrong according to Agile fans.
"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.
Most companies aren't willing to do this, so... we get a semi-unstructured form of micro-management hell which goes by the name "Agile." Regardless of whatever that term originally meant, this is what it means now.
> "That wasn't true Agile" is starting to sound about as credible as "That wasn't true Communism."
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.
> The difference is that many people have worked on highly functional "real agile" teams and can tell the tale.
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.
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 :)
“Self-organizing teams of experienced, expert engineers. Let them develop whatever process works best for the individual team and project.”
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.
This is what agile proponents always say. Whatever someone is suggesting, that's agile. It appears to mean nothing. Here, you're saying that the agile manifesto literally says nothing beyond "let people make up whatever process they want", which boils down to nothing at all. If that's really the case then agile as a concept may as well not exist.
But we have story points, epics, scrums, retros etc. Agile is very much more than that.
I think people just confuse Agile the manifesto and various methodologies that claim to adhere to it. You can work in a way that meets the manifesto without any of those concepts that are tied to it through things like Scrum.
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.
You have to look at how Agile was started. Before it often projects were planned out in detail beforehand and then they tried to execute that plan without changes. As it turned out that often didn’t work. So the Agile Manifesto writers tried to explain that software is unpredictable and you have to make sure people can adapt to changes.
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.
Even granting Marx wasn't particularly specific, the specific invention of Leninism, the Party as "intermediary" between the proletariat and History with a capital H, is conceived of absolutely nowhere in Marx's work, but the 'perversion' of Marxism to Leninism to Maoism is no different than the 'perversion' of Agile to Scrum to SAFE; there's no 'perversion' at all, because the idea of "lineage", while it works for and describes sequences of organic structures, is completely unfit for understanding ideas and how and why they change, to the point that its difficult to really use the word "origin" when it comes to ideas, particularly when each phase distinguishes itself from the last by what problems its trying to solve, the constraints on solutions, etc. We can only really talk about them being related insofar as there are structural identities in the concepts but that's about it.
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.
Then, to clarify, I almost never see story points assigned for refactoring existing code. Completion of story points is generally the metric of success in the absence of more valid metrics. That measure of success applies to the scrum master that moves the project forward and the developer assigned to perform the work.
> 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.
You're describing another sad disease. Or two, really.
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.
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