61–70 of 239 posts
"leapfrog for the masses" Is this how googlers refer to results of their work and people respectively?
When human beings are part of an association that is verifiably elite, it is quite common for them to have elitist attitudes.
But is the average Googler contributing more to humanity than the average teacher? I'm not so sure.
That top rated answer is excellent. Agile at its core, to me as an engineering manager, is: - People over process/tools - Plan-able execution and pivoting quickly in rapidly changing environments - Create consistent, repeatable work delivery - Retrospection, learning and iteration over time - Tools (can) support the process to multiply efficiency but do not solve the core goals and problems Like the author of the com…
However, if you try to create a product in a market with competition, a non agile competitor can reach a global optima (for example Apple vs MS in mobile phones), and than you will lose the market (and sometime your future).
Earlier quoted context omitted.
>I would caution against trying to paint "developers at Google" using broad strokes.
There's a lot of irony in saying that about "developers at Google" and then immediately turning around and classifying everyone else as "the masses". Talk about broad strokes!
A related issue is software that cannot be meaningfully prototyped because any design that is reflective of the desired product has the same order of effort as the actual product, for many of the same reasons.
There are certain kinds of high-value software that cannot be built inside most tech companies now because it pattern matches so poorly to the way people think "agile" software development should look like.
I'm not saying that agile processes are inferior or even no better than other software development processes. I'm just saying that there is some level of fundamental capability that a software organization must have before the process is even going to matter.
> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to th…
I feel like people who are opposed to agile and scrum often make out things of it that are in no way prescribed by these methodologies. For example, I see people mentioning the idea that with scrum, you should release working software every sprint. This is not the case. The idea is to deliver a _potentially_ shippable product increment - a.k.a. not building 10 bridges in parallel if there's no need for it. Some might…
My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. Software development almost never works out so neatly. What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. You start working on it, maybe you di…
They don’t, there are ‘spikes’ that are just time spent researching or exploring or designing rather than implementing.
If your scrum master is telling the team what they can’t or can’t do, or how they should do their jobs, they are doing it wrong. Their job is to help you plan and help you resolve impediments to your work. They aren’t your boss.
The first thing in the manifesto is people over process, there should never be a case where some rule tells you that you can’t do the right thing.
Formal Scrum is a nice way to organize ‘normal’ work, but there are lots of cases where you have to improvise, and the process should never get in the way of that.
> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to th…
They probably deduced from this that their warning system worked as expected.
> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to th…
This is a sign of a sick and abusive culture. Once process becomes more important than people then the evil ones will work the system and climb the ladder hurting everyone in their path. Yuck.
There is unfortunately a large gulf between “agile” and “Agile” development these days. The former refers to development generally in line with the agile manifesto, with processes tailored to the needs of the team and the project. The latter is a buzzword used by consultants to convince management to put their favored bureaucratic method in place, usually some variant on the scrum system.
This is mostly what I see happen too, "Agile" is used an excuse to introduce some type of bureaucratic process to fix what is actually pathological cultural / leadership issues.