If you perceive it as micromanagement, whoever is running the process is doing something wrong. It should appear to the developer as if they have much more control.
You're too far behind the times to hope to catch up. Agile was the buzzword about 5 before Cloud.
More seriously: Agile is a particular process for getting things done, which became trendy in software development in particular about a decade ago. It's main tenet is to do work on short cycles, delivering the result to the customer, and then allowing the customer to define the next priority. The hope is that this continuous delivery model avoid the primary pitfall of longer software development cycles, which is spending months/years developing something, only to discover that the requirements were poorly defined at the start (and that the product therefore doesn't meet the real needs), or that market trends have rendered the result pointless.
I think you just described waterfall. In agile, the manager is supposed to tell the other manager those features will never be delivered. (I'm serious: a feature no one cares about should never make the priority queue, and therefore never get done). Putting a hard date to feature delivery is the very hallmark of waterfall.
I'm currently in my personal year 8 with a company that has been doing agile for the last 11. We've had most of the original team leave at this point, so that there are only a couple of people left more senior than I am. Undocumented code isn't a fault of agile, that's a fault of the team. Documentation should be part of your work product, and it should be scheduled right along with the other work, or an acceptance criterion for the other work.
Agile should pose zero risk of never having a working project after the end of the first sprint, at which point you should have a working product, which you will refine with additional features over time.
And looking at it more realistically, if your requirements are changing that drastically, you have something wrong with your process other than agile. The real problem is likely with your product managers, who are doing a poor job of defining the product with your customers.
Agile would say that someone with a theory of a better solution would propose it during the customer feedback cycle, and let the customer decide if that better solution is actually what they want.
Why is that the wrong outcome. From what you are saying, they are maximizing customer satisfaction overall. Yes, you, the minority customer, are dissatisfied. But someone has to be in this scenario. Why should they choose to make more customers dissatisfied?
What you've ended up doing is exactly what agile recommends: all work is in a single priority queue, and the customer gets to determine the priority every sprint. Work comes out of the queue at the rate reality dictates, but the customer can always decide what is most important to them to get next.
Shorter iterations is kind of the primary point. The idea being that project failure will become visible earlier, opening up more options in the response to the failure.
That's a nice theory, but only applies to stupid sellers. Smart sellers realize that if they can bury their competitors in the short run, they can reap monopoly profits in the long run.
That'd be a nice trick. Who is going to rewrite the thousands of hours worth of server code that doesn't ship with the client and is never released to the public?
AI is a very low processor cost item. Smartphones would actually have a much easier time with the AI of Fallout and Civ than they would with the graphics. But they are only two generations behind in graphics now, and steadily closing the gap. It won't be long.
I think the input device will be a non-issue within a year or two. Someone will get it right, and then game devs will be able to assume you have one, or can get one cheaply.
The response time will never get good enough for cloud rendering. It's not physically possible, the speed of light is the limiting factor. They'd have to put the compute station so close to you it may as well be in your home.
Slashdot Mirror
If you perceive it as micromanagement, whoever is running the process is doing something wrong. It should appear to the developer as if they have much more control.
You're too far behind the times to hope to catch up. Agile was the buzzword about 5 before Cloud.
More seriously:
Agile is a particular process for getting things done, which became trendy in software development in particular about a decade ago. It's main tenet is to do work on short cycles, delivering the result to the customer, and then allowing the customer to define the next priority. The hope is that this continuous delivery model avoid the primary pitfall of longer software development cycles, which is spending months/years developing something, only to discover that the requirements were poorly defined at the start (and that the product therefore doesn't meet the real needs), or that market trends have rendered the result pointless.
Agreed. Agile is the solution to a particular problem, but that problem is not incompetent development team.
Indeed. People who are selling agile as the solution to your incompetent team are ruining agile's reputation for the rest of us.
I think you just described waterfall. In agile, the manager is supposed to tell the other manager those features will never be delivered.
(I'm serious: a feature no one cares about should never make the priority queue, and therefore never get done).
Putting a hard date to feature delivery is the very hallmark of waterfall.
I'm currently in my personal year 8 with a company that has been doing agile for the last 11. We've had most of the original team leave at this point, so that there are only a couple of people left more senior than I am.
Undocumented code isn't a fault of agile, that's a fault of the team. Documentation should be part of your work product, and it should be scheduled right along with the other work, or an acceptance criterion for the other work.
Agile should pose zero risk of never having a working project after the end of the first sprint, at which point you should have a working product, which you will refine with additional features over time.
And looking at it more realistically, if your requirements are changing that drastically, you have something wrong with your process other than agile. The real problem is likely with your product managers, who are doing a poor job of defining the product with your customers.
You asked wrong. You don't ask for the priorities, you ask for the order he'd like them resolved in.
Agile would say that someone with a theory of a better solution would propose it during the customer feedback cycle, and let the customer decide if that better solution is actually what they want.
Why is that the wrong outcome. From what you are saying, they are maximizing customer satisfaction overall. Yes, you, the minority customer, are dissatisfied. But someone has to be in this scenario. Why should they choose to make more customers dissatisfied?
What you've ended up doing is exactly what agile recommends: all work is in a single priority queue, and the customer gets to determine the priority every sprint. Work comes out of the queue at the rate reality dictates, but the customer can always decide what is most important to them to get next.
Shorter iterations is kind of the primary point. The idea being that project failure will become visible earlier, opening up more options in the response to the failure.
I'm anti HSR in CA also, but you're omitting freight in your analysis, and that's a major gap.
I don't know, B&M has to unpack item, place on shelf. Mail order has to unpack item, repack item, and potentially take to mailing service.
That's a nice theory, but only applies to stupid sellers. Smart sellers realize that if they can bury their competitors in the short run, they can reap monopoly profits in the long run.
If you delete the rear seat that should make room for an additional two passengers, if you stack them right.
And, unlike your mustang, you can share the ride with more than 4 smelly passengers.
That'd be a nice trick. Who is going to rewrite the thousands of hours worth of server code that doesn't ship with the client and is never released to the public?
AI is a very low processor cost item. Smartphones would actually have a much easier time with the AI of Fallout and Civ than they would with the graphics. But they are only two generations behind in graphics now, and steadily closing the gap. It won't be long.
I think the input device will be a non-issue within a year or two. Someone will get it right, and then game devs will be able to assume you have one, or can get one cheaply.
I don't know where in the USA Central London is, and since I know most of the USA, that implies it's a niche.
Businesses using legacy apps like excel will be buried by modernized offices that can do the same work better and faster with Instagram.
The response time will never get good enough for cloud rendering. It's not physically possible, the speed of light is the limiting factor. They'd have to put the compute station so close to you it may as well be in your home.
Me too. Well, I still have a bookshelf, actually, but I'm using it for displaying nicknacks. I got rid of the books the last time I moved.
Which is not to mention that their Kindle should still have enough power for a few more days.