Earlier quoted context omitted.
This is exactly what drove me off my last team. We were seasoned developers with a combined experience of more than 50 years, 25 of them in scrum. And we were assigned a scrum master that never worked in software development before, fresh of the scrum master training and was telling us in a very condescending tone, how we could improve ourselves and our team. That guy didn't know anything about software development,…
How can you even get a Job as a "scrum master" with no experience in development or the industry. You should collectively have just refused to work for them in this case.
Agile at 20: The Failed Rebellion
311–320 of 320 posts
Re: Agile at 20: The Failed Rebellion
#312Earlier quoted context omitted.
> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over resp…
The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. I once had it used against me to justify not writing tests ("processes and tools!"). We had meetings about bugs instead. Seriously. Complain all you like about perversion, that was a perfectly valid interpretation coz those hallowed commandments are,…
Re: Agile at 20: The Failed Rebellion
#313Earlier quoted context omitted.
> We don’t allow scrum masters and agile coaches in hospitals Give it a few years.
My hospital had them 10 years ago. Leaving is, second to marrying my wife, the best decision I ever made. Hospitals are, much to my sincere regret, not able to attract much talent in IT. Mediocrity is the best you can hope for, and I wouldn't even count on that.
I think the GP meant "in hospitals" as in "among medical people", doctors and nurses, not IT staff.
Re: Agile at 20: The Failed Rebellion
#314Earlier quoted context omitted.
They keep releasing versions that break backward compatibility forcing whole app rewrite left and right, that counts too
The track record for compatibility in the tools I mentioned is extremely good. Even when new approaches were launched (Hooks, Composition in Vue), backwards compatibility was kept. You can even mix and match approaches in the same app. Of course there's Angular, but that's the exception to the rule. Heck, Microsoft has completely changed the way of writing native Windows apps in the last 10 years more ways than Javas…
No they haven't. You still write them in Delphi or Free Pascal / Lazarus just the same way you did ten years ago.
Oh, you meant "the way of writing native Windows apps" with Microsoft tools? Yeah, well... Heard the old joke about the guy who complains, "Doctor, doctor, it hurts when I do this!"? My answer is the same as the doctor's: Well, don't do that then.
Re: Agile at 20: The Failed Rebellion
#315Earlier quoted context omitted.
Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go. Agile tries to turn software development into a product design process rather than a product manufacturing process. Together with the client, iteratively you try to find the right solution and design for the customer problem. By being easy to adopt,…
> Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go. Oh, man. I think you hit the head of the nail. One succinct phrase that describes the entire problem.
(And I think for completeness' sake the next two need to be included too.)
Re: Agile at 20: The Failed Rebellion
#316Earlier quoted context omitted.
"Customers don't know what they want": this is something Agile specifically tries to address by releasing often and adapting to change. This is a quick feedback loop: the customer can quickly see a product and the development can quickly adapt. What was the 'standard' way to develop systems when the Agile Manifesto was written: the same as for building a bridge. You gather and freeze requirements. You write a massive…
Your characterization is not true. The reality was quite the opposite. Here's the introduction of Steve McConnell's "Rapid Development" from 1994 - well before the Agile Manifesto! - Chapter 1, page 1: > The product manager told me he wanted to build a product right for a change. He wanted to pay attention to quality, prevent feature creep, control the schedule, and have a predictable ship date. > When the time came…
> > To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi.
Huh? Did you get the year wrong, or was he referring to a brand-new / not yet released / tool as a "standard" for some segment of his audience? AFAICR, Delphi was introduced in 1995, or at the very earliest, late 1994. Feels weird that he should mention it in a book published in 1994.
Re: Agile at 20: The Failed Rebellion
#317Earlier quoted context omitted.
The sales team sells what has already been delivered. In my experience, the customer collaboration happens through a proxy called the product manager. It is their job to hold meetings with customers to figure out priorities. You don’t “prevent” feature creep ever. It is part and parcel of development. You can, however, manage it by restricting when the goalposts change. In Scrum, that’s at sprint boundaries. The most…
Except most customers only pay when it goes live, or reaches major milestones, and then you are out of budget, struggling to find another parallel project to somehow keep the team in place, before management states it is time to move on.
But with (real) agile, it went live early on, didn't it?
Re: Agile at 20: The Failed Rebellion
#318If waterfall is the first Death Star is SAFe the second?
Re: Agile at 20: The Failed Rebellion
#319The customer had a problem, he knew he wanted a computer in the solution. The first person he contacted to solve the problem hired me to write the solution. He hated the hardware chosen, and went off to make is own choices.
Having chosen acceptable hardware, he hired a different person to solve the problem. They also hired me, we pitched a solution. It took about 2 months to code.
The program worked as promised, met all the requirements. Up to this point, it was essentially waterfall. We agreed that a wider sale/deployment would be contingent on me working directly with the customer on-site in an agile fashion.
I wrote code, he brought a random power plant worker in to try it out (in the days before everyone knew how to run a PC), and we iterated. Everyone was quite happy with the product for years, until networks, Windows and other reporting systems made it obsolete.
Nobody knows the details of what is useful until there is a prototype to work with, and get the feel of. Agile is the way people have been solving problems forever.
There seem to be a lot of "No True Scotsman" threads here. Since I did this before "agile" was a thing, I don't have to worry about it. 8)
Re: Agile at 20: The Failed Rebellion
#320Earlier quoted context omitted.
Research and algo design was where most of the 3- and 5-point tickets came from. I think I remember a couple with more points, but not many. Given the "about one hour of work, give or take" target point value we used, there weren't many tasks which had more points than that.
I see. But that's still only the first, "plannable" part. If the research (or algo design) led to the conclusion that component X needed a rewrite, would it require waiting half a month to get started? Maybe that makes sense if it's a larger thing (so that detailed planning would be worthwhile), but would you be required to drop it and do something else in the meantime even for smaller ones (say, a man-day of work)?