At the same time, I have now done software engineering for over a decade, in many roles and teams, and I have never seen Agile or Scrum to lead to the development of a good piece of software. I guess we were using it wrong.
Their manager got an “agile PM” forced on them and it broke.
The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.
The only time I've ever seen this not happen was when we had a 55 year old delivery manager who viewed his job as facilitating team meetings in a way that meant everyone got the chance to speak and that consensus formed. Didn't try to dictate process or anything, just made sure everyone got heard and that decisions got made. He was patient enough to wait and not force the issues, too.
(I refuse to utter the above phrase without accompanying it with tjis: "not everything that counts can be counted")
You will still get cold emails and LinkedIn messages from these people but you don't have to respond
If it’s not described, and only works via the “minds of a few engineers”, you get amateur treehouse-quality engineering like the 737 MAX.
I guess chance can make it work well like that “once” sporadically, but when you need to touch that code again to maintain it, we go back to the amateur treehouse.
[edit] Too many of these people want tomatos, so they plant a tomato, when really they want seasonal tomatos, and need to consider a farm, and take into account growth cycles. The term I like is "sustainable development."
As mentioned by user "phkahler":
> 1) Come to work.
> 2) Look at the current state.
> 3) Decide what the product needs from you.
> 4) Do that.
> 5) Use git.
> Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates).
> This is how my current job works and we are unbelievably productive.
[edit]
I like the book "phoenix project," and I think they wrote "Team Topologies" which I am curious to read.
[edit]
In general, psychological safety was the number one factor for productive teams, according to a massive google study. From this viewpoint, it's easy to see why there are so few productive teams, as there is little to no safety for most people. Remember though, "There are no silver bullets."
[Edit]
The goal should be continuous delivery imo.
And of course that is where the cost savings are usually made because it is seen as a null function in some businesses. It creates waste and reduces delivery and ROI. Those are all symptoms of other problems in the business but that's how it is generally perceived. And sometimes clients are happy to receive muck if it's cheap.
But that's also how we get planes that crash and Microsoft firing their entire QA and delivering shit for the last half a decade.
And that in turn is because management and project management culture is data driven by people who have no idea what the fuck they are doing whatsoever.
I still don't understand the role of PMs when there are engineering managers, product owners and self-organizing teams involved.
Then the CTO left, and was never replaced, then the layoffs came and a competent PM was replaced with a junior. Entire design department replaced with a single junior as well. Engineering gutted. Ok, lay-offs happen but at least I still have a job.
Then came “we’re waterfall now”. You know what didn’t come with it? Actual planning, documentation or specs or anything typical of “waterfall”. Estimates are now guessed before anything is defined and turned into commitments. You know what we still had? “Daily stand ups”, “backlog grooming”, two week “sprints”, and no retrospectives. No opportunity or agency to try to make things better - just endlessly stuck in my own personal hell.
Now we have projects that are supposed to take 2 months now taking 6. We have last minute spec changes that require massive rewrites because UAT isn’t done until the end of the entire project. “PM is slow to write out requirements” so we’re basically expected to just guess what they are based on very small selection of unfinished design flows.
And of course, executive wonders “why does engineering take so long to deliver”.
I started calling this “scrumerfall” or even ”fragile”. It’s basically the worst of both with none of the positives.
I don’t know what point I’m actually trying to make…just get like ranting and this seemed like a good time lol
What I've seen the most is people putting up straw men in place of Agile, and proceed to attack the strawman in spite of being repeatedly pointed out they are pummelling a straw man.
Scrum fixed that by being as bad as it was precisely defined.
I can get what the originators of agile were getting at but they explained themselves super badly.
I think a lot of ppl forget that.
One of the nice things about scrum is that it has an official source who defines it and you can look at it to see what it is and what it is not intended to be.
The retrospective is where you can tweak the process, but you can honestly change things anywhere. Bad managers will resist change at any cost and will use Scrum as an excuse to resisting change, but that's true for any methodology.
The problem is it doesn't work when there's micromanagement, it doesn't work when there are waterfall-ish parts (eg: PMs not splitting tickets, QAs hogging releases). Scrum also doesn't work when the development team isn't empowered, or has no domain experts. But most methodologies also don't.
Just the typical "No True Scotsman" fallacy [1], happens all the time when there is no good defense of the position.
Sometimes the fakes simply do outnumber the real ones.
You can use SCRUM/Kanban/SaFE/LeSS, hybrid or other Agile methodology, or no process at all, but it will not help when people are not trained to be proper part of the process.
For example, a PM may replace SCRUM meeting with a status meeting, because it makes his job easier, while PM or other M should not attend a SCRUM meeting at all, unless called in by engineers. The proper moment for interaction between PM and engineer are beginning/end of a ticket, sprint review, and sprint planning.
2) Look at the current state.
3) Decide what the product needs from you.
4) Do that.
5) Use git.
Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates).
This is how my current job works and we are unbelievably productive.
And IMO it also implies things like CI/CD.
A process is a hardcoded way of do thing, which is deficient because it cannot react to an ever-changing world
A better way to handle things is by defining "what" should be done, not "how" it should be done
Everything you do -up to and including taking a leak- is a sort of process. Perhaps you don't think that particular example should be a corporate process, but that's not my problem :-P .
You can compose processes to get things done.
Processes can be made mutable or flexible by eg. incorporating decisions or iteration. Especially iterated processes can be very powerful (you can get a lot done with them).
Thinking of things in terms of processes instead of in terms of component steps each time frees your mind to worry about other stuff.
Compare it with dividing a program into functions. Once you've wrapped a task in a function, you can then design using the function, rather than worry about how to write the code from scratch each time. Same with process thinking: you don't have to get bogged down in particulars all the time.
That said, maybe you're thinking of the "Befehlstaktik" vs "Auftragstaktik" [1] approach to doing things. In which case we're arguing definitions instead (which can be easily resolved).
You need to communicate with stakeholders then, to change requirements, explain mistakes, set new goals, and reprioritize tasks. Agile (SCRUM/Kanban/etc.) are designed with frequently changing requirements in mind. In SCRUM, this is done at sprint review/sprint planning stage. In Kanban, it's continuous process.
Just as product requirements can change, so can the way we work. Just like there is not one singular product that solves everybody’s needs, there isn’t necessarily one process that does that either.
I kid, but I think the early proponents of Scrum and similar were trying to achieve a loose framework to do exactly what you’re talking about. The modern incarnations of these can be horrific, but the original intent was always to empower teams to make their own process. Ahh well.
Like so many good ideas (democracy, constitutions), you only really know how well they function once people are actively trying to subvert them. Scrum et.al. have failed in the face of corporatocracy. I honestly don’t know if decentralised structures (i.e. teams empowered to run themselves), can ever survive in large corporates. Which is a pity. Cities grow, but companies die. You have to jump off the dying colossus to find the new company that hasn’t yet succumbed.
The team is self-organizing but person X is the decision maker in the process.
There is an engineering manager, but they will get overruled by person X more often than not.
The framework is simple, but person X will add new rules.
Agile/Scrum says people must understand the domain, but person X is the only one talking to stakeholders since engineers are "not people persons".
I don’t think that’s why they exist, but I do think the structure is not robust to a large number of dysfunctions. This one included.
But bad on agile for letting charlatans co-opt the term.
What's "by the book" agile? Scrum? The things in the manifesto? Something that some rando Scrummaster said?
And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?
> What's "by the book" agile? Scrum? The things in the manifesto?
Definitely scrum.
> And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?
Every single detail and aspect of your work is determined by someone or something else. You have zero individual autonomy, zero individual responsibility. And zero option to do something good or bad. "Self-organizing" just means that scrum master or coach or whoever is creating set of rules that dictate pretty much every aspect of work.
Yeah, it is not one person telling you how to do things. It is that every aspect of work is decided by someone else or some committee. When you have one person telling you how to do things you at least can adjust to them and negotiate some space with them.
See, this is already not "by the book" Scrum.
The team decides those things in a retrospective, and as long as they are releasing in a reasonable timely manner, it's alright.
If someone is being unreasonable and putting their foot down too much, then it's a management issue that doesn't have anything to do with Scrum. Either the person is a dictator, or they don't have authority and there's no management to put an end to it.
Scrum also doesn't work when the team is burning in a building on fire, but we don't blame Scrum for that.
I'm all for shitting on it, but those problems have been happening in companies for millenia. Scrum won't fix them, you gotta fix each separate problem by itself.
The Agile Manifesto was just a bunch of people who were already doing XP, Scrum or some other lightweight process getting together and writing down the similarities between what they were doing. It's a blanket term invented to describe a variety of different processes, not an actual process.
[1] https://en.wikipedia.org/wiki/Kent_Beck