Countless articles like https://www.hypermatic.com/articles/agile-is-for-losers opine that Agile, implemented in a distorted way, is counter-productive. That’s been my experience. It has greatly slowed progress (5X-10X) all so that management can have dashboards.
Anyone else miss the old days?
Agile doesn’t work when most of the team does basically nothing on most days. It makes those daily scrums a little awkward.
at a different company with some small amount of agile in IT/analytics for internal customers only. the need for formality and process isn't as intense since our customers are all "down the hall", not all around the world. our pendulum has swung to something in between. standups are about 2x a week. for the most part, not doing retros. not doing demos with the whole group, just for the specific stakeholders involved. we get together for some light grooming of stories outside the standups, still moving stories through our board with QA, acceptance, etc.
it's better than a heavy meeting and heavy dashboard approach, but think we have gone a little too lightweight. would be good to add retros back for maybe once/quarter, demos just to be able to see what others are doing and learn from peers once every 1-2 months. it's supposed to be "individuals and interactions over processes and tools", but it depends on your management. bad management = bad processes, bad everything.
In my old days as a SAS developer we had meetings once a month.
Agile blew me away.
I think a single monthly meeting is not enough. But Agile brought a different world.
Every day status meeting.
Every sprint a 1-2 hour developer meeting to discuss each story and how long it would take.
Every sprint a 1-2 hour group meeting to officially assign each story.
Every sprint a 1 hour post-sprint retrospective
And of course there were always other meetings about various stuff.
I made the mistake of complaining about this in a meeting. My manager was a prima donna type who took this as a personal attack. Guess what happened?
Agile is so meeting oriented it's amazing anything gets done.
Disgusting that you have to race-bait.
There is a lot of rhetoric and semantics surrounding “Agile” in the context of Software Development. The original Agile Manifesto was authored by white boomer males (considered expert software practitioners) over 20 years ago.
https://en.m.wikipedia.org/wiki/Agile_software_development
For better for worse, that was what it was, although today’s “Agile” personnel are, at the very least, thankfully a whole lot more diverse.
Following this 2001 convocation, I am personally loath to trace the detailed history and protagonists that got the Software Industry to the state that it is in today with Agile. However, it seems that it’s mostly turned into a bunch of certifications that underwrite bullsh-t jobs having very little to do with designing and creating software THAT IS ACTUALLY EFFECTIVE AND PROFITABLE … and I say that as someone who has many decades of experience, and prior to retirement was recognized as an expert software designer and developer in the areas I worked in.
Competent, effective professionals, passionate about their craft, who know how to communicate verbally and in writing do not need the micromanaged silliness and rigidity that often attends modern “Agile” practices. Such Product and Engineering professionals are perfectly capable of adapting to whatever circumstances are necessary to empower their colleagues and make a project mission successful. If not, they are at the very least deficient and at worst ”professional in name only”.
if a particular team sees benefits from aspects of so called Agile methodologies, then fine, let them implement that, and make necessary adjustments to it over the course of various projects and then chuck it altogether if need be. However, do such expert teams really need somebody with a “Agile certification” (yet often no honest software design/development expertise) to preside over silly meetings were the same. Staff gets regurgitated sprint after sprint? Also, PLEASE don’t try to create a company culture around the religious aspects of Agile, nor bow to the whims of certain tool vendors who are profiting fabulously from the continually evolving over-inflated hype that has been Agile for the past 15 years.
https://news.ycombinator.com/item?id=5406384
When everything is a metric, nothing adds up. Just like when everything is a priority, nothing is.
The love affair with dashboards and metrics is mostly foolish. Metrics can be extremely useful when they inform process improvement. When they are used to measure a team's or individual's performance, then the incentive diabolically shifts to managing the metric instead of improving the process. When this happens, the metrics are no longer accurate or useful.
You can't lead an organization by imposing metrics. But, you can make them toxic.
“The Product Manager is outwardly facing and focuses on gathering requirements from the customers. The Product Owner is inwardly facing and focused on translating requirements into work items, and helping the dev team. They can be the same person, but these are two different skill sets.”
But at SAS, we product managers were required to fill both those roles—and to do more as well. Speaking from 25 years of experience in the role(s). Now happily retired.
"You keep using that word ("agile"), but I don't think you know what it means." (Or, your management doesn't know what it means.)
We used agile principles when I was part of a small group at SAS 20+ years ago. Well before "agile" was a thing. The idea of small focused teams having the freedom to "self-organize" while working in close proximity to each other and the customer to deliver value. It worked great then...and it works great now.
Agile does not equate to sprints. Kanban is much better when it is agile.
Some of my teams use sprints and others Kanban. Both have advantages. Kanban is more likely to degenerate into waterfall. The teams are more likely to become "story slaves" and "feature factories." Always in "hurry up" mode.
Features and stories are much better than the old requirements documents and formal project plans we used to write. Sprints and Kanban are just how the teams manage the flow of the stories.
We do have to provide estimates to the business for how long the work will take. In my experience sprints are more accurate than Kanban. Perhaps, because the velocity of a team is a more comprehensive metric than story cycle time.
There are two distinct roles. The Product Manager is outwardly facing and focuses on gathering requirements from the customers. The Product Owner is inwardly facing and focused on translating requirements into work items, and helping the dev team. They can be the same person, but these are two different skill sets. Both are critical for success. The PM better be working closely with sales & marketing, or the product won't get sold, and your software will fail.
A critical factor hiding in all this is trust. Without it, you can't be agile.
same issues out here in the real world. management wanting "dashboards" has nothing to do with agile or no agile. it's its own disease. 5000 (probably vanity) metrics means none of them are "key". agile is more about "self organizing" teams, transparency, checking in often to stay in sync, not about b.s. management dashboards.
Agile is a scam but SAS and other companies have bought into it hook, line and sinker.
It has got to go after so many years of wasted productivity on meetings. Most companies do not use Agile properly anyway.
Agile was intended to replace Waterfall, but arguably it has evolved to become worse. Agile requires more meetings and produces more artifacts, which wastes more time.
If the Product Manager reports to Marketing, Agile also enables Marketing departments to increase their control. Because Marketing speaks the language of the customer, they tend to want to manage a list of features. Architecture, design patterns, refactoring, and other engineering concepts get lower priority. The development organization becomes a "Feature Factory".
Agile had good intentions -- like the road to He-l. Agile has been perverted, and should be abandoned.
Use Kanban instead. It's a lightweight methodology that prioritizes completed work -- instead of meetings and artifacts that give insecure managers the illusion of control.