> My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process.
Some processes try to break conceptual integrity. Micro services are one but Scrum as practiced usually tries to stick people into a blind valley where the horizon is months out rather than years. That leads to bad minmaxing behaviors, and/or covert channels being used to keep the wheels on. Scrum theater is especially grating when people who make the sausage have to listen to zealous managers brag about how the process is the source of all of their success. Since they don’t know where the success comes from they don’t see it leave the building to be appreciated somewhere else.
The second time it was my circus, my clowns, someone had divided the backend and front end people into different groups and it was a shitshow. Until I/we discovered that diagrams of user interactions were less than useless for preventing impedance mismatches between the tiers. What you needed were data flow analyses. Particularly for complex data entry workflows. C comes from B, B comes from A. Rework dropped like a rock once I incorporated this into kickoff meetings.
Worst is, this has nothing to do with short feedback loops and frequent releases. It all has to do with perception and how the method is used.
It's a mixed bag. One thing refactoring is good for is getting past friction introduced by people who don't like a good idea. Early in my career I got a lot of "that will take too long" for features in the High Cost, High Value quadrant of the feature graph. A couple months of picking away at the accidental complexity and you can come back with a <6 week estimate instead of 4 months, and your proposal gets more consideration. I'm not saying 4 months is a reasonable estimate, I get why that causes concern, but refactoring can be so much more effective when you have long-term goals in mind. When you have a list of 'target of opportunity' features. When you can romance an epic into the code, instead of forcing it in.
I still get that pushback of course, but I'm more used to it and also sometimes don't ask questions I don't want the answer to. It's all subterfuge and puppet mastery. If I wanted to be an accountant or a lobbyist I wouldn't have enrolled in a CS degree at a semi-respectable institution.
The settings :
Giant industrial corporation, giant projects with other giant corps as clients.
Process process process. SAFe Scrum.
Somehow I ended up in a team that started to care. Like, we, small individual team, had a agenda and a goal. We saw path to success for this mess of a giant project.
And we started to shadow work our way thought it.
At first myself and another senior guy. As a hobbit.
But it became prevalent for the team as a whole to do “prep work” on top of our tickets.
We self organize, self train.
Why? So we can move faster and actually deliver.
Our normal ticket we’re adjacent work. It’s not like we started 30 repo on the side.
Finally our scrum master caught on that. She went onboard.
We repurposed tickets like nobody’s business. Acceptance criteria was a mere indication, because the QA folks were on board as well.
Not to less us merge crap, QA is QA and you don’t go to prod with a buggy industrial system. That shit is dangerous:
but they knew where we were going and were fine with changing the AC if they see progress, and if the black market scrum master say we’re gonna have a black market ticket to fix it.
We delivered. It fucking worked. My favorite part ? We were the “bad” team. The team without a cool project or a decent backlog. The cleanup crew.
How about if everybody can fit (the outline of) the entire system in their head? XP says that everyone needs to understand the cocktail-napkin-level view of the system, and everyone needs to be able to reproduce it when asked. That helps conceptual integrity - everyone knows the vision of the system.
Personally I don't like answering the same questions over and over. I got into programming so I could 'solve' repetitive work, not so I could get paid more to to it faster. And I've seen to many cases of unapproachable=out of touch so that's not an option for me. The only way to scale being the person to ask hard questions is if you make sure people can self-serve on easy and intermediate ones.
And yet it is I would say very rare to see a good team scale their vision up. AOL was able to onboard new programmers and share the vision, but we never got a different geographic site converted, not really.
One tried things with documentation and two person Webex meetings, and code reviews that focus not on being tidy, but here’s how we understand this problem, these are the reasons to do something, this use case is an example of such and such a concept. (Just a final closing comment, be tidy you won’t be happy otherwise.). It can gradually build up over time, but rarely causes teams to catch fire.