As usual no one can agree what agile actually is. Is what you are doing agile? Some would say no. Some would say yes.
Someone will likely says agile is a lot of shit and someone will reply saying "you are doing it wrong" without giving any indication of how to do it right.
This is because the naive mental model of development processes is bullshit: the techniques introduced and used should never be some rigid dogma. This applies to "agile" or whatever flavor-of-the-year we're talking about.
Agile is best thought of as an ecosystem of tools used to shape software (and knowledge) work. Am I "doing it wrong" when I get out my toolbox, use the #2 Philips head screwdriver, but not the torque wrench? NO! Not if I didn't need the torque wrench!
And that's a massive source of pain with "agile", or what I think of as "kitchen sink agile" where the goal becomes, explicit or not, to apply as many processes from as many books as possible – instead of picking just the right ones.
I've literally never been on two teams with the same process needs in my entire (now long) career. Even those teams year-over-year evolve their needs as the members, organization, and business change. Why should the process therefore be a static entity? One of the very few fixed rules I've learned hits to the GP's theme: it's critical to have the least necessary process, just as it's ridiculous to break out every tool in the box just to tighten up a loose screw.
again here is my opinion...
The minimum requirement for doing agile IMHO is to have retros and to iterate the process all the time until it works. That’s it.
But what agile is or is not is just semantics. It’s irrelevant I think. Who cares if we all follow the same set of rules? People selling certifications that's who!
Same! Whenever I have to explain what agile is I start with retrospectives. It's the one rule that is mandatory. Standups, sprints, JIRA boards, grooming/refinement sessions and everything else in a heavyweight framework like scrum is there to support the principles of agile, but none of it is actually necessary. IMO every software developer should read the Agile Manifesto ( https://agilemanifesto.org/principles.html ) every once in a while and consider whether their process is actually working for the team.
> and to iterate the process all the time until it works.
YES! If you aren't able to hack the process, then you aren't agile. Any rule-book driven "agile" isn't agile.
The problem is, to do agile, you need managers that don't have to have a rule book to follow. Those are rare. If you don't have them, then you get somebody's rigid "agile process", but not much actual agility.
Yes for me this is also the case. The WIP on the Kanban is very important. Is not a question of deadlines, is more a question of doing as little as possible at the same time.
the massive popularity of "agile" otoh, is based to a large extent on the fact that it turns engineers into automatons and offers management unprecedented visibility into their work.
As an IT exec if sprints and work broken into 2 hour deliverables makes sense.
Then ask them if they tell their boss every day what they're going to do for the next 24 hours in two hour increments.
Same approach also adopted here, except we don’t bother with daily stand-ups just on demand “regroups” once we finish tasks or someone requests help. We also don’t write a whole lot down, rather we just learn and internalise lessons as we go. We just define and evolve some key team ethos.
Limiting work in progress is the game changer for me.
I can see how this could work, however do you think one would feel similarly confident in hitting quarterly goals / OKRs without such estimation/sprints?
Why would you want to work at a place that does such bs in the first place?
Do that with your mba buddies and define okrs or whatnot but please let us just build awesome stuff. Thats my okr at least.
Dont need some manager breathing down my neck that the estimate was wrong
I don't think it is a maturity thing. It's a you have customers and business requirements to satisfy and if certain criteria are not met than the feature is kind of useless. I work at an org with around 5000 people and there is no way any engineer could know all of the business requirements for an application, there is just too much to know.
Well... I will try to put it in a different light. A cross functional product team must have all the knowledge to complete the tasks they are given. There is no way agile is going to work for you if there are 5000 people with a saying on your day to day tasks.
If there are a few stakeholders outside the team it's really the PO's job to represent them. If you need to know if the task is complete you ask the PO and she should made the call. It’s simple really
Agile has nothing to do with what is described in the article.
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.
Honestly, the part about agile I dislike the most is a dedicated scrum master role. They have very little to do if they aren't split between multiple teams and instead try to come up with weird ways to add value which usually don't add any value. We had agile coaches at my company recently and it was one of the more painful experiences of my career. They would try to add all these different flavors of grooming, planning, standup, and retro that usually just led to developers being uncomfortable and wanting to work from home. I'm not saying agile doesn't work, but it doesn't need to be a full time job and take up that much of developers time and they sure as hell don't need to inflate the process and methodology just to feel better about themselves.
> Honestly, the part about agile I dislike the most is a dedicated scrum master role
That's not a part about Agile, but about Scrum.
Also, the “dedicated” part isn't even essential to Scrum.
> We had agile coaches at my company recently and it was one of the more painful experiences of my career. They would try to add [...]
That's a different issue than a dedicated ScrumMaster role, and anti-Agile, as team ownership of process is central to Agile. Consultants external to the team (whether internal to the org or external there, too) trying to impose process is the antithesis of Agile. There might be a role for coaching in Agile, but it certainly isn't process advocacy.
Fair points, I tend to conflate agile and scrum since they seem to be coupled together. I get that the dedicated part isn't a requirement, it just seems to be part of most implementations I see. I guess my problem is more with people's implementations.
We have this now, our scrum masters do everything now because they don’t really understand their role nor is it well defined. It’s hell.
They are now delving into solutions architects and seem to be expert software engineers who ask questions like, “but isn’t that simple? How come it’s going to take so long” etc.
Nightmare.
I find it telling that I never met scrum masters who can actually tell you what they’re working on or what their backlog is. Funny that?
Yeah I always see scrum masters as trying to play engineering manager or play at a role that isn't theirs nor are they qualified for. They also seem to think most engineers are stupid and can't even walk without hand holding.
> work methodologies are moving towards an asynchronous event model where information streams get connected, are mapped and then are transformed into a native model in unpredictable fashion
Probably the most insightful quote from the article.
"Perhaps the last major holdout of such applications is with the category of games, and even there, the emergence of a few consistent tool-sets such as the Unreal Engine means that there's increasing convergence on the technical components, with Agile really only living on in areas such as design and media creation." - In practice, I haven't seen the use of Unreal Engine promoting the end of agile or vice versa. If what he's saying here is that using off the shelf game engines means no more need for programmers so no more agile (except for content) then he's dead wrong. Every game that I've ever worked on using Unity or Unreal have a significant amount of programming work involved. Some of them have used agile and others less so.
The team I'm on uses Agile, but in practice it's a combination of Agile, Kanban, and Waterfall. The tasks we work on are usually pretty big and undefined. And it's nice to meet every couple weeks to plan out a sprint. But an overall waterfall-like list of objectives drive everything, and we're not strict about adding or removing things from the sprint. So I don't know what system fits us best. Agile encourages us to document tickets so they can be worked on, which is nice.
> The Agile Manifesto, like most such screeds, started out as a really good idea. The core principle was simple - you didn't really need large groups of people working on software projects to get them done.
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.
> 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
I'd like to read those studies. Do you have a cite?
That specific finding was from what appears to be the 1997 QSM study [0], though the description I am familiar with it from (Mike Cohn’s Succeeding in Agile: Software Development Using Scrum, 2010, describes it as covering projects in 2003-2005 (the author, organization, and number of projects in the analysis, and the one result chart from the study that is in the article on the web [1] match between the book and the 1997 one, though, but the chart showing time to complete by team size isn't shown in the article.)
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.
If capital-A “Agile” ever ends, it will be replaced by something with a different name that takes exactly the same form. How do I know? Because I’m old enough to remember before there was capital-A “Agile”, and the original XP/Agile manifesto came along and within a few years was bastardized into exactly what came before it: the expectation that with enough meetings and unreasonable enough demands, software development could be a perfectly predictable, cookie-cutter endeavor, as uneventful as manufacturing sheet metal.
Agreed, before Agile there was Waterfall, RUP, and many other theories of assembly line management processes. They are all based on starting universities for the way to produce a product, and these paradigms all came from auto makers... It's a constantly spinning wheel... Can't be stopped...
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
Someone will likely says agile is a lot of shit and someone will reply saying "you are doing it wrong" without giving any indication of how to do it right.
Agile is best thought of as an ecosystem of tools used to shape software (and knowledge) work. Am I "doing it wrong" when I get out my toolbox, use the #2 Philips head screwdriver, but not the torque wrench? NO! Not if I didn't need the torque wrench!
And that's a massive source of pain with "agile", or what I think of as "kitchen sink agile" where the goal becomes, explicit or not, to apply as many processes from as many books as possible – instead of picking just the right ones.
I've literally never been on two teams with the same process needs in my entire (now long) career. Even those teams year-over-year evolve their needs as the members, organization, and business change. Why should the process therefore be a static entity? One of the very few fixed rules I've learned hits to the GP's theme: it's critical to have the least necessary process, just as it's ridiculous to break out every tool in the box just to tighten up a loose screw.
But what agile is or is not is just semantics. It’s irrelevant I think. Who cares if we all follow the same set of rules? People selling certifications that's who!
YES! If you aren't able to hack the process, then you aren't agile. Any rule-book driven "agile" isn't agile.
The problem is, to do agile, you need managers that don't have to have a rule book to follow. Those are rare. If you don't have them, then you get somebody's rigid "agile process", but not much actual agility.
As an IT exec if sprints and work broken into 2 hour deliverables makes sense.
Then ask them if they tell their boss every day what they're going to do for the next 24 hours in two hour increments.
Limiting work in progress is the game changer for me.
Acceptance criteria? That’s BS! We are all adults where I work
If there are a few stakeholders outside the team it's really the PO's job to represent them. If you need to know if the task is complete you ask the PO and she should made the call. It’s simple really
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.
That's not a part about Agile, but about Scrum.
Also, the “dedicated” part isn't even essential to Scrum.
> We had agile coaches at my company recently and it was one of the more painful experiences of my career. They would try to add [...]
That's a different issue than a dedicated ScrumMaster role, and anti-Agile, as team ownership of process is central to Agile. Consultants external to the team (whether internal to the org or external there, too) trying to impose process is the antithesis of Agile. There might be a role for coaching in Agile, but it certainly isn't process advocacy.
They are now delving into solutions architects and seem to be expert software engineers who ask questions like, “but isn’t that simple? How come it’s going to take so long” etc.
Nightmare.
I find it telling that I never met scrum masters who can actually tell you what they’re working on or what their backlog is. Funny that?
You probably haven't yet experienced SAFE / Scaled Agile at a non-tech Fortune 500. There's worse things people can slap an Agile tag on :)
Probably the most insightful quote from the article.
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.
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.
[0] https://agilemanifesto.org/
[1] https://agilemanifesto.org/principles.html
I'd like to read those studies. Do you have a cite?
[0] https://www.qsm.com/blog/2019/4-key-studies-team-size
[1] https://www.qsm.com/articles/team-size-can-be-key-successful...
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.
Mark my words, remote work is worse, and will destroy careers.