This may vary from region to region, but my biggest issue with the present Agile trend is the cargo-culting of SCRUM. Sprints, standups, reviews and retros, planning poker, all followed blindly, but to no effect. Worse yet, the dreaded term "anti-agile" is used to shut down any other way of operating.
It has almost become a religion and any attempts at advocating planning discipline or detailed designs (even in domains where it's called for) are quickly labeled and rejected as "waterfall". Some project managers trained in agile methodologies have trouble grasping some basic common sense project management practices such as dependency tracking and capacity planning.
I recently gave up on all buzzwords and boiled the whole thing down to 3 things:
1. Deliver things in small, testable chunks
2. Start with a best-effort plan, but refine weekly based on how things went
3. If you're blocked or your work is at risk, let others know ASAP
The irony being that agile was meant to be a rejection of blindly following a ONE TRUE WAY. A major point was to periodically review your processes and adapt them to better suit your situation. The idea being you don't get locked in to a process that's no longer working and even have some freedom to experiment.
Exactly. Depending on the team, I usually try to start off using something mostly by the book and we adjust from there. Some teams need more structure and some suffocate under it.
A business has to understand that the processes that are best for software delivery are orthogonal to the ones that are best for business.
Namely, (good/agile) software development demands fluctuation and iteration where business plans seem to thrive on long-term forecasts and projections. Waterfall would absolutely be the best things for businesses... if it worked.
But I'm telling you people!, the earth revolves around the sun.
---Burn him!!!!
We're currently swallowing the Scaled Agile Framework pill and I honestly think that it's cause maybe 3 serious episode of depression and burnout in 7 person team.
We failed a sprint a while back. No one knew you could do that until we did.
Yeah but management consultants can't sell that as easily as they can sell a pre packaged "agile" solution like they do with SCRUM. Fundamentally, agile requires processes that are at odds with traditional management, so companies that sell buzzwords to traditional management aren't going to push anything that requires real behavioral change from the senior team.
It has almost become a religion and any attempts at advocating planning discipline or detailed designs (even in domains where it's called for) are quickly labeled and rejected as "waterfall". Some project managers trained in agile methodologies have trouble grasping some basic common sense project management practices such as dependency tracking and capacity planning.
I've seen it go wrong in both ways.
One project did BDUF and then planned it out as a 2 year series of sprints, delivering increments. The scrum master's job was to keep an eye on this macro-schedule and make small course corrections along the way to keep things on track. There were weekly demo's, but since there was no slack in the schedule there was no way to act on the feedback unless the next sprint involved building out the same set of screens. That project went ridiculously over budget, and ended up so unsuitable for the customer's needs that they didn't adopt it.
Another project avoided doing any design up front, because "that's not agile". In the course of the project it became apparent that several key architectural decisions were wrong due to requirements which were known at the start and which would have been apparent had an up-front design been made. These proved very costly to rework.
My conclusion is: (1) if there are requirements set in stone up front, do the design work necessary to fit those requirements at the start, and (2) don't translate that design to a schedule, but instead to a prioritized backlog, then go one sprint at a time without planning too far ahead. Management tends to get really jumpy at the last bit. They want to know the whole scope for the whole cost, up front, and that doesn't fit into an agile way of working. (It doesn't fit into any way of working, which is why so many projects go over budget, but that's a whole different can of worms.)
>Management tends to get really jumpy at the last bit. They want to know the whole scope for the whole cost, up front, and that doesn't fit into an agile way of working.
This is the delicious irony... management loves the idea of agile because finally those pesky developers will stop pushing back on the schedule with all their requirement demands and lengthy estimates! Go fast, weekly sprints! Daily updates! What do you mean you can't tell me the cost without gathering requirements? I saw so many organizations use Agile as a way to beat developers over the head, then be surprised at the anarchy that resulted.
This is exactly why agile failed, it became a religion and stopped being a tool you could modify as needed.
Like SCRUM, we use kanban boards to handle projects, but a lot of our projects are so small that one guy can build the project in a week or two. Like a registration form for scheduling phone calls, you need a front end form, a backend api and integration to outlook. The first time we build one it took longer, but now we can have one up and running in a week or two.
We place that on our kanban board and we talk about it SCRUM style, but it’s not it’s own project and it’s not broken in to every step of the SCRUM methodology either, because if we did that it would probably add a week of agile project management.
But since we’re not doing that it means that we’re not agile or using SCRUM, because we’ve bent it to our needs and broken it’s golsen dogmas.
Now I give quite a few management talks on this, and as soon as you admit that you’ve broken agile to make it fit, a line of others forms to confess. Because I don’t think I’ve ever met anyone outside of academia or extremely large tech projects that actually followed any of the agile methodologies to the letter.
So agile is just as silly as waterfall, maybe even more so because it turned out that the analysis part of waterfall is often still extremely useful if you’re mixing your tech with HR stuff like benefit realisation, and let’s face it, who in digitisation isn’t? I mean, we’re digitizing to increase efficiency after all, and nothing screams benefit realisation more than that.
Jeff Bezos once warned to "avoid proxies" and using fake scrum is a prime example. Scrum on its own is just a proxy for agility. Scrum done correctly can give you great agility. If you're running stand-ups and using a backlog but are unable to iterate quickly and deliver incremental value then you're failing at your actual goal.
Of course, agile itself can be considered a proxy because the ultimate goal is always customer value.
Some argue No True Scotsman. That is, any agile process can be faulted so we keep searching for a pure agile somewhere (that actually works). If true the lesson is, agile doesn't work anywhere (or nearly nowhere)
You can also argue that the original Communist Manifesto still stands up today, and that the problem is that genuine communism has never been put in place.
I’ve noticed, still after a decade, people who know what they’re doing will self organise into an “agile ish” way of working similar to the points you make.
If you prescribe it you end up with a mess every time.
Agile occurs naturally if you’re team isn’t dysfunctional. If you have to force it in, its dysfunctional.
Scrum isn't meant to solve problems, it's meant to reveal them so you and your team can solve them yourselves. Scrum is a framework and doesn't prescribe any development practices. Rather you use the framework and iteratively insert your own practices and processes, regularly inspecting and adapting those practices and processes over time to fit your goals.
Stop blaming the framework for a lack of discipline.
After my last gig I firmly believe that agile is a cargo cult: every morning sales and marketing did a standup. In a circle. At the peak about 50 of the org members.
1) Humans have an extremely limited capacity to determine what's true.
2) Our modus operandi is not to determine what is true but with which side are we politically affiliated
3) The truth is of little importance
This plays out exactly like you describe. A cargo-cult. You're either for or against it. You are either on the political side of the divide that believes being in the cult is better for ones survival or you are on the side that believes deep introspection about what is better for the situation at hand is best for survival. Close to nobody has the resources or capacity to evaluate if it's actually a good idea or not and even less so the political clout to sway the group for or against. So cargo-cult it is, for better or for worse.
TL;DR
The state of any development methodology you can give a name to and dogmatically adhere to: a shambles.
I would argue Agile is a Philosophy and Waterfall would be more of a Methodology. My biggest concern with Agile is that it's lacking integration with a methodology (ie: best practices of waterfall could be in an agile way). Companies and teams tend to just say lets do Agile/Scrum/Kanban and leave out the requirements definition, documentation, etc and replace it with "As a user create shiny button". Which, might be fine in some cases but as a new-start it lacks direction IMO.
All you need is a proper retrospective. And that's basically it.
In a proper retrospective, you can change anything you want, improve every step.
So all the problems that you mention, can all be addressed and improved, just as long as you have a good retrospective. Don't like planning poker? Do something else. Don't like standups? Change it.
I really wanted to agree with you, but your comment is mostly criticizing people doing agile without understanding it.
And yet, you 3 points prove that you don't understand agile either.
If feels like a bad driver honking at other cars.
All the points you cite are useful, but they are nowhere what agile is.
The most important thing about agile is __the emphasis on communication and a short feedback loop__.
You deliver things in small testable chunks because it's easier to ochestrate a team around that, and you get feedback sooner.
You refine weekly based on how things went because you can thanks to the regular feedback you get.
You let others know ASAP because you have regular communication.
You are making the same mistake as everybody: thinking agile is about a process, and hence, rules.
It's not.
Agile is a set of principles, which then you use to implement whatever rules and so, process, you need for your current situation. SCRUM is one way, XP is another.
Your agile and mine won't be the same. Mine today won't be the same as the one tomorrow.
Because what matters is communication and short feedback loops, and there are many ways to get that.
Sure, you can use proven tools and receipes. It's good. We all do it.
But it's no more agile that using a good knife is cuisine.
That's why there was a post-agile movement already like 5 years ago, but due to overwhelming bandwagoning of clueless PMs trained in "Agile" by big-bank "consultants" that stream seems to have died out.
I guess that SCRUM should have not been adopted as a mainstream/default agile process. I think that SCRUM can work for some teams, but it should be a niche in the world of agile development.
The problem is that people take it as a "best agile practice/process for every team". That is IMHO the biggest issue here.
After doing software for almost 30 years now, I honestly believe Agile has been the most destructive thing to happen to the industry. Software has become buggy shit that's shoveled out the door as fast as possible. It's not just your development team, it's all development teams.
Windows 10 update deleting your files? Is it the lack of testing, poor code quality, too many features or not enough engineers?
Ultimately it's going to boil down to some cargo cult scrum process of reviews, retros, and bs that we are all familiar with, and Windows 10 is buggy. Android is buggy. iOS is buggy. Nobody cares about the software. They blindly follow the process.
Honorable mention to the fact that software used to be a lot harder to distribute. Making disks and CDs was slow and expensive, but now we can push a patch any time over the Internet. Why not ship fast when shipping a patch is just easy?
I think it's safe to say that bugs are way more predominant in software that used to be reliable. It's not that the software was completely bug free, it's the quantity and quality of the bugs now being presented.
> Software has become buggy shit that's shoveled out the door as fast as possible.
This comes up a lot in dealing with PMs and those funneling requirements to developers: What is "good enough"?
"Good enough" for a software project means different things to different people, and is influenced by factors like time, cost, and attention.
Oftentimes, there's conflicting desires/statements from stakeholders in the Agile process. For example:
- Executives approve an iterative "MVP" software plan proposed by the PMs.
- PMs deliver plan to developers, and give them a schedule.
- Developers deliver the software "as-is" based on what was scoped in the MVP plan.
- Executives (or some other party) are demoed the software, and undoubtedly come up with list of things that could be done differently or questions like "Why don't we have this feature in..."
- PMs funnel down the executive feedback to the developers; developers say "This wasn't in scope for MVP..."
Where iteration and speed falls apart is when those judging the work want things to move out the door on schedule and as cheaply as possible, while still have the software fit their liking and follow an unrealistically ideal development path.
Agile Coach here, there’s more truth to this than you may know. I’ve commented here about this before.
With agile many companies (often helped by consultants) threw out what little design and engineering common sense we scraped together over the preceding decades and, in practice, made small teams of developers directly accountable to their customers. Whilst customers saw immediate benefit the loss of air cover from engineering leadership hath wrought a mess of technical debt the scale of which is hard to fathom.
I’m thoroughly fed up with my field. Agile coaches are, for the most part, fucking muppets with no significant engineering or leadership background. Fire them all.
I doubt you've been doing software for 30 years if you think software these days is buggy compared to software 20+ years ago. The amount of software these days is incredibly vast compared to back then, and the size of the software has increased, and the complexity has increased. Given all that, software these days is far less buggy.
Doesn't help of course, but high quality cannot be tested into a product.
I'd place more blame on inexperienced developers that don't know you should never delete user files unless completely sure they aren't needed. Even then they should be put in a backlog to be deleted later.
I've worked at four companies that have claimed to do agile development. Not one of them has deeply embraced the principles of doing so. Generally they have added a few easy practices, like stand-up meetings and sprints. They've kept large-scale chunks assigned to specific developers, defining both the work to be done and the time to do it, and substantial design docs. Unit testing tends to be spotty.
We're not living in Agile World. We're living in Fake Agile World.
I have some reservations about true-blue agile, but I'd be willing to give it a shot. Let's do Fundamentalist Scrum once. I'd be up for it. At least I'd know whether it works or not.
> And yet what I'm hearing so much is the Agile Industrial Complex imposing methods upon people, and that to me is an absolute travesty.
I find it depressing that Fowler sees the same problem I do. I have yet to find a shop that practices “agile” in a way that's actually consistent with the Agile Manifesto. What I've been seeing instead was micromanagement and cargo cult. All power to make decisions lies with management and if there are developers involved at all, it's the top one or two who are de facto part of management.
Agile methods do have a bit of a problem with the concept of authority. They really really want to believe that at least within a development team, everyone is equal. That's not a great fit to actual dev teams in companies where there are junior devs, senior devs, architects, and managers.
In my experience the power structure within the team is fairly flat, it's the managers outside the team that insist on having authority, micromanagement and veto rights over things they don't understand.
I'm thinking they make an effort to accommodate that. The poker idea is to average out the team's estimates which is shown to come to a reasonable number (adding up noisy signals equals a better signal). And the whole scrum thing is explicitly to let mentoring happen organically
I've seen the converse. "Empowered" teams arguing relentlessly with each other and other teams. It comes down to individuals regardless of what the methodology-du-jour is. Martin seems to think all we need is better tech skills.
I don't know if we practice "Agile Manifesto" or not but with our current flow[1] of collaboration and partnership we're pretty agile and able to respond to business reality within hours. Sometimes it's minutes depending on the complexity of the required "pivot" / refactoring. edit: also the team has no hierarchy and information silos. This trust builds a good rhythm.
I'm also trying to find and collaborate with a team which can do the same.
This might just be the best, well-balanced talk on how agile has gone wrong, and ways to combat the decay.
I've seen a lot great teams and poor teams operate. A common set of components in great teams: Technical excellence, freedom coupled with accountability and giving a shit about the quality of their work.
Poor teams: lack of discipline, not caring and poor technical skills.
I've also seen great teams fall apart due to external influence. That influence was agile gone wrong, imposed from the top. Freedom: gone, but accountability remains. Technical practices valued by the team: deprioritized by the process. Giving a shit: demotivation followed by quitting or being fired.
I started working with agile since day one and it was fun back then. Why? Because it made projects so much more interesting. We were learning how to do things differently and it was pretty cool. Unfortunately, it became more popular and upper management started looking at the benefits of Agile. “Tell me one reason why we should adopt agile in our company?”. Unfortunately, a good answer to that was the ability to track the progress and a large increase in delivery and productivity. Teams hate those words but management love them.
That’s what agile became today, tracking progress with constant status updates, charts and metrics that tell a team “clearly you did a really bad job this time” or “you’re late”. Management doesn’t even have to do the dirty job anymore. Meaningless meetings, less power for engineers, no creativity (ain’t got time for that!), etc.
It went from a cool way to do things to a perfect tool for factories. No offense to factory workers.
And the illusion of getting things done, because tickets! makes it seem like progress is happening even if churn is all that's happening. Last contract (I left) was 6 years into churning the same awful pile of spaghetti. I came on board to help break the logjam. Micromanaging Agile manager put me on fire fighting, just like all his other reports, just like the last 6 years of churning had done. Left after 6 months and it was obvious they were going nowhere.
Exactly. Doing Agile properly requires a bi-directional mutually respectful communication between the development team and the product stakeholders. It's the complete opposite of traditional suspicion-based hierarchical management. That's why it has so much difficulty getting adopted.
My problem with current "Agile" beyond the complaints in that talk is it can mean absolutely anything. Nothing is falsifiable, and the snake oil industry views that as a feature.
Most of that revolves around the way retrospectives are handled and the weird way in which "continuous improvement" is viewed. Agile sees this as continuous process improvement, instead of say, people improvement, team improvement, or software improvement. This process for creating process (aka "bureaucracy") has led to retrospectives evaluating things like burndowns, "What about our process went well?" or "What about our process didn't go well?", etc. Scrum has basically a built-in bias to destroy itself: "We've iterated into this super process-oriented way of doing work, and we did it in small steps.... Agile!!!"
I once made a comment that neither I, my company's customers, nor their customers were paid in story points. I still think that is the crux of why Scrum is so broken.
Agility will become more pronounced in software teams when the feedback mechanism ("retrospective") is based upon 1) qualitatively evaluating product success, and 2) quantitatively measuring something that is relevant to the product or business being built and not a peripheral concern like how much work was done or how it was done. Work done, predictability, and even lateness have very little to do with product success outside the realm of contracting.
Focusing on story points is not Scrum, so why blame Scrum? Rather it's clearly delineated that a Scrum team product owner's main job is to maximize the value delivered through development to the customer. 50 story points means nothing unless the PO has prioritized work that's going to yield the most value to the client.
Scrum isn't broken. It's literally all laid out in a 16 page document. Nowhere will you find mention of story points.
Stop blaming the framework for someone's bastardization of what said framework is meant to achieve.
>We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile', we've got to come up with some new word," - but that doesn't help the fundamental problem. It's the values and principles that count and we have to address and keep pushing those forwards and we might as well use the same label, but we've got to let people know what it really stands for.
The heart of the problem he's describing here stems from the fact that those principles were originally quite vague:
* Individuals and interactions over processes and tools (does this mean prefer meetings to writing tests and creating a CI pipeline?)
* Working software over comprehensive documentation (don't write documentation? do write documentation? Why not both? Moreover even the most waterfall of companies I've seen have never actually prioritized documentation over working software)
* Customer collaboration over contract negotiation (never did encounter a situation where this principle could even be applied... does this phrase use contract negotiation as a metaphor or is he talking about literal contract negotiation?)
* Responding to change over following a plan (he actually complains in this article that he never meant "don't plan"... idk)
Contrast that with, say "develop iteratively, in small chunks and, where feasible write the test first and release frequently and talk regularly with the customer" -- those are specific principles.
If you create a vague set of principles surrounding an idea that resonates deeply with people then the emergence of a "priesthood" that doesn't necessarily agree with your original intentions is somewhat inevitable, no?
Yes, the values are too vague. The twelve principles are better for conveying what Agile is trying to be.
The "responding to change" point means in practice that it's better to deviate from a plan than to not have any plan to deviate from. The plan has to be adjusted all the time. For that to be possible, there has to be a plan.
The twelve principles are very basic, common sense. Common sense is not common though.
I've always found it hilarious that what we see today from the Agile industry can in no way have come from such vague statements. 99% of Agile is shit people who weren't part of the original group made up so they could sell and the 1% if Agile that's actually real isn't specific enough to mean anything more than "do stuff".
Readit News
It has almost become a religion and any attempts at advocating planning discipline or detailed designs (even in domains where it's called for) are quickly labeled and rejected as "waterfall". Some project managers trained in agile methodologies have trouble grasping some basic common sense project management practices such as dependency tracking and capacity planning.
I recently gave up on all buzzwords and boiled the whole thing down to 3 things:
1. Deliver things in small, testable chunks
2. Start with a best-effort plan, but refine weekly based on how things went
3. If you're blocked or your work is at risk, let others know ASAP
A business has to understand that the processes that are best for software delivery are orthogonal to the ones that are best for business.
Namely, (good/agile) software development demands fluctuation and iteration where business plans seem to thrive on long-term forecasts and projections. Waterfall would absolutely be the best things for businesses... if it worked.
We're currently swallowing the Scaled Agile Framework pill and I honestly think that it's cause maybe 3 serious episode of depression and burnout in 7 person team.
We failed a sprint a while back. No one knew you could do that until we did.
So at least we're learning.
The same holds true for all religions. However many believers nowadays defend it as there was only one true way.
I've seen it go wrong in both ways.
One project did BDUF and then planned it out as a 2 year series of sprints, delivering increments. The scrum master's job was to keep an eye on this macro-schedule and make small course corrections along the way to keep things on track. There were weekly demo's, but since there was no slack in the schedule there was no way to act on the feedback unless the next sprint involved building out the same set of screens. That project went ridiculously over budget, and ended up so unsuitable for the customer's needs that they didn't adopt it.
Another project avoided doing any design up front, because "that's not agile". In the course of the project it became apparent that several key architectural decisions were wrong due to requirements which were known at the start and which would have been apparent had an up-front design been made. These proved very costly to rework.
My conclusion is: (1) if there are requirements set in stone up front, do the design work necessary to fit those requirements at the start, and (2) don't translate that design to a schedule, but instead to a prioritized backlog, then go one sprint at a time without planning too far ahead. Management tends to get really jumpy at the last bit. They want to know the whole scope for the whole cost, up front, and that doesn't fit into an agile way of working. (It doesn't fit into any way of working, which is why so many projects go over budget, but that's a whole different can of worms.)
This is the delicious irony... management loves the idea of agile because finally those pesky developers will stop pushing back on the schedule with all their requirement demands and lengthy estimates! Go fast, weekly sprints! Daily updates! What do you mean you can't tell me the cost without gathering requirements? I saw so many organizations use Agile as a way to beat developers over the head, then be surprised at the anarchy that resulted.
This is quite true. I often frame this as "design detail is inversely proportional to requirements volatility"
Like SCRUM, we use kanban boards to handle projects, but a lot of our projects are so small that one guy can build the project in a week or two. Like a registration form for scheduling phone calls, you need a front end form, a backend api and integration to outlook. The first time we build one it took longer, but now we can have one up and running in a week or two.
We place that on our kanban board and we talk about it SCRUM style, but it’s not it’s own project and it’s not broken in to every step of the SCRUM methodology either, because if we did that it would probably add a week of agile project management.
But since we’re not doing that it means that we’re not agile or using SCRUM, because we’ve bent it to our needs and broken it’s golsen dogmas.
Now I give quite a few management talks on this, and as soon as you admit that you’ve broken agile to make it fit, a line of others forms to confess. Because I don’t think I’ve ever met anyone outside of academia or extremely large tech projects that actually followed any of the agile methodologies to the letter.
So agile is just as silly as waterfall, maybe even more so because it turned out that the analysis part of waterfall is often still extremely useful if you’re mixing your tech with HR stuff like benefit realisation, and let’s face it, who in digitisation isn’t? I mean, we’re digitizing to increase efficiency after all, and nothing screams benefit realisation more than that.
Of course, agile itself can be considered a proxy because the ultimate goal is always customer value.
Deleted Comment
e.g. World Cup themed retro, describe how the sprint went for you as one of the World Cup teams.
Christ, really? What nonsense.
It just ended up with cringey comments as people try to shoehorn something into being world cup related (or whatever the theme was). Just silly.
I'd be tempted to say "I was Scotland - we didn't qualify" ;-)
If you prescribe it you end up with a mess every time.
Agile occurs naturally if you’re team isn’t dysfunctional. If you have to force it in, its dysfunctional.
Stop blaming the framework for a lack of discipline.
Cowboy coding isn't agile.
After my last gig I firmly believe that agile is a cargo cult: every morning sales and marketing did a standup. In a circle. At the peak about 50 of the org members.
It's "scrum" that appears to be the problem...
I've come to realize a few key things:
1) Humans have an extremely limited capacity to determine what's true. 2) Our modus operandi is not to determine what is true but with which side are we politically affiliated 3) The truth is of little importance
This plays out exactly like you describe. A cargo-cult. You're either for or against it. You are either on the political side of the divide that believes being in the cult is better for ones survival or you are on the side that believes deep introspection about what is better for the situation at hand is best for survival. Close to nobody has the resources or capacity to evaluate if it's actually a good idea or not and even less so the political clout to sway the group for or against. So cargo-cult it is, for better or for worse.
TL;DR The state of any development methodology you can give a name to and dogmatically adhere to: a shambles.
It's a little shocking how common the groupthink was, and no one dared speak against it, so it's nice to see people speaking freely here.
Agile makes me want to leave software entirely.
In a proper retrospective, you can change anything you want, improve every step.
So all the problems that you mention, can all be addressed and improved, just as long as you have a good retrospective. Don't like planning poker? Do something else. Don't like standups? Change it.
And yet, you 3 points prove that you don't understand agile either.
If feels like a bad driver honking at other cars.
All the points you cite are useful, but they are nowhere what agile is.
The most important thing about agile is __the emphasis on communication and a short feedback loop__.
You deliver things in small testable chunks because it's easier to ochestrate a team around that, and you get feedback sooner.
You refine weekly based on how things went because you can thanks to the regular feedback you get.
You let others know ASAP because you have regular communication.
You are making the same mistake as everybody: thinking agile is about a process, and hence, rules.
It's not.
Agile is a set of principles, which then you use to implement whatever rules and so, process, you need for your current situation. SCRUM is one way, XP is another.
Your agile and mine won't be the same. Mine today won't be the same as the one tomorrow.
Because what matters is communication and short feedback loops, and there are many ways to get that.
Sure, you can use proven tools and receipes. It's good. We all do it.
But it's no more agile that using a good knife is cuisine.
The problem is that people take it as a "best agile practice/process for every team". That is IMHO the biggest issue here.
I wrote an article about my experiences with SCRUM which I named "Why SCRUM doesn't work" :-) You can read it here: https://stribny.name/blog/2018/05/why-scrum-doesnt-work
I'd be interested in any opinions about this.
Windows 10 update deleting your files? Is it the lack of testing, poor code quality, too many features or not enough engineers?
Ultimately it's going to boil down to some cargo cult scrum process of reviews, retros, and bs that we are all familiar with, and Windows 10 is buggy. Android is buggy. iOS is buggy. Nobody cares about the software. They blindly follow the process.
Let's not pretend bugs didn't exist in the pre-agile/scrum era. Bugs have been around as long as software has been around.
This comes up a lot in dealing with PMs and those funneling requirements to developers: What is "good enough"?
"Good enough" for a software project means different things to different people, and is influenced by factors like time, cost, and attention.
Oftentimes, there's conflicting desires/statements from stakeholders in the Agile process. For example: - Executives approve an iterative "MVP" software plan proposed by the PMs. - PMs deliver plan to developers, and give them a schedule. - Developers deliver the software "as-is" based on what was scoped in the MVP plan. - Executives (or some other party) are demoed the software, and undoubtedly come up with list of things that could be done differently or questions like "Why don't we have this feature in..." - PMs funnel down the executive feedback to the developers; developers say "This wasn't in scope for MVP..."
Where iteration and speed falls apart is when those judging the work want things to move out the door on schedule and as cheaply as possible, while still have the software fit their liking and follow an unrealistically ideal development path.
* Agile, the good bad and ugly by Bertrand Meyer
* Balancing agility and discipline by Boehm
With agile many companies (often helped by consultants) threw out what little design and engineering common sense we scraped together over the preceding decades and, in practice, made small teams of developers directly accountable to their customers. Whilst customers saw immediate benefit the loss of air cover from engineering leadership hath wrought a mess of technical debt the scale of which is hard to fathom.
I’m thoroughly fed up with my field. Agile coaches are, for the most part, fucking muppets with no significant engineering or leadership background. Fire them all.
How are you measuring it? Where do you get your numbers? What are your numbers, for that matter?
Except those unit tests get a lower priority than writing documentation.
And we all know which priority writing documentation gets.
I'd place more blame on inexperienced developers that don't know you should never delete user files unless completely sure they aren't needed. Even then they should be put in a backlog to be deleted later.
We're not living in Agile World. We're living in Fake Agile World.
I have some reservations about true-blue agile, but I'd be willing to give it a shot. Let's do Fundamentalist Scrum once. I'd be up for it. At least I'd know whether it works or not.
I find it depressing that Fowler sees the same problem I do. I have yet to find a shop that practices “agile” in a way that's actually consistent with the Agile Manifesto. What I've been seeing instead was micromanagement and cargo cult. All power to make decisions lies with management and if there are developers involved at all, it's the top one or two who are de facto part of management.
Then they'll wonder why the experienced people quit.
I don't know if we practice "Agile Manifesto" or not but with our current flow[1] of collaboration and partnership we're pretty agile and able to respond to business reality within hours. Sometimes it's minutes depending on the complexity of the required "pivot" / refactoring. edit: also the team has no hierarchy and information silos. This trust builds a good rhythm.
I'm also trying to find and collaborate with a team which can do the same.
[1] http://tales.camplight.net/post/169889253916/how-we-develop-...
I've seen a lot great teams and poor teams operate. A common set of components in great teams: Technical excellence, freedom coupled with accountability and giving a shit about the quality of their work.
Poor teams: lack of discipline, not caring and poor technical skills.
I've also seen great teams fall apart due to external influence. That influence was agile gone wrong, imposed from the top. Freedom: gone, but accountability remains. Technical practices valued by the team: deprioritized by the process. Giving a shit: demotivation followed by quitting or being fired.
That’s what agile became today, tracking progress with constant status updates, charts and metrics that tell a team “clearly you did a really bad job this time” or “you’re late”. Management doesn’t even have to do the dirty job anymore. Meaningless meetings, less power for engineers, no creativity (ain’t got time for that!), etc.
It went from a cool way to do things to a perfect tool for factories. No offense to factory workers.
Most of that revolves around the way retrospectives are handled and the weird way in which "continuous improvement" is viewed. Agile sees this as continuous process improvement, instead of say, people improvement, team improvement, or software improvement. This process for creating process (aka "bureaucracy") has led to retrospectives evaluating things like burndowns, "What about our process went well?" or "What about our process didn't go well?", etc. Scrum has basically a built-in bias to destroy itself: "We've iterated into this super process-oriented way of doing work, and we did it in small steps.... Agile!!!"
I once made a comment that neither I, my company's customers, nor their customers were paid in story points. I still think that is the crux of why Scrum is so broken.
Agility will become more pronounced in software teams when the feedback mechanism ("retrospective") is based upon 1) qualitatively evaluating product success, and 2) quantitatively measuring something that is relevant to the product or business being built and not a peripheral concern like how much work was done or how it was done. Work done, predictability, and even lateness have very little to do with product success outside the realm of contracting.
Scrum isn't broken. It's literally all laid out in a 16 page document. Nowhere will you find mention of story points.
Stop blaming the framework for someone's bastardization of what said framework is meant to achieve.
The heart of the problem he's describing here stems from the fact that those principles were originally quite vague:
* Individuals and interactions over processes and tools (does this mean prefer meetings to writing tests and creating a CI pipeline?)
* Working software over comprehensive documentation (don't write documentation? do write documentation? Why not both? Moreover even the most waterfall of companies I've seen have never actually prioritized documentation over working software)
* Customer collaboration over contract negotiation (never did encounter a situation where this principle could even be applied... does this phrase use contract negotiation as a metaphor or is he talking about literal contract negotiation?)
* Responding to change over following a plan (he actually complains in this article that he never meant "don't plan"... idk)
Contrast that with, say "develop iteratively, in small chunks and, where feasible write the test first and release frequently and talk regularly with the customer" -- those are specific principles.
If you create a vague set of principles surrounding an idea that resonates deeply with people then the emergence of a "priesthood" that doesn't necessarily agree with your original intentions is somewhat inevitable, no?
The "responding to change" point means in practice that it's better to deviate from a plan than to not have any plan to deviate from. The plan has to be adjusted all the time. For that to be possible, there has to be a plan.
The twelve principles are very basic, common sense. Common sense is not common though.