I believe agile fails for the same reason devops fails. The people who did ops or waterfall project management didn’t go anywhere. They just got told they’re using a new buzzword with the same responsibilities. Try telling a classically trained project manager that we should have less process and watch their head explode. Of course they revert to what they know the moment there is a breakdown.
Agile at 20: The Failed Rebellion
111–120 of 320 posts
Re: Agile at 20: The Failed Rebellion
#112Earlier quoted context omitted.
That being said, non technical PM always turned to be bad. Theoretically they don't need knowledge, but practically they do and it shows.
They can turn out fine if you have a strong lead or senior developers.
I ran my company like this (and have recommended to clients a similar approach). It still doesn't work the way you are thinking.
The "strong lead or senior developers" you're talking about: I call them TMs. Technical Managers. Because that's what their job becomes when the PM isn't technical enough. In the end, it's not the PM who "turns out fine" when paired with TMs; it's the combo of PM and TM who turn out fine.
There does exist a big difference between "lead or senior developers" who are good at development and those who are also good at using their technical knowledge to manage a team's work. A non-technical PM lacks that essential latter part, and if they have to rely on a "developer" to step up and fill that role, they're still a PM, but they're not the sole person doing PM any more.
Re: Agile at 20: The Failed Rebellion
#113Earlier quoted context omitted.
It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.
You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.
You can also flip that around. As much as devs try to disagree, technology is not a goal in of itself. Management is an abstraction on top of money in/money out and if in<out it doesn’t matter if you have the crispest tech, you’re going out of business.
Re: Agile at 20: The Failed Rebellion
#114I'm not an expert on this subject, but I feel like "agile" could be summarized as "a process for actively incorporating feedback early and often". That doesn't mean you need points or tshirt sizes or constant status meetings. You just need channels of communication with the right people and a chance to adapt to what they say.
You need because of the hostile nature between the creator and the patron of the creator.
The patron wants more, the creator doesn't want to create more, so you need to force a detente so the patron will continue to pay the creator, and the creator will continue to produce.
You get t-shirt sizes and points when the patron feels the creators aren't doing what they said they'd do, so in a way it's a communication problem, yes, but the cause of the communication problem is that there is almost never an alignment between the two groups, and so you need some kind of shared language where expectations can translate, and accountability can exist at all, usually in some flawed form.
Re: Agile at 20: The Failed Rebellion
#115Earlier quoted context omitted.
My PM does know more than me. And he's good at directing where the team should invest it's efforts. That's why he's my PM. You seem to have completely missed my point, which is that technical leads and PMs should have domain knowledge and that this is why DevOps is not in danger of failing at competent companies.
I get your point that someone rose from your ranks and you respect them over someone who who has a background in pm but not your product. That technical pm is a luxury and will move on at some point. You don't need him your team with a strong lead or more senior developers could work with a regular pm and get the job done.
> ... your team with a strong lead or more senior developers could work with a regular pm and get the job done.
Let me show you where this slippery slope ends: Teams with a strong lead or more senior developers could work without any PMs and still get the job done.
Oh. Wait a second. This happens all the time! Does this mean those teams achieved their success without any management happening? Or does it mean that technical people in those teams who did do the management work did it without the title?
IME, far more often, it's the latter.
Re: Agile at 20: The Failed Rebellion
#116Interestingly, one of the point in the manifesto says "Individuals and interactions over processes and tools", yet there are all sorts of processes and tools that now exists for Agile. What an irony.
I've been implementing "agile" at my new company, and while we do use Jira, I've made it abundantly clear that it's just for my own sanity to track what we're up to.
I could just as easily do this in a notebook, but it wouldn't be indexable or searchable, is all.
Re: Agile at 20: The Failed Rebellion
#117The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…
> The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want
I don't disagree, though I firmly believe Agile does a much better job of dealing with the problem you state than any other software development methodology that has been attempted before.
Is it perfect? of course not. As a methodology, is it better for building software than methodologies that have been used to build enormous physical structures for generations? Undoubtedly yes.
As far as I'm aware, there currently isn't anything better for building complex software with changing requirements (i.e. the real world).
Re: Agile at 20: The Failed Rebellion
#118Earlier quoted context omitted.
I think the fuss about the daily scrum is a perfect example of what is wrong with many Agile transformations. Often it seems that people talk about the 'micromanagement' and 'wasted time' as if they would not enjoy the daily. To me this is a warning, that something within the setup is not right. In general, micromanagement requires hierarchy, but I don't recall from the Scrum Guide [1] that a manager should be presen…
> negative emotions involved Because the daily standup can only be X minutes, someone always gets cut off, causing negative emotions.
I'd say the much more common negative emotion is when you didn't manage to get the work done you had planned to do/spending way too long on a task and having to justify that in front of the team.
Re: Agile at 20: The Failed Rebellion
#119Earlier quoted context omitted.
> This sounds soul-crushing and I hope never to work in such an environment. It isn't. Soul-crushing is doing "Agile" where the "scrum master" tells you how long each ticket will take, where the client is invisible and never involved, and where retro is 1 hour at the end of the sprint and focused on blame.
That example does sound really bad. But I would feel disengaged if everything was broken down to 1 point stories at the beginning of the sprint.
I thought the idea was to focus on what is achievable in the sprint. Breaking tasks into separate steps or points exposes the complexity of a task and a task that is listed as 1 point should be fairly quick to implement.
For me I'd feel more engaged by seeing that I've contributed to completing distinct points on the board at the end of the sprint.
I'm a team of one and only recently started coding a large project. Sometimes I can work entire days only having achieved intangible progress. I'd love to be able to quantify this work as progress toward distinct tasks. Maybe I need to implement an Agile-like system for myself.
Re: Agile at 20: The Failed Rebellion
#120Earlier quoted context omitted.
Using story points for evaluating developers goes against the ideals of Agile. It also makes story points useless. See Goodhart’s law.
No, I mean using story points for evaluating the complexity of a task (a lot of companies/teams use them this way at least).
I think spending too much time in a large company is damaging, possibly permanently, to a developer's ability to connect value to work.
On a basic level, Story Points are there because if you can't tell me how long something will take, I don't want to give you money to go do it.
Everyone has to deal with this, at every level. CEOs think about this, janitors think about this, literally everyone is constantly calculating estimated time to complete a task as a key metric about whether or not they should do the task.
All a Story Point should do is make that a conversation, not an isolated person's random guess. That's it. I don't see what's harmful about that.