by interweb on 8/23/19, 11:16 AM with 41 comments
by jdmoreira on 8/23/19, 12:32 PM
No estimates. No sprints. No Jira. No bullshit!
What we do? Retro, grooming and planning. Standup everyday in front of a Kanban board with post-its. And we help each other. That’s it!
Seriously, how hard can it be? Building software is not the same as a Ford model T assembly line
by lmilcin on 8/23/19, 1:27 PM
Agile is not dead and will be more important going on. "Agile" (apostrophes intended) is and will be kept alive by countless managers of different levels that would like to emulate successful organizations but don't want to spend time and effort actually understanding what makes them successful.
Please, read something like "Pheonix Project" (Gene Kim, Kevin Behr, George Spafford) or "The Goal" (Eliyahu Goldratt) to get better informed about what Agile is.
My understanding of Agile is that it is a shared understanding, commitment for porsuing goal of serving your organization and your customer as efficiently as possible. Hopefully, serving your customer is tantamount to serving your organization, if your organization's values are right.
Agile is not a process. Agile is a drive to seek most efficient process. Agile means you are honestly critical of what you are doing and are constantly learning and adjusting to get best possible outcome.
Scrum or Kanban happen to be one of ways to implement Agile but they are not equivalent to Agile. Agile precludes any single set process because every product, customer and organization is different and so it is not possible for a single set process to be best possible process.
Scrum or Kanban are anti-Agile in my opinion because they tend people to get complacent with the process (yes, we have implemented Scrum so we are Agile). Being complacent is opposite to what Agile is -- constantly seeking better process.
by notus on 8/23/19, 1:26 PM
by ljw1001 on 8/23/19, 9:44 PM
by 9wzYQbTYsAIc on 8/23/19, 1:06 PM
Probably the most insightful quote from the article.
by sparker72678 on 8/23/19, 3:21 PM
Developing and maintaining a large project will be difficult, no matter your approach.
Which is not to say that all approaches are equal.
Part of our problem is that we want a development/management approach that works for all types of problems. There isn't one.
by djmips on 8/24/19, 7:22 AM
by jdlyga on 8/23/19, 2:22 PM
by dragonwriter on 8/23/19, 1:13 PM
That's not the core principle of the Agile Manifesto. In fact, nothing even vaguely like that is included in the Manifesto for Agile Software Development [0] or the Principles behind the Agile Manifesto. [1]
Now, to be fair, there is a study or set of studies which shows that, for software projects within a certain broad size range, a team size of 5-7 gets the project done fastest, and that larger teams not only take more man-hours for the same size project but more calendar days, and that study is broadly influential in setting team sizes in teams that claim to be practicing Agile or Lean development; that's not a, much less the, core principle of Agile, though, just a piece of empirical evidence that became available when Agile (at least the name, of perhaps not the actual philosophy) was becoming popular.
Agile has kind of the same problem as Marxism; the theory is, and the is quite critical in both cases, bottom up, but most of the practical implementations throw that out and are top-down.
With Marxism, this might seem like a bigger problem because it is every single implementation that claims the name has the problem, but in a sense it's a little easier to distinguish the problem in practice as being separate from Marxism itself because at least all the real world implementation point to a particular revision of the theory which contains the diversions from the original (Leninism). So at least you can point to Leninism and say it's the problem distinct from Marxism. While there are a few bottom-up Agile implementations where the teams really are self-organizing and empowered, the norm is top down implementation of something that at least superficially resembles Scrum, without any real control of process in the team, but there is no clearly diverging theory that unifies the top-down one; they don't claim to be practicing Agile-Leninism but instead plain, vanilla Agile, though their practices are in no way grounded in the Agile Manifesto or Principles, but instead the same canned-process management approach against which Agile was a reaction. So it's a little harder to distinguish based on what the implementors say is their philosophy, though it's still possible to distinguish the substance.
by winternett on 8/23/19, 1:00 PM
People just aren't willing to admit the parts of it that are Kool Aid, and the parts that are useful because it's a profit machine (books, training, merch, etc)as well as a methodology for getting things done in projects.
I have never seen anyone implement agile fully in my world, it's usually 50% or below in terms of adoption rate. Passing around a hockey stick is a gimmicky thing, and I've always avoided the silly ideas, i want to go to work, stick to the points, get things done right and then go home... Sprint Poker, passing a hockey stick, agile toys, going to Agile conferences etc can be left to agile coaches if you ask me.
by end-of-remote on 8/23/19, 11:59 AM
Mark my words, remote work is worse, and will destroy careers.
by billman on 8/23/19, 12:29 PM
by topkai22 on 8/23/19, 4:35 PM