What is Agile?
-
I'm a backend developer who comes from a non-agile background. Last year, when I accepted my latest position, I was told that the team uses agile. I was eager to begin learning this new, magic method for creating software, based upon everything I had heard about agile. But I've been in the position for a year now, and the only difference from my previous jobs to this one is that now we have morning meetings and we delineate our work into two week intervals. That's it. Is this the highly touted Agile method? It's turned out to be a big disappointment. Is my experience typical?
The difficult we do right away... ...the impossible takes slightly longer.
Agile is just developer socialism. Whenever it has been tried people who survive it never want anything more to do with it and people who have never tried it think that “this time will be different!”
If you can't laugh at yourself - ask me and I will do it for you.
-
Do you point the stories(terminology used in agile)? Had a scrum master who was completely hung up on Fibonacci point values. Mercifully he changed jobs within the company. A day is approximately 2 points now.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
Yes, we score stories with points that are Fibonacci point values. Also points are not about how long it will take to complete but complexity. I could drone on endlessly about that last subject of complexity/time but suffice it to say that I am now so indoctrinated that I accept that points are not about time :laugh: Defects however are not scored with points but with t-shirt sizes S/M/L which is a time score - please big hole in the ground come and swallow me up...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I'm a backend developer who comes from a non-agile background. Last year, when I accepted my latest position, I was told that the team uses agile. I was eager to begin learning this new, magic method for creating software, based upon everything I had heard about agile. But I've been in the position for a year now, and the only difference from my previous jobs to this one is that now we have morning meetings and we delineate our work into two week intervals. That's it. Is this the highly touted Agile method? It's turned out to be a big disappointment. Is my experience typical?
The difficult we do right away... ...the impossible takes slightly longer.
What, no three to four 1+-hour meetings a week!? :omg: There's the backlog refinements, sprint planning, review, retrospective... I've literally spent hours refining, prioritizing and planning a sprint, only for some manager to come in three days into the sprint and change everything because priorities had changed :doh: That company was the biggest money wasting pile of incompetence I've ever seen though, so maybe not completely representative.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
What, no three to four 1+-hour meetings a week!? :omg: There's the backlog refinements, sprint planning, review, retrospective... I've literally spent hours refining, prioritizing and planning a sprint, only for some manager to come in three days into the sprint and change everything because priorities had changed :doh: That company was the biggest money wasting pile of incompetence I've ever seen though, so maybe not completely representative.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
That's a good story, thanks!
The difficult we do right away... ...the impossible takes slightly longer.
-
I'm a backend developer who comes from a non-agile background. Last year, when I accepted my latest position, I was told that the team uses agile. I was eager to begin learning this new, magic method for creating software, based upon everything I had heard about agile. But I've been in the position for a year now, and the only difference from my previous jobs to this one is that now we have morning meetings and we delineate our work into two week intervals. That's it. Is this the highly touted Agile method? It's turned out to be a big disappointment. Is my experience typical?
The difficult we do right away... ...the impossible takes slightly longer.
-
I'm a backend developer who comes from a non-agile background. Last year, when I accepted my latest position, I was told that the team uses agile. I was eager to begin learning this new, magic method for creating software, based upon everything I had heard about agile. But I've been in the position for a year now, and the only difference from my previous jobs to this one is that now we have morning meetings and we delineate our work into two week intervals. That's it. Is this the highly touted Agile method? It's turned out to be a big disappointment. Is my experience typical?
The difficult we do right away... ...the impossible takes slightly longer.
To repurpose an old aphorism, Agile is like teenage sex: * Everyone claims to be doing it * Very few are actually doing it * The few that are doing it are usually doing it wrong.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I'm a backend developer who comes from a non-agile background. Last year, when I accepted my latest position, I was told that the team uses agile. I was eager to begin learning this new, magic method for creating software, based upon everything I had heard about agile. But I've been in the position for a year now, and the only difference from my previous jobs to this one is that now we have morning meetings and we delineate our work into two week intervals. That's it. Is this the highly touted Agile method? It's turned out to be a big disappointment. Is my experience typical?
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
But I've been in the position for a year now, and the only difference from my previous jobs to this one is that now we have morning meetings and we delineate our work into two week intervals. That's it. Is this the highly touted Agile method?
I've worked projects in traditional "up front design"/waterfall and agile management. The right choice depends on the project and the players. I've found that the following are relevant: - UFD requires that the entire project is designed and planned before the software development starts. This can help with budgeting and well defined tasks. The project is finished when the development and testing is done. This works best with a relatively short time span (several months). - A UFD design document is "the design" and needs to be completely thought out. - A UFD project generally describes one version of the product. - An Agile design document is needed, and needs to define high level features but should not describe granular details. - UFD invites project management dysfunction such as feature creep, "this isn't what we want" and is very difficult to change one or two steps in "the plan". - Agile accommodates feature creep and invites stakeholder and end user participation if they see that they can change a bad choice into something they want. - Agile projects can comfortably go on for years and span multiple versions of a product. - Agile allows software development at an earlier stage in the project design. You also get a better ad hoc idea of how much effort is required to complete the task. - Agile is harder to budget and justify to upstream managers and bean counters. - UFD generally provides better adherence to features and (sometimes) reliability. - Agile generally provides better UI and general User Experience. - Agile will give you a product that you can start using much sooner, as feature 'x' and 'y' are implemented. - Agile will let you prioritize implementation details, do UI changes or partial redesign or add new features as needed. - As long as you have incoming funding, Agile will give you a better product that more people will like. For a better outcome: - Use UFD to design a rocket lander or navigation computer or hospital ventilator. - Use Agile if you have indecisive users or sales/managers that promise new features that were not planned for. P.S. if your scrum meetings are hours in length, you are doing scrum wrong. This daily meeting should take pla
