Why don’t software development methodologies work? (2014)(typicalprogrammer.com)
typicalprogrammer.com
Why don’t software development methodologies work? (2014)
https://typicalprogrammer.com/why-dont-software-development-methodologies-work
148 comments
Point 3 is very true.
In my company at the time, they had a million rules and processes, but everybody had to drop everything because the son of an influential client could not get toy cars (!) into the new enterprise retail procurement system because of some incorrect logistical data. Normally you would get a ticket, analyze etc.
But he was the loudest/most influential, so everything else was unimportant. No Jira, nothing, just one angry email. Fix it for him alone, NOW! Billion-dollar company, thousands of clients but a dude with 20 toy cars won.
The issue was resolved (we removed the validation rules that were implemented before because "this is the filter for incorrect data, and we want to clear our data by restricting them") and everything went back to normal. Jiras, process and so on.
In my company at the time, they had a million rules and processes, but everybody had to drop everything because the son of an influential client could not get toy cars (!) into the new enterprise retail procurement system because of some incorrect logistical data. Normally you would get a ticket, analyze etc.
But he was the loudest/most influential, so everything else was unimportant. No Jira, nothing, just one angry email. Fix it for him alone, NOW! Billion-dollar company, thousands of clients but a dude with 20 toy cars won.
The issue was resolved (we removed the validation rules that were implemented before because "this is the filter for incorrect data, and we want to clear our data by restricting them") and everything went back to normal. Jiras, process and so on.
> everything else was unimportant, no Jira, nothing
Well, until review time - then, "why didn't you make any progress on your Jira tickets?"
Well, until review time - then, "why didn't you make any progress on your Jira tickets?"
One of the reasons why I would just open a Jira ticket anyway, process be damned. If I’m suspending work on a P1 because of this ticket, I’m gonna mark this ticket at least a P1. If management wants me to complete it within X hours, then I can find the priority level that matches the X-hour turnaround time.
I have found that many many developers are averse to tickets and complain about having to create tickets (like we see in a sibling of yours). I don't see why. It's really not that hard in most places to create one. Even in large and bureaucratic ones.
I always found that tickets are protection. When you're being asked to "drop everything for X", my first thought is to create a ticket for my own protection. At the least I can track the fact that I had to spend N hours on this thing X and I can refer back to it. At best I can document the stupidity of the whole thing w/ the ticket contents.
If you're in a place like my sibling where they ban creating a ticket yourself and assigning yourself: run. That's so stupid for so many reason that it's not even funny any longer
I always found that tickets are protection. When you're being asked to "drop everything for X", my first thought is to create a ticket for my own protection. At the least I can track the fact that I had to spend N hours on this thing X and I can refer back to it. At best I can document the stupidity of the whole thing w/ the ticket contents.
If you're in a place like my sibling where they ban creating a ticket yourself and assigning yourself: run. That's so stupid for so many reason that it's not even funny any longer
"I have found that many many developers are averse to tickets and complain about having to create tickets (like we see in a sibling of yours)."
I can give you my answer: Because the ticketing system is painfully slow to log in to, create the ticket, move it to the proper status, etc. Single sign on can make things worse too. The whole process can add up to easily a minute, and not a productive minute of the actual filing (I would be fine with that) but a minute of poking at things.
This does not make you wrong. If you want to say there's some laziness there, yeah, maybe. But it's not just laziness, there's a psychological torture aspect to it all too that is, if not "objectively" true, then at least not entirely my imagination either.
I really, really, really wish Atlassian would basically drop everything for a quarter or two and work on the speed of their products. There shouldn't be a fundamental reason why their stuff is so slow.
I can give you my answer: Because the ticketing system is painfully slow to log in to, create the ticket, move it to the proper status, etc. Single sign on can make things worse too. The whole process can add up to easily a minute, and not a productive minute of the actual filing (I would be fine with that) but a minute of poking at things.
This does not make you wrong. If you want to say there's some laziness there, yeah, maybe. But it's not just laziness, there's a psychological torture aspect to it all too that is, if not "objectively" true, then at least not entirely my imagination either.
I really, really, really wish Atlassian would basically drop everything for a quarter or two and work on the speed of their products. There shouldn't be a fundamental reason why their stuff is so slow.
Not to say your experience isn't awful but have you actually timed this? (also Cloud vs. Server can make a huge difference - Cloud being faster even if their recent UI changes aren't all great).
Login processes can suck. Absolutely. But like you say, single sign-on means you should at max be logging in once per day if not even less.
So just for giggles I timed various things in our instance for you. I have a logged in single sign-on session already.
Opening the Jira instance to my default dashboard until I could conceivably click on the "Create" button: 3.5s
Click the "Create" button until I could start typing into the summary field (while the rest still loads): 1.1s
Now as for filling out what you need, that obviously depends on your company and they can make it a pain, agreed. If we're talking about the "someone tells you drop everything now and to work on X" I doubt it takes more than 30 seconds to fill in even one of the "wild" issue creation screens. I mean you literally have to type something like "Exec B made me work on X" into both the summary and the description field, maybe choose an issue type and select the first value of any dropdown required fields and type "a" into any required input fields.
Actual ticket creation duration shouldn't take much longer either and even if, who cares? By that time I'm already back in my IDE.
Login processes can suck. Absolutely. But like you say, single sign-on means you should at max be logging in once per day if not even less.
So just for giggles I timed various things in our instance for you. I have a logged in single sign-on session already.
Opening the Jira instance to my default dashboard until I could conceivably click on the "Create" button: 3.5s
Click the "Create" button until I could start typing into the summary field (while the rest still loads): 1.1s
Now as for filling out what you need, that obviously depends on your company and they can make it a pain, agreed. If we're talking about the "someone tells you drop everything now and to work on X" I doubt it takes more than 30 seconds to fill in even one of the "wild" issue creation screens. I mean you literally have to type something like "Exec B made me work on X" into both the summary and the description field, maybe choose an issue type and select the first value of any dropdown required fields and type "a" into any required input fields.
Actual ticket creation duration shouldn't take much longer either and even if, who cares? By that time I'm already back in my IDE.
> have you actually timed this?
I'm not who you're asking, but I have timed this at multiple workplaces. The most egregious example took 32 minutes end-to-end (for many reasons: Jira was behind a VPN, which was extremely slow to login and even slower to actually use, the SSO system only allowed a session to persist for an hour, the server actually running Jira was underspec'd, the ticket template was incredibly verbose, etc, etc, etc). I am excluding the time it took to type the ticket in the first place (I wrote up the text beforehand and copy/pasted it into the fields) and including the time it takes to sign in to SSO, log into the VPN, browse to the ticketing system, etc. Essentially, I assume that it's the start of a work day and the only thing I've done is boot up my machine. Excluding the 32-minute workplace, I've got an average of ~9.5 minutes (only one was < 60 seconds).
While many workplaces have good systems, don't assume that every workplace does. There are many out there who accept/mandate potato-quality tools.
I'm not who you're asking, but I have timed this at multiple workplaces. The most egregious example took 32 minutes end-to-end (for many reasons: Jira was behind a VPN, which was extremely slow to login and even slower to actually use, the SSO system only allowed a session to persist for an hour, the server actually running Jira was underspec'd, the ticket template was incredibly verbose, etc, etc, etc). I am excluding the time it took to type the ticket in the first place (I wrote up the text beforehand and copy/pasted it into the fields) and including the time it takes to sign in to SSO, log into the VPN, browse to the ticketing system, etc. Essentially, I assume that it's the start of a work day and the only thing I've done is boot up my machine. Excluding the 32-minute workplace, I've got an average of ~9.5 minutes (only one was < 60 seconds).
While many workplaces have good systems, don't assume that every workplace does. There are many out there who accept/mandate potato-quality tools.
Hehe fair enough for your case. Yes, those absolutely exist. If you're not working for a military contractor or something there I hope you ran a long time ago. This seems to indicate that a lot of other things would be wrong with that place too.
I asked my parent if he timed it, because he mentioned "a minute". Lots of things feel longer to us than they actually are. If you're waiting for something to open or react to a click or other input even half a second can feel long and we're bound to say things like "whoa that took like 30 seconds, WTF!". But when you time it, it actually takes way less.
E.g. opening an issue directly from a new tab in Jira takes about 5 seconds for me in my quick test for example. Yes, that's absolutely a "long" time for what it ultimately needs to display and do. But it's also nowhere near a minute and if all you gotta do is to open a ticket someone sent you because you're supposed to "work on ASAP", these 5 seconds don't matter. You'll wait about the same time to run your unit tests after making the required change. You'll wait way longer to run the entire test suite etc.
I asked my parent if he timed it, because he mentioned "a minute". Lots of things feel longer to us than they actually are. If you're waiting for something to open or react to a click or other input even half a second can feel long and we're bound to say things like "whoa that took like 30 seconds, WTF!". But when you time it, it actually takes way less.
E.g. opening an issue directly from a new tab in Jira takes about 5 seconds for me in my quick test for example. Yes, that's absolutely a "long" time for what it ultimately needs to display and do. But it's also nowhere near a minute and if all you gotta do is to open a ticket someone sent you because you're supposed to "work on ASAP", these 5 seconds don't matter. You'll wait about the same time to run your unit tests after making the required change. You'll wait way longer to run the entire test suite etc.
We use cloud Jira, without any sort of crazy customization. This morning, I wanted to unsubscribe from a ticket.
It took about 15 seconds to load the ticket page, and another 5 seconds to process the unsubscribe. I just tried again now, and it took "just" 3 or so seconds to load the ticket page.
Their p50 time is already unacceptable, and their p90 time is completely absurd.
We've known what acceptable delays are since 1968[1]! Why is it so hard to build software that meets these requirements? Our computers are only 20 million times faster than back then...
[1]: https://dl.acm.org/doi/10.1145/1476589.1476628
It took about 15 seconds to load the ticket page, and another 5 seconds to process the unsubscribe. I just tried again now, and it took "just" 3 or so seconds to load the ticket page.
Their p50 time is already unacceptable, and their p90 time is completely absurd.
We've known what acceptable delays are since 1968[1]! Why is it so hard to build software that meets these requirements? Our computers are only 20 million times faster than back then...
[1]: https://dl.acm.org/doi/10.1145/1476589.1476628
> Why is it so hard to build software that meets these requirements?
At the same time, why would they? Your employer bought it anyway. And I guess the execs won't notice these HN discussions ...
At the same time, why would they? Your employer bought it anyway. And I guess the execs won't notice these HN discussions ...
Try Linear[1] and let me know if you have ideas how to sell speed to program management or execs. Startups get it, it’s more rare that large companies see the value.
[1]: https://linear.app/
[1]: https://linear.app/
The worse is maybe not the total time in itself but the lag effect.
It is annoying to click on something and wait 4-10s for the page/board to load or the login redirect dance to be completed.
So, what happens is that you click, and you go to do something else like reading another page in the meantime.
And then you completely forgot what you were about to do and when you remember you are already logged out or you have to refresh the board again, and it is slow again, so you go do something else in the meantime, etc...
And so on you lose a lot of time with frustration.
It is annoying to click on something and wait 4-10s for the page/board to load or the login redirect dance to be completed.
So, what happens is that you click, and you go to do something else like reading another page in the meantime.
And then you completely forgot what you were about to do and when you remember you are already logged out or you have to refresh the board again, and it is slow again, so you go do something else in the meantime, etc...
And so on you lose a lot of time with frustration.
Yes, agreed.
I think many developers have a vague understanding of how companies work and how their role fits into the company at large. I know a lot of developers who want to focus only on solving technical problems, want to be given the freedom to make technical problems, and want to have the other problems solved by everyone else.
If you’re focusing on technical problems, a ticketing system is a burden imposed on you by management. If your priority is the success of your entire team rather than the success of your own technical decisions, then you’d understand that visibility of your work, your thought process, how you justify decisions, is all critical knowledge that a ticketing system serves to record and disseminate.
I can’t count the number of times where I found a reference to a bug in a piece of code like:
I think many developers have a vague understanding of how companies work and how their role fits into the company at large. I know a lot of developers who want to focus only on solving technical problems, want to be given the freedom to make technical problems, and want to have the other problems solved by everyone else.
If you’re focusing on technical problems, a ticketing system is a burden imposed on you by management. If your priority is the success of your entire team rather than the success of your own technical decisions, then you’d understand that visibility of your work, your thought process, how you justify decisions, is all critical knowledge that a ticketing system serves to record and disseminate.
I can’t count the number of times where I found a reference to a bug in a piece of code like:
// Release gadget early to avoid starving froopy pipeline,
// see bug #12345.
> want to have the other problems solved by everyone else
In other words, do their job and not do everybody else's job for them? Or conversely, get paid everybody else's salary since we're already doing all of their jobs?
In other words, do their job and not do everybody else's job for them? Or conversely, get paid everybody else's salary since we're already doing all of their jobs?
Are you trying to make a point? Could you make the point directly, rather than make some vague, sarcastic comment?
If I’m interpreting your comment correctly, there’s a lot wrong with what you’re saying. First, the “job” that computer programmers do is much more than just writing code and designing systems. Computer programmers are expected to prioritize work, advocate for work that they think is important, gather requirements from stakeholders, make decisions about who holds various responsibilities, document and communicate the process to team members, and disseminate knowledge about how systems work to others. Just for starters.
Second,
> Or conversely, get paid everybody else's salary since we're already doing all of their jobs?
1. Computer programmers are paid generously, at least where I live. One of the reasons we are paid generously is because computer programmers are very efficient at getting work done that may otherwise need many people.
2. It’s not somebody else’s job to follow you around and document what you’re doing and justify it. It never was. It was always your job.
“Keep your head down and just do good work” is a kind of hyper-individualistic fantasy. It’s the fantasy where you’re some kind of powerhouse getting work done in your own world, and you do not need to advocate for what you feel is important. That’s what I’m arguing against. The technical part of our jobs is only one part of it, and you can’t make a good team out of several highly skilled programmers if they only have technical skills.
If I’m interpreting your comment correctly, there’s a lot wrong with what you’re saying. First, the “job” that computer programmers do is much more than just writing code and designing systems. Computer programmers are expected to prioritize work, advocate for work that they think is important, gather requirements from stakeholders, make decisions about who holds various responsibilities, document and communicate the process to team members, and disseminate knowledge about how systems work to others. Just for starters.
Second,
> Or conversely, get paid everybody else's salary since we're already doing all of their jobs?
1. Computer programmers are paid generously, at least where I live. One of the reasons we are paid generously is because computer programmers are very efficient at getting work done that may otherwise need many people.
2. It’s not somebody else’s job to follow you around and document what you’re doing and justify it. It never was. It was always your job.
“Keep your head down and just do good work” is a kind of hyper-individualistic fantasy. It’s the fantasy where you’re some kind of powerhouse getting work done in your own world, and you do not need to advocate for what you feel is important. That’s what I’m arguing against. The technical part of our jobs is only one part of it, and you can’t make a good team out of several highly skilled programmers if they only have technical skills.
And then there was the place that (when I started) used Remedy. (Ever seen the ticket creation process there? Of course, only customer-facing people were supposed to create them.) That wasn't good enough, so they added a customized Jira for the devs to track their activities. (A Jira ticket had to be associated with a Remedy ticket, even for new development.) And finally, they slathered on a layer of Rally on top to make sure we were suitably Agile.
Fortunately, now, we're SAFe.
Fortunately, now, we're SAFe.
That's I guess where the "most" comes in ;) Yes unfortunately I have seen other systems than Jira and most are awful. That's another thing developers complain about a lot: Jira. I find Jira is a breath of fresh air compared to traditional systems and fortunately in most places devs only deal w/ Jira like in the case you described.
Were you unlucky enough that they actually had checks in place or was it the typical "these systems are 'integrated' but not really"? If no checks, then to hell with the remedy ticket. I'm not putting any. If it only checks for not-empty field, I'll fill in junk. If they do check existence, I'll find an unlucky Remedy ticket that gets stuck with all my Jira tickets. If they check that the Remedy ticket is actually still open, I'll somehow find one of those Remedy tickets that are forgotten and hopefully will never be found and cleaned up (unlikely anyway) and that one gets stuck with all my Jira tickets. If only one Jira ticket can get associated with each Remedy ticket (which is again stupid for so many reasons ...) I'll use subtasks on one special "junkyard" Jira ticket.
I'm sure there are more cases you can think of and where we can find workarounds that still allow me to publicly document what I worked on.
Were you unlucky enough that they actually had checks in place or was it the typical "these systems are 'integrated' but not really"? If no checks, then to hell with the remedy ticket. I'm not putting any. If it only checks for not-empty field, I'll fill in junk. If they do check existence, I'll find an unlucky Remedy ticket that gets stuck with all my Jira tickets. If they check that the Remedy ticket is actually still open, I'll somehow find one of those Remedy tickets that are forgotten and hopefully will never be found and cleaned up (unlikely anyway) and that one gets stuck with all my Jira tickets. If only one Jira ticket can get associated with each Remedy ticket (which is again stupid for so many reasons ...) I'll use subtasks on one special "junkyard" Jira ticket.
I'm sure there are more cases you can think of and where we can find workarounds that still allow me to publicly document what I worked on.
When I have aversion to creating a ticket, it's around the weight of the ticket to create.
What I generally want is someplace to cheaply mark an action item to create a ticket, so I can jot down a quick idea, then come back to write the heavy weight ticket from that later.
If I'm aiming to jot something down, it's because im focused on a work item, and don't want to fully context switch away from that item and into the user story and background details for the new ticket. It's not that it's hard to write the ticket, but it's hard to resume the work you were doing before you were prompted to open a ticket
What I generally want is someplace to cheaply mark an action item to create a ticket, so I can jot down a quick idea, then come back to write the heavy weight ticket from that later.
If I'm aiming to jot something down, it's because im focused on a work item, and don't want to fully context switch away from that item and into the user story and background details for the new ticket. It's not that it's hard to write the ticket, but it's hard to resume the work you were doing before you were prompted to open a ticket
> I have found that many many developers are averse to tickets and complain about having to create tickets
FWIW: I've consulted at places in the past where developers couldn't create tickets, only update them. It was most definitely a way to attempt to keep them under control and harder to advocate for themselves.
FWIW: I've consulted at places in the past where developers couldn't create tickets, only update them. It was most definitely a way to attempt to keep them under control and harder to advocate for themselves.
Ideal process IMO is that developers should casually drop some lines in the chat like "we need to refactor ScaryService some day. Some manager carefully reads that chat and creates ticket in the backlog with link to the conversation. There's friction and there're people who supposed to support processes and can ease this friction.
It's telling that your given reason for tickets is 'protection'.
I usually do. I once worked for one company that was so dysfunctional that they implemented a rule that made it impossible to open a ticket and assign it to yourself to prohibit that.
Then in your retro meeting the manager/TPM/etc. talks about how we need a better process which results in nothing changing apart from more tickets to create.
In those cases you open the ticket and assign it to yourself, "for tracking purposes."
And I think #2 and #3 is why #1 is true. Or put differently, my experience in changing processes in many places has convinced me that unspoken management dynamics are what really matter, and that most managers will resent any process change that makes the actual management dynamics obvious.
For example, one way to classify process changes is when they make problems obvious. E.g., a release-early, release-often approach makes problems visible early on. And I've had great luck with them on teams that are actually trying to succeed, because faster feedback means faster learning. But most organizations reject that because actual success doesn't matter nearly as much as managerial appearance of success. Many managers thus hate fast-feedback processes because they would rather hide negative information, even if that makes long-term success much less likely. But they like the appearance of success that comes with using the latest buzzwords. This results in the common pattern of the manager who talks Agile but whose projects are in effect waterfall.
One book really helpful to me here looks at the default ideology of current management: https://www.amazon.com/Confronting-Managerialism-Business-Ec...
For example, one way to classify process changes is when they make problems obvious. E.g., a release-early, release-often approach makes problems visible early on. And I've had great luck with them on teams that are actually trying to succeed, because faster feedback means faster learning. But most organizations reject that because actual success doesn't matter nearly as much as managerial appearance of success. Many managers thus hate fast-feedback processes because they would rather hide negative information, even if that makes long-term success much less likely. But they like the appearance of success that comes with using the latest buzzwords. This results in the common pattern of the manager who talks Agile but whose projects are in effect waterfall.
One book really helpful to me here looks at the default ideology of current management: https://www.amazon.com/Confronting-Managerialism-Business-Ec...
In many enterprise software markets, customers legitimately hate frequent releases. Each new release may force them to retrain employees, do their own compatibility testing with third-party systems, and possibly even go through some sort of expensive legal compliance process. It's a good discipline to always keep the main repo branch in a fully releasable state, but only push out actual releases on a slower schedule.
I agree that for certain legacy markets that's the case, but I don't think that's the future of software. One of the things that distinguishes enterprise software is how little the users or their experience matter to making a sale. Those also strike me as defensive choices. Defending against bugs, against bad relationships, against bad design.
All of those are true for some markets, but it's no way to create new products because it breaks core feedback loops. Companies that don't have a way to improve will eventually get replaced by those that do. And as you say, they might then become the next company forced to slow their pace by their customers. But I am hopeful that even enterprise companies will learn to move faster.
All of those are true for some markets, but it's no way to create new products because it breaks core feedback loops. Companies that don't have a way to improve will eventually get replaced by those that do. And as you say, they might then become the next company forced to slow their pace by their customers. But I am hopeful that even enterprise companies will learn to move faster.
It depends what you release. A bug fix, an extra plugin etc. is not going to disrupt the user as much ad a UI overhaul.
Feature flags and great communication with customers and empathy means you can have frequent releases without annoying the customer.
It should be strictly better than slow releases. You can emulate a quarterly release of 1000 changes at once if you want that. Or you could say release fixes and small feature continuously and big features are timed with the customer/training/support functions. They might even be beta/optin at first.
Getting the code out fast always and then providing ways to avoid dumping confusing features on people seems better to me.
Feature flags and great communication with customers and empathy means you can have frequent releases without annoying the customer.
It should be strictly better than slow releases. You can emulate a quarterly release of 1000 changes at once if you want that. Or you could say release fixes and small feature continuously and big features are timed with the customer/training/support functions. They might even be beta/optin at first.
Getting the code out fast always and then providing ways to avoid dumping confusing features on people seems better to me.
Development methodologies sort of work -- they don't work perfectly, but nothing really does. Most teams practice some sort of pseudo-version of methodology #1 while they do the practical work of methodology #2.
That doesn't mean methodology #1 is useless. Agile/scrum really did have an impact on the industry, and the proof of that is how hard it is to find people who still advocate for the kind of waterfall methodology that was once accepted by pretty much everyone.
The annoying thing about development methodologies is meeting people who don't understand that the map is not the territory and insist that a perfect application of a methodology is absolutely necessary. They drive everyone else crazy with buzzwords and process. Most people are fine with a sort-of agile process that takes reality and business value into account.
That doesn't mean methodology #1 is useless. Agile/scrum really did have an impact on the industry, and the proof of that is how hard it is to find people who still advocate for the kind of waterfall methodology that was once accepted by pretty much everyone.
The annoying thing about development methodologies is meeting people who don't understand that the map is not the territory and insist that a perfect application of a methodology is absolutely necessary. They drive everyone else crazy with buzzwords and process. Most people are fine with a sort-of agile process that takes reality and business value into account.
As somebody who was very involved in the Agile movement early on (2000-2008 or so), I don't think Agile deserves the credit here. What I think actually happened was that the rise of the internet made faster release cycles both possible and necessary. Scrum rode that wave, saying that they had the solution. But most Scrum implementations I've seen are not what I'd call conscious, proactive process change. It's just a new set of labels for accelerated versions of the old behaviors (waterfall or code-and-fix or a mix), plus a revenue stream for consultants and a certification scam for everybody else.
I wrote more about that a long time ago, and still stand by it: https://williampietri.com/writing/2011/agiles-second-chasm-a...
I wrote more about that a long time ago, and still stand by it: https://williampietri.com/writing/2011/agiles-second-chasm-a...
I completely agree with this. Yeah, it's not like they don't work at all, it's that they work to some degree.
And, yeah, I think a lot of devs would agree that the traditional waterfall is not as good a process as agile. You could say that it's an antiprocess, whose basic idea is that the old inflexible waterfall with its overly structured teams is inefficient. Yes, small, tight-knit teams working closely together and iterating quickly is much more productive, creative and rewarding way to work.
... although, in my humble opinion, the one thing that agile really needs to stress more (that is key in the waterfall) is requirements. A (couple of) dedicated rounds of requirements where you talk with users (and stakeholders) saves a ton of dev time - agile does have requirements, but at least in my experience, devs seems to gloss over it.
And, yeah, I think a lot of devs would agree that the traditional waterfall is not as good a process as agile. You could say that it's an antiprocess, whose basic idea is that the old inflexible waterfall with its overly structured teams is inefficient. Yes, small, tight-knit teams working closely together and iterating quickly is much more productive, creative and rewarding way to work.
... although, in my humble opinion, the one thing that agile really needs to stress more (that is key in the waterfall) is requirements. A (couple of) dedicated rounds of requirements where you talk with users (and stakeholders) saves a ton of dev time - agile does have requirements, but at least in my experience, devs seems to gloss over it.
I would also add that management often subverts the methodology by using them as a form of metrics. In my experience with Agile/Scrum they started to expect design and implementation in 2 weeks cycles which is unrealistic for large projects. This ultimately ended up in an inability to execute and complete projects that needed long term thinking and planning.
Number 3 seems about right. My Vulcan brain thinks that something like number 1 must the answer, but my lizard brain knows that the food pellets drop when I follow number 3.
Back in the day, our CEO's neighbor mentioned that our site didn't work well on Microsoft's WebTV. WebTV appeared on our list of supported platforms.
Back in the day, our CEO's neighbor mentioned that our site didn't work well on Microsoft's WebTV. WebTV appeared on our list of supported platforms.
On point 3, also you have a plethora of PMs who are insistent they are important and can bend the will of Somebody Important and definitely aren’t just relaying those “drop everything” requests and are actually a proper job of being a PM…
I can't complain too much about Scrum when some people take CMMI seriously
(Of course those are deeply in managerial self-pleasing and probably would make a hello world project cost a million dollars, still...)
(Of course those are deeply in managerial self-pleasing and probably would make a hello world project cost a million dollars, still...)
Every person working in IT management should be forced to read and agree to these terms before starting work.
What works: A lead who plans out the project and works with engineers or engineering teams with different specialties to scope out the required components. Lead puts together a plan that is path dependence aware, engineers / teams work iteratively and communicate status.
Leads often don’t know how to lead, scrum hides this.
Management is supposed to be understanding the organizational needs of completing such projects i.e. making sure the right personnel are on the team, on the right teams, that the right teams exist, and that individuals are capable (technically, as a matter of attitude, incentives, conflicts of interest).
Management often doesn’t know how to manage and scrum hides this.
Product is supposed to be coming up with the projects. It gets more complicated as there are “technical” products where the PMs are maybe the leads of Engineering teams, and other ones, but overall, someone is supposed to be responsible for defining what to do next as a discrete goal.
Product often doesn’t know how to do this and scrum hides this.
The thing everyone gets wrong with agile / scrum is that you just keep hacking away until “something” gets done. Without getting into how “agile isn’t scrum” and really just meaning “the death march of ill-specification and low accountability that often gets described as scrum or agile”, you’re supposed to actually start and stop stuff. You can start, fail, and restart. But you need to complete stuff, then look at what was planned versus what was delivered. You need to make specific people responsible for specific things getting done. If people can’t handle their assignments, they need to be given different assignments or removed.
This all sounds really simple, but at dysfunctional orgs, it gets way off track. Being somewhere where nobody is responsible for anything is practically a right of passage in this industry.
Leads often don’t know how to lead, scrum hides this.
Management is supposed to be understanding the organizational needs of completing such projects i.e. making sure the right personnel are on the team, on the right teams, that the right teams exist, and that individuals are capable (technically, as a matter of attitude, incentives, conflicts of interest).
Management often doesn’t know how to manage and scrum hides this.
Product is supposed to be coming up with the projects. It gets more complicated as there are “technical” products where the PMs are maybe the leads of Engineering teams, and other ones, but overall, someone is supposed to be responsible for defining what to do next as a discrete goal.
Product often doesn’t know how to do this and scrum hides this.
The thing everyone gets wrong with agile / scrum is that you just keep hacking away until “something” gets done. Without getting into how “agile isn’t scrum” and really just meaning “the death march of ill-specification and low accountability that often gets described as scrum or agile”, you’re supposed to actually start and stop stuff. You can start, fail, and restart. But you need to complete stuff, then look at what was planned versus what was delivered. You need to make specific people responsible for specific things getting done. If people can’t handle their assignments, they need to be given different assignments or removed.
This all sounds really simple, but at dysfunctional orgs, it gets way off track. Being somewhere where nobody is responsible for anything is practically a right of passage in this industry.
You perspective is interesting. Do you have an opinion about to help management know how to manage? I'm personally in a constant struggle to improve my management skills but struggle to weed through the sudo-science of management training resources.
Hot take: “management skills” are bullshit. A good manager is empathetic, logical, and organized. Easier said than done of course but that is the only “signal” required — the rest is just noise.
I've been managing for a long time, and where I always seem to land are to ask stakeholders and the engineering team what a successful engineering org looks like to them, and I start from there. The almost universal answer from stakeholders is consistency and some measure of predictability. For Engineers, it's usually consistency and feeling like their making valuable contributions and shipping products.
People tend to gravitate towards Scrum because they know it, but it's usually implemented because a process is deemed to be required, not that specific goals are trying to be met. By starting with the goals, I can at least start from a position of agreement, and develop a Scrum or other process that can provide some measure of success for stakeholders while meeting the needs of the engineers. It's also a forcing function for me to say that if you want X from the Engineering team, we need Y from you.
I'm also very upfront that a hill I'll die on is that velocities and story points are great planning tools and signals around process health, but they're never goals nor are they tools for judgement and reviews.
People tend to gravitate towards Scrum because they know it, but it's usually implemented because a process is deemed to be required, not that specific goals are trying to be met. By starting with the goals, I can at least start from a position of agreement, and develop a Scrum or other process that can provide some measure of success for stakeholders while meeting the needs of the engineers. It's also a forcing function for me to say that if you want X from the Engineering team, we need Y from you.
I'm also very upfront that a hill I'll die on is that velocities and story points are great planning tools and signals around process health, but they're never goals nor are they tools for judgement and reviews.
I think clarity on what “level of leadership” (link, Netflix presentation) is expected is a good thing and also helps people understand that such a hierarchy exists. It gets people thinking about just handling things for you.
Otherwise, I dunno, my best managers had their own way of waxing philosophical about leadership and my role, the product, company, etc to make me more autonomous.
https://www.infoq.com/presentations/netflix-five-level-owner...
Otherwise, I dunno, my best managers had their own way of waxing philosophical about leadership and my role, the product, company, etc to make me more autonomous.
https://www.infoq.com/presentations/netflix-five-level-owner...
The key insight in this post is in the conclusion section:
> My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process.
> My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process.
RPI has a degree in information systems management, I think they call it. A coworker enrolled and worked part time while in the program. Apparently they teach that Conceptual Integrity is the dominant factor in project success or failure. Someone has to be able to fit the entire system in their head and when they go it’s all downhill.
Some processes try to break conceptual integrity. Micro services are one but Scrum as practiced usually tries to stick people into a blind valley where the horizon is months out rather than years. That leads to bad minmaxing behaviors, and/or covert channels being used to keep the wheels on. Scrum theater is especially grating when people who make the sausage have to listen to zealous managers brag about how the process is the source of all of their success. Since they don’t know where the success comes from they don’t see it leave the building to be appreciated somewhere else.
The second time it was my circus, my clowns, someone had divided the backend and front end people into different groups and it was a shitshow. Until I/we discovered that diagrams of user interactions were less than useless for preventing impedance mismatches between the tiers. What you needed were data flow analyses. Particularly for complex data entry workflows. C comes from B, B comes from A. Rework dropped like a rock once I incorporated this into kickoff meetings.
Some processes try to break conceptual integrity. Micro services are one but Scrum as practiced usually tries to stick people into a blind valley where the horizon is months out rather than years. That leads to bad minmaxing behaviors, and/or covert channels being used to keep the wheels on. Scrum theater is especially grating when people who make the sausage have to listen to zealous managers brag about how the process is the source of all of their success. Since they don’t know where the success comes from they don’t see it leave the building to be appreciated somewhere else.
The second time it was my circus, my clowns, someone had divided the backend and front end people into different groups and it was a shitshow. Until I/we discovered that diagrams of user interactions were less than useless for preventing impedance mismatches between the tiers. What you needed were data flow analyses. Particularly for complex data entry workflows. C comes from B, B comes from A. Rework dropped like a rock once I incorporated this into kickoff meetings.
It's not even months. People become incredibly risk-averse, need results, see what they want in 2 weeks and instead of the natural process (gain trust, be left to your own devices more), the reins are kept short and any short term mistake is blown out of proportions.
Worst is, this has nothing to do with short feedback loops and frequent releases. It all has to do with perception and how the method is used.
Worst is, this has nothing to do with short feedback loops and frequent releases. It all has to do with perception and how the method is used.
Any time I feel effective in pure scrum, I also feel like I'm an accountant for the mafia; all the bookkeeping is a fiction to keep the authorities happy, meanwhile something completely different is happening in the back room. There's amortizing refactoring across every feature in a module, and there's deep rationalization of why this refactor can plausibly be tied to this ticket.
It's a mixed bag. One thing refactoring is good for is getting past friction introduced by people who don't like a good idea. Early in my career I got a lot of "that will take too long" for features in the High Cost, High Value quadrant of the feature graph. A couple months of picking away at the accidental complexity and you can come back with a <6 week estimate instead of 4 months, and your proposal gets more consideration. I'm not saying 4 months is a reasonable estimate, I get why that causes concern, but refactoring can be so much more effective when you have long-term goals in mind. When you have a list of 'target of opportunity' features. When you can romance an epic into the code, instead of forcing it in.
I still get that pushback of course, but I'm more used to it and also sometimes don't ask questions I don't want the answer to. It's all subterfuge and puppet mastery. If I wanted to be an accountant or a lobbyist I wouldn't have enrolled in a CS degree at a semi-respectable institution.
It's a mixed bag. One thing refactoring is good for is getting past friction introduced by people who don't like a good idea. Early in my career I got a lot of "that will take too long" for features in the High Cost, High Value quadrant of the feature graph. A couple months of picking away at the accidental complexity and you can come back with a <6 week estimate instead of 4 months, and your proposal gets more consideration. I'm not saying 4 months is a reasonable estimate, I get why that causes concern, but refactoring can be so much more effective when you have long-term goals in mind. When you have a list of 'target of opportunity' features. When you can romance an epic into the code, instead of forcing it in.
I still get that pushback of course, but I'm more used to it and also sometimes don't ask questions I don't want the answer to. It's all subterfuge and puppet mastery. If I wanted to be an accountant or a lobbyist I wouldn't have enrolled in a CS degree at a semi-respectable institution.
I did my best work as in a mafia scrum team.
The settings :
Giant industrial corporation, giant projects with other giant corps as clients.
Process process process. SAFe Scrum.
Somehow I ended up in a team that started to care. Like, we, small individual team, had a agenda and a goal. We saw path to success for this mess of a giant project.
And we started to shadow work our way thought it.
At first myself and another senior guy. As a hobbit.
But it became prevalent for the team as a whole to do “prep work” on top of our tickets.
We self organize, self train.
Why? So we can move faster and actually deliver.
Our normal ticket we’re adjacent work. It’s not like we started 30 repo on the side.
Finally our scrum master caught on that. She went onboard.
We repurposed tickets like nobody’s business. Acceptance criteria was a mere indication, because the QA folks were on board as well.
Not to less us merge crap, QA is QA and you don’t go to prod with a buggy industrial system. That shit is dangerous:
but they knew where we were going and were fine with changing the AC if they see progress, and if the black market scrum master say we’re gonna have a black market ticket to fix it.
We delivered. It fucking worked. My favorite part ? We were the “bad” team. The team without a cool project or a decent backlog. The cleanup crew.
The settings :
Giant industrial corporation, giant projects with other giant corps as clients.
Process process process. SAFe Scrum.
Somehow I ended up in a team that started to care. Like, we, small individual team, had a agenda and a goal. We saw path to success for this mess of a giant project.
And we started to shadow work our way thought it.
At first myself and another senior guy. As a hobbit.
But it became prevalent for the team as a whole to do “prep work” on top of our tickets.
We self organize, self train.
Why? So we can move faster and actually deliver.
Our normal ticket we’re adjacent work. It’s not like we started 30 repo on the side.
Finally our scrum master caught on that. She went onboard.
We repurposed tickets like nobody’s business. Acceptance criteria was a mere indication, because the QA folks were on board as well.
Not to less us merge crap, QA is QA and you don’t go to prod with a buggy industrial system. That shit is dangerous:
but they knew where we were going and were fine with changing the AC if they see progress, and if the black market scrum master say we’re gonna have a black market ticket to fix it.
We delivered. It fucking worked. My favorite part ? We were the “bad” team. The team without a cool project or a decent backlog. The cleanup crew.
We submarined Kanban into a similar project at a large, old, waterfall company. It was such a silent conspiracy that to my recollection we never mentioned Kanban out loud. Limited Work In Progress was as close as we got to uttering the name.
[deleted]
> Apparently they teach that Conceptual Integrity is the dominant factor in project success or failure. Someone has to be able to fit the entire system in their head and when they go it’s all downhill.
How about if everybody can fit (the outline of) the entire system in their head? XP says that everyone needs to understand the cocktail-napkin-level view of the system, and everyone needs to be able to reproduce it when asked. That helps conceptual integrity - everyone knows the vision of the system.
How about if everybody can fit (the outline of) the entire system in their head? XP says that everyone needs to understand the cocktail-napkin-level view of the system, and everyone needs to be able to reproduce it when asked. That helps conceptual integrity - everyone knows the vision of the system.
I'm not averse to that but if you're working some place where less than four people know what the fuck is going on, it's a long process to get to 'all senior developers understand the whole system'.
Personally I don't like answering the same questions over and over. I got into programming so I could 'solve' repetitive work, not so I could get paid more to to it faster. And I've seen to many cases of unapproachable=out of touch so that's not an option for me. The only way to scale being the person to ask hard questions is if you make sure people can self-serve on easy and intermediate ones.
Personally I don't like answering the same questions over and over. I got into programming so I could 'solve' repetitive work, not so I could get paid more to to it faster. And I've seen to many cases of unapproachable=out of touch so that's not an option for me. The only way to scale being the person to ask hard questions is if you make sure people can self-serve on easy and intermediate ones.
There is no mistaking the magic when a large group of programmers have a common vision, of sufficient conceptual integrity to allow most anyone to make most any decisions (source: programming in the host side team at AOL while the traffic was still doubling every few months),
And yet it is I would say very rare to see a good team scale their vision up. AOL was able to onboard new programmers and share the vision, but we never got a different geographic site converted, not really.
One tried things with documentation and two person Webex meetings, and code reviews that focus not on being tidy, but here’s how we understand this problem, these are the reasons to do something, this use case is an example of such and such a concept. (Just a final closing comment, be tidy you won’t be happy otherwise.). It can gradually build up over time, but rarely causes teams to catch fire.
And yet it is I would say very rare to see a good team scale their vision up. AOL was able to onboard new programmers and share the vision, but we never got a different geographic site converted, not really.
One tried things with documentation and two person Webex meetings, and code reviews that focus not on being tidy, but here’s how we understand this problem, these are the reasons to do something, this use case is an example of such and such a concept. (Just a final closing comment, be tidy you won’t be happy otherwise.). It can gradually build up over time, but rarely causes teams to catch fire.
Yup. It also comes from involving devs in the problems they are trying to solve.
Going even further back, Deming called it "constancy of purpose."
Related:
Why don’t software development methodologies work? (2014) - https://news.ycombinator.com/item?id=15885171 - Dec 2017 (184 comments)
Why don’t software development methodologies work? (2014) - https://news.ycombinator.com/item?id=15476638 - Oct 2017 (1 comment)
Why don’t software development methodologies work? - https://news.ycombinator.com/item?id=7211341 - Feb 2014 (197 comments)
Why don’t software development methodologies work? (2014) - https://news.ycombinator.com/item?id=15885171 - Dec 2017 (184 comments)
Why don’t software development methodologies work? (2014) - https://news.ycombinator.com/item?id=15476638 - Oct 2017 (1 comment)
Why don’t software development methodologies work? - https://news.ycombinator.com/item?id=7211341 - Feb 2014 (197 comments)
It’s funny how it gained more traction later as a trend!
I disagree with the fundamental conceit of the article:
> But in terms of the only measurement that really matters—satisfying requirements on time and within budget—I haven’t seen any methodology deliver consistent results.
What matters is delivering value to the organization, and doing so in a cost-effective, sustainable way. Making plans and then meeting them is incidental to this, and quite often opposed to it.
> But in terms of the only measurement that really matters—satisfying requirements on time and within budget—I haven’t seen any methodology deliver consistent results.
What matters is delivering value to the organization, and doing so in a cost-effective, sustainable way. Making plans and then meeting them is incidental to this, and quite often opposed to it.
Absolutely. It's entirely possible to develop a bad budget or schedule. You don't find a lot of material about that.
Hey, I just invented eXtreme Budgeting. If you buy my book, attend my conference talks, and hire my firm the coach your organization through implementing it, you'll be among the A-tier companies that have decided to take budgeting seriously by practicing XB!
Who wants to go in on it?
"Double-entry bookkeeping is just pair programming for accounting" -me
Hey, I just invented eXtreme Budgeting. If you buy my book, attend my conference talks, and hire my firm the coach your organization through implementing it, you'll be among the A-tier companies that have decided to take budgeting seriously by practicing XB!
Who wants to go in on it?
"Double-entry bookkeeping is just pair programming for accounting" -me
Sam Bankman-Fried beat you to it.
> What matters is delivering value to the organization
No, what _should_ matter is delivering value to the organization. But that's impossible to measure, so what actually matters is what they can measure, which is "on time and within budget".
No, what _should_ matter is delivering value to the organization. But that's impossible to measure, so what actually matters is what they can measure, which is "on time and within budget".
Well, I agree but people make investment decisions based on rough estimates of expenses and when the expenses are wildly different from the estimates, often projects are finished that in retrospect would not have been started. Classic example, this system is 99.8% reliable. Polish the last bit or re-architect it? If the rearchitecture is six months with five people, ok do that. When it takes well over a year, maybe more polishing would have been good. Especially when the year was half polishing the new system.
This was one of my biggest issues with a team I used to work on; they prided themselves on "doing what we said we would do" but just could not grasp how rigid and impossible to work with that becomes when an adjustment is needed.
What you said you would do is based on old information!
What you said you would do is based on old information!
The concrete problem here depends on when and how often adjustments are needed.
If adjustments are needed every week, then the root problem lies deeper.
If adjustments are needed every week, then the root problem lies deeper.
The trick is to work on the things that won't need adjustments first, and delay the rest until information is more stable.
The root problem is usually that customers are fickle and you need to constantly adapt to what they're telling you.
this is something you have to manage. your customers and your salespeople by proxy. yes, absolutely you should respond to the market. no, you should not drop everything to let your customer bikeshed.
My observations are than "agility" in most corporations mean "agile" approach to requirements, hard fixed approach to deadlines and environment or sdlc. Once I got blamed from system admins that I am late and they have extra work because client asked for change few hours before the release deadline. I implemented this but I got blamed for being late. Also in SCRUM the zealous approach to the holy 2 weeks, it cannot last 13 days, nor 15 days. It's super important to last exactly 14 days. In holy ticketing environment where you have to issue a ticket to wipe glasses. In my opinion the best and simplest methodology is an incremental waterfall with releases every 3 months ( more or less ). 3 month long "milestones" because every company does quarter reports. Additionally for status reporting Kanban boards. No damn red tape driven "agile" Scrums, safs and so on.
I think the article is very relevant and I agree with the article's observation that the methodologies are perhaps less important than human relationships.
However, I think the failure of methodologies can be ascribed to treating SW development as a sort of reproducible, factory process. Two major misconceptions that come out of that:
1. Assuming that the progress on SW development is linear, and the sum of software is exactly the sum of its parts. In reality, SW development process is more like an S-curve, where you plan a lot in the beginning (so coding comes slower), then you speed up because most of the issues are clear and the research is done, and then you slow down back again as you're trying to fine-tune the whole result. This inherent non-linearity is really difficult for the "bean counters" to deal with.
2. Assuming that the people should operate as workers on assembly line, that is, the architects designs, programmer codes, QA tests, support does fixes.. In reality, it's more like a workshop operation - ideally people live with each feature for the whole lifecycle.
What always amazes me, though. Big pop art productions like computer games or movies.. they often run on a schedule, and yet are as creative or diverse as SW development. So it seems like there perhaps should be a methodology.
However, I think the failure of methodologies can be ascribed to treating SW development as a sort of reproducible, factory process. Two major misconceptions that come out of that:
1. Assuming that the progress on SW development is linear, and the sum of software is exactly the sum of its parts. In reality, SW development process is more like an S-curve, where you plan a lot in the beginning (so coding comes slower), then you speed up because most of the issues are clear and the research is done, and then you slow down back again as you're trying to fine-tune the whole result. This inherent non-linearity is really difficult for the "bean counters" to deal with.
2. Assuming that the people should operate as workers on assembly line, that is, the architects designs, programmer codes, QA tests, support does fixes.. In reality, it's more like a workshop operation - ideally people live with each feature for the whole lifecycle.
What always amazes me, though. Big pop art productions like computer games or movies.. they often run on a schedule, and yet are as creative or diverse as SW development. So it seems like there perhaps should be a methodology.
I think the example of video games and movies is instructive - there's always a ton of "cut content". In software, we can always change the requirements to meet a deadline :)
Because the premise of this article is totally and utterly wrong. It says:
> Whether a methodology works or not depends on the criteria: team productivity, happiness, retention, conformity, predictability, accountability, communication, lines per day, man-months, code quality, artifacts produced, etc. Every methodology works if you measure the right thing. But in terms of the only measurement that really matters—satisfying requirements on time and within budget—I haven’t seen any methodology deliver consistent results.
Asking a methodology to always meet requirements on time and within budget is asking for human perfection. You might as well expect it to deliver world peace and end hunger as we know it as well. So of course if you set a ludicrously unattainable goal, development methodologies all fail. In every project, unforeseen obstacles will always come up, which usually means some combination of scope-cutting or delaying or (occasionally) spending more.
But when teams are having major problems in delivering working code at all or at a reasonable pace, that's where different methodologies can absolutely improve the situation, depending on what's going wrong and what the desired product is. So obviously they do work in terms of adding value, when applied appropriately.
Let's not throw the baby out with the bathwater here.
> Whether a methodology works or not depends on the criteria: team productivity, happiness, retention, conformity, predictability, accountability, communication, lines per day, man-months, code quality, artifacts produced, etc. Every methodology works if you measure the right thing. But in terms of the only measurement that really matters—satisfying requirements on time and within budget—I haven’t seen any methodology deliver consistent results.
Asking a methodology to always meet requirements on time and within budget is asking for human perfection. You might as well expect it to deliver world peace and end hunger as we know it as well. So of course if you set a ludicrously unattainable goal, development methodologies all fail. In every project, unforeseen obstacles will always come up, which usually means some combination of scope-cutting or delaying or (occasionally) spending more.
But when teams are having major problems in delivering working code at all or at a reasonable pace, that's where different methodologies can absolutely improve the situation, depending on what's going wrong and what the desired product is. So obviously they do work in terms of adding value, when applied appropriately.
Let's not throw the baby out with the bathwater here.
> Asking a methodology to always meet requirements on time and within budget
I'm not quite sure what you're getting at here, because that's absolutely, positively 100% what the people who are recommending methodologies insist they're for and absolutely, positively 100% what the people who adopt them want them for. The ENTIRETY of software developer management is focused - beginning and ending - on meeting requirements on time and within budget. That's the ONLY thing they care about and their ONLY purpose for existing.
I'm not quite sure what you're getting at here, because that's absolutely, positively 100% what the people who are recommending methodologies insist they're for and absolutely, positively 100% what the people who adopt them want them for. The ENTIRETY of software developer management is focused - beginning and ending - on meeting requirements on time and within budget. That's the ONLY thing they care about and their ONLY purpose for existing.
I mean I don't know what to tell you, but you're just completely wrong.
Sure, that's what management would wish in an ideal world. But obviously that's not what these methodologies are even marketed as -- e.g. the entire purpose of agile/scrum is to break into sprints that have deliverables as goals but not as guarantees, in order to de-risk larger failures by exposing smaller failures earlier, to be able to then adjust requirements/timeline as you go. Heck, it's so important that they insist on estimating tasks in terms of abstract points instead of units of time.
Methodologies attempt to give more accurate, less wishful-thinking, estimates of timelines/resources. And they're often quite successful at that with things like planning poker etc. But all they do is improve, they don't give guarantees.
Sure, that's what management would wish in an ideal world. But obviously that's not what these methodologies are even marketed as -- e.g. the entire purpose of agile/scrum is to break into sprints that have deliverables as goals but not as guarantees, in order to de-risk larger failures by exposing smaller failures earlier, to be able to then adjust requirements/timeline as you go. Heck, it's so important that they insist on estimating tasks in terms of abstract points instead of units of time.
Methodologies attempt to give more accurate, less wishful-thinking, estimates of timelines/resources. And they're often quite successful at that with things like planning poker etc. But all they do is improve, they don't give guarantees.
You're totally right, but the main issue is that people don't even learn what the goal of agile / extreme programming is (it's a methology for engineers for giving data to managers to be able to take early decisions / manage the project while it's cheaper).
It has taken over by managers to just be used for pressuring software engineers, that's why the name had to change so much.
It has taken over by managers to just be used for pressuring software engineers, that's why the name had to change so much.
Yeah, no. I wrote one of the more popular books about Agile development (The Art of Agile Development) and it says right in the first chapter that "meeting requirements on time and within budget" is not the goal.
"Agile teams define success as delivering value, not conforming to a plan. In fact, truly Agile teams look for opportunities to increase value by changing their plans." (p.7)
So there's at least one person recommending methodologies who absolutely, positively, 100% does not agree with you.
The whole chapter is free online if you want to get out of your bubble: https://www.jamesshore.com/v2/books/aoad2/what_is_agile
"Agile teams define success as delivering value, not conforming to a plan. In fact, truly Agile teams look for opportunities to increase value by changing their plans." (p.7)
So there's at least one person recommending methodologies who absolutely, positively, 100% does not agree with you.
The whole chapter is free online if you want to get out of your bubble: https://www.jamesshore.com/v2/books/aoad2/what_is_agile
In my experience working with a well-known consultancy that uses strict XP, agile, TDD, the whole 9 yards - this isn’t the case at all.
They talk about a triangle of (scope, quality, cost) where you can only pick 2. As a business you can choose what trade off you want to make, but no one’s promising that you can have a rocket ship by next week with 2 engineers if you just organize your tickets correctly.
They talk about a triangle of (scope, quality, cost) where you can only pick 2. As a business you can choose what trade off you want to make, but no one’s promising that you can have a rocket ship by next week with 2 engineers if you just organize your tickets correctly.
Methodologies should help projects meet requirements on time and within budget, but expecting 100% success regardless of the project, experience of the team complexity of estimate and what not is completely unrealistic.
Also, even the concepts of "on time" and "within budget" have more or less meaning depending on your methodology and where your company is in its lifecycle.
I tend to think of a working methodology as one that produces software that meets the customer's need in a way they are willing to pay for that is sufficient to fund the organization that builds and operates the product.
But even that definition can be poked apart because it only accounts for self-sustaining companies, and many software startups do not have an intent to be that.
I tend to think of a working methodology as one that produces software that meets the customer's need in a way they are willing to pay for that is sufficient to fund the organization that builds and operates the product.
But even that definition can be poked apart because it only accounts for self-sustaining companies, and many software startups do not have an intent to be that.
Hes asking for "consistent results", not perfect results.
I'll give you another methodology I call it "TRACK-RECORD". Give the resources to the guys who gets the project done and dont bug them with what ever management bullshit is the current fad and dont keep changing the specification because you diddnt do your homework before starting the coding.
Because they don't apply universally and managers want them to.
Take scrum vs. for example.
The focus on small changes, repetitive action, reflective insights, and short feedback cycles is absolutely awesome for software maintenance. Use cases like the python 2 migration, Database upgrades, human language translations, or incremental architectural rework are perfectly suited for scrum.
You can develop features as well, as long as they are fairly isolated. If you want to add a device driver to the Linux kernel, scrum would probably work very well.
But scrum totally breaks down for features that are not independent of each other. Using scrum can easily lead to two features deployed to production that logically cannot coexist under certain circumstances. And no, testing doesn't prevent that. Another problem are features that are just very large by nature. They tend to break the repetitive cycle, because they simply don't repeat.
Finally, bugs are often problematic if they cannot be planned into a future sprint because they are urgent. Scrum simply doesn't assume that anything could happen in the middle of the sprint. It's an alien concept.
That doesn't make scrum a bad methodology per se, it's just important to consider the use cases and potential exceptions. And to chose another methodology once the exceptions become the norm.
Take scrum vs. for example.
The focus on small changes, repetitive action, reflective insights, and short feedback cycles is absolutely awesome for software maintenance. Use cases like the python 2 migration, Database upgrades, human language translations, or incremental architectural rework are perfectly suited for scrum.
You can develop features as well, as long as they are fairly isolated. If you want to add a device driver to the Linux kernel, scrum would probably work very well.
But scrum totally breaks down for features that are not independent of each other. Using scrum can easily lead to two features deployed to production that logically cannot coexist under certain circumstances. And no, testing doesn't prevent that. Another problem are features that are just very large by nature. They tend to break the repetitive cycle, because they simply don't repeat.
Finally, bugs are often problematic if they cannot be planned into a future sprint because they are urgent. Scrum simply doesn't assume that anything could happen in the middle of the sprint. It's an alien concept.
That doesn't make scrum a bad methodology per se, it's just important to consider the use cases and potential exceptions. And to chose another methodology once the exceptions become the norm.
>Using scrum can easily lead to two features deployed to production that logically cannot coexist under certain circumstances. And no, testing doesn't prevent that. Another problem are features that are just very large by nature. They tend to break the repetitive cycle, because they simply don't repeat.
Breaking down features is a skill that not many learn because, unless it's trivial, they believe it to be impossible to begin with.
Good god is it valuable though.
I'm with you on the rest of scrum. It's an awful methodology.
Breaking down features is a skill that not many learn because, unless it's trivial, they believe it to be impossible to begin with.
Good god is it valuable though.
I'm with you on the rest of scrum. It's an awful methodology.
Breaking down features doesn't help if two features are simply incompatible with each other.
I experienced this once, when feature A that was about 3 years old prevented feature B that was a out 1 year old from functioning correctly. The error lead to accumulation of garbage in a DB and was spotted when said DB ran out of disk space. It was incredible difficult to convey the message to management that the bug was at a meta level because both features worked as specified. They really struggled with the concept. It simply didn't fit their view on reality that features aren't completely independent.
I experienced this once, when feature A that was about 3 years old prevented feature B that was a out 1 year old from functioning correctly. The error lead to accumulation of garbage in a DB and was spotted when said DB ran out of disk space. It was incredible difficult to convey the message to management that the bug was at a meta level because both features worked as specified. They really struggled with the concept. It simply didn't fit their view on reality that features aren't completely independent.
No, definitely not. That should be self evident during a planning session though should it not?
In my experience, the MBA vs Engineer mindset plays a part in this. The manager class says we need X number of people and as long as we use the right methodolgy then good things will happen.
Meanwhile the engineer mindset says to give us good engineers, not numbers and good things will happen under any methodolgy.
Meanwhile the engineer mindset says to give us good engineers, not numbers and good things will happen under any methodolgy.
I think you got this right, but the other thing is also that either of those approaches can work in the small, but they just don't scale. For the engineering side, at some point you need "architects" or people whose sole job is to maintain consistency of the whole system, and one way to break down work into smaller components is to define interfaces between components. This is crucial, throwing more people at a larger problem just doesn't work (in my experience) if you don't have this (and it can be entirely informal... engineering orgs tend to route around beancounters!). So the quality of people, not number or methodology is the main driver of success.
> I now routinely get involved with projects developed by one or two people burdened with so much process and “best practices” that almost nothing of real value is produced.
The problem is that nobody really knows what practices are best, anyway. It's mostly just following the herd and gold-plating.
A story I typically trot out at this point is some code that was written in Fortran. I passed a meeting room one day, where some consulting dude was talking about "yeah, we could just put that in xml."
The thing about Fortran is that it can read arrays as a one-line statement. It's native to the language. You put data in XML, then you need to link in libraries and parse the whole shebang.
Programs need to be revised periodically. That means a bunch of guys who know what they're doing (not necessarily programmers) have to sit down and go through the tedious business of figuring out a new spec and how things need to change. I don't there's any shortcut to this. XML won't magic the problem away.
The problem is that nobody really knows what practices are best, anyway. It's mostly just following the herd and gold-plating.
A story I typically trot out at this point is some code that was written in Fortran. I passed a meeting room one day, where some consulting dude was talking about "yeah, we could just put that in xml."
The thing about Fortran is that it can read arrays as a one-line statement. It's native to the language. You put data in XML, then you need to link in libraries and parse the whole shebang.
Programs need to be revised periodically. That means a bunch of guys who know what they're doing (not necessarily programmers) have to sit down and go through the tedious business of figuring out a new spec and how things need to change. I don't there's any shortcut to this. XML won't magic the problem away.
The only thing that works is:
- people who care
- people who make a good faith effort every day
- people who consider the big picture and don't relegate themselves into a comfortable little box
- people who care
- people who make a good faith effort every day
- people who consider the big picture and don't relegate themselves into a comfortable little box
If the team doesn't agree on what is being built, what tools should be used to build it and how the software/hardware will be used, all the methodology in the world can't fix it. Methodology turns into a weird quasi-religious ceremony where everyone works together to find solutions that everyone knows aren't going to do anything but solve political problems.
When everyone agrees on what is being built, tools and how the product will be used, methodology is nothing but a framework to simplify the non-coding part of building software. All of the methodologies will work b. So if your methodology isn't working... it's a deeper problem.
When everyone agrees on what is being built, tools and how the product will be used, methodology is nothing but a framework to simplify the non-coding part of building software. All of the methodologies will work b. So if your methodology isn't working... it's a deeper problem.
Agree with the gist of the article. My most productive work was in a team of three where people had different strengths. The same team got blown up to 10 people and we were doing less - albeit more ambitious work, but a lot of time was wasted with people with same strengths stepping on each other toes. Where we had one person with the need to feel important and do "cool" work, we had three with different views. So methodology was far off from the key thing.
This topic always do make me remember this old Dijkstra quote:
Software engineering has accepted as its charter "How to program if you cannot"
Software engineering has accepted as its charter "How to program if you cannot"
If you learn Blacksmithing, you will learn a methodology to create fine steel. Something like:
Put steel ingot into furnace. Wait until hot. Remove to anvil and hit 50 times. Put back in furnace until hot. Remove to anvil and hit 50 more times. Repeat until steel forms a blade. Then quench.
This methodology is fine for producing a basic blade blank. But clearly it's not enough to simply give someone a method to make a blade. They have to actually do the job well, which they can only learn by doing. The method describes the process, but the method is not what produces the blade. If the blade turns out crap, the blacksmith is at fault, not the method.
Put steel ingot into furnace. Wait until hot. Remove to anvil and hit 50 times. Put back in furnace until hot. Remove to anvil and hit 50 more times. Repeat until steel forms a blade. Then quench.
This methodology is fine for producing a basic blade blank. But clearly it's not enough to simply give someone a method to make a blade. They have to actually do the job well, which they can only learn by doing. The method describes the process, but the method is not what produces the blade. If the blade turns out crap, the blacksmith is at fault, not the method.
I've been writing software for 30+ years and I think the reason methodologies don't work is that they are simple. Software is an attempt to implement something that will be used by people, interact with data, help make decisions, and much more and the real world is extremely messy. People want software to work one way on weekdays and another way on weekends, and differently if it is day or night, across multiple timezones, and in multiple political locations. They want it to know their workflow. They want it know things people know, like the weather or things in the news or specialized knowledge domains. So I think the main problem with methodologies is they do not address the fact that people use software, and all current computers and software are very poor at fitting into human life, desires, and expectations. AI is starting to change that a little, but there is much more to do before computers fulfill their promise. Methodologies may help along the way, but new inventions are probably a greater requirement. Methodologies are how developers interact with software and each other and management, and they won't solve the problem of how software interacts with people and the world. It's the elephant in the room.
Because the ones that work actually require management to manage the least. That’s why. It’s not meant for management it’s meant for teams to self manage (core tenant of XP and Agile is self organizing teams).
My theory goes that since the general management / MBA mindset didn’t evolve to do higher level things with the time this would free up for management, so they kept turning the screws until management as a job was also a requirement for things to work and then it all starts to deviate from the core tenants until it’s just Agile In Name Only or what have you
My theory goes that since the general management / MBA mindset didn’t evolve to do higher level things with the time this would free up for management, so they kept turning the screws until management as a job was also a requirement for things to work and then it all starts to deviate from the core tenants until it’s just Agile In Name Only or what have you
IMO, methodologies are mostly just theatre to cater to stakeholders and their preferences and fears, and are otherwise BS from a development perspective. And in my experience, regardless of what methodology you use, what happens in practice (in the grand scheme of things) largely ends up being the same anyhow. Rather, the speed and success of a project seems to have nothing to do with the methodology, and everything to do with the particular project, people, constraints, and requirements.
[deleted]
I get a huge amount of amusement from the last comment there talking about waterfall being a cruel joke. Especially combined with the view of "Surprisingly, left to themselves programmers don’t revert to cowboy coding—they adopt or create methodologies stricter and more filled with ritual than anything I experienced in 1980." I can't but think of the waterfall process that my team is trying to build right now.
[deleted]
Waterfall is great for projects that have predictable tasks with significant internal dependencies. Software is less predictable, and, with modularity and unit tests, has fewer hard dependencies that prevent other tasks from starting. A kanban board with simple task descriptions is far less overhead than recalculating a critical path method analysis for every change in a project (without much to gain from doing so).
Agile OGs will tell you Scrum is too-often a way of bureaucratizing Agile and making is safe (SAFe?) for managers who demand predictability. If you don't let a small-a agile approach emerge in a way that is appropriate to your project, in your organizational setting, you just end up with a different flavor of bureaucracy.
When planning and budgeting there is a lot to be said for traditional project management methods. They are more predictive than a spreadsheet full of task estimates. But if your team doesn't know why running a project off a Gantt chart fails so often, they won't know which parts of agility are most important to their project.
Agile OGs will tell you Scrum is too-often a way of bureaucratizing Agile and making is safe (SAFe?) for managers who demand predictability. If you don't let a small-a agile approach emerge in a way that is appropriate to your project, in your organizational setting, you just end up with a different flavor of bureaucracy.
When planning and budgeting there is a lot to be said for traditional project management methods. They are more predictive than a spreadsheet full of task estimates. But if your team doesn't know why running a project off a Gantt chart fails so often, they won't know which parts of agility are most important to their project.
I think of small-a agile as a tool chest you rifle through to solve a problem you're encountering, but only once you've encountered it.
You just have to be good at knowing what the problem patterns look like is the only trick to this, and not let something get out of hand when there's a ready-made tool available to fix the issue.
You just have to be good at knowing what the problem patterns look like is the only trick to this, and not let something get out of hand when there's a ready-made tool available to fix the issue.
If you want big wins, then what you are doing is going to have variance. All these solutions are new, and the data to make it predictable is not sufficient to predict, u less you just slow everything down to a pedestrian rate, succeed at predicting that, and then get replaced by some order of magnitude better competitor.
> the data to make it predictable is not sufficient to predict
What's particularly ironic about the methodology obsession is that if a perfect methodology came along that could reduce software development into cookie-cutter assembly-line work then, while programmers would be reduced to minimum wage janitors, the managers that insist that WE'RE the problem because we can't do complex things in the blink of an eye would be reduced to spreadsheets.
What's particularly ironic about the methodology obsession is that if a perfect methodology came along that could reduce software development into cookie-cutter assembly-line work then, while programmers would be reduced to minimum wage janitors, the managers that insist that WE'RE the problem because we can't do complex things in the blink of an eye would be reduced to spreadsheets.
Every project management tool and methodology was conceived and matured by specific individuals and teams in their specific contexts, relationships, and business environment.
Many companies and teams share similar structures and characteristics, but every single one has differences (even at the same company). Just because something worked for some company and team (even ones which are similar to yours) does not mean it will work for you.
There have been so many times where a group I've been involved with has rushed headlong into a specific methodology or tool without having a decent grasp on the team dynamics and goals, and then spent precious hours configuring Jira or arguing about how many hours equals a scrum point. Lord help all of you who get that one person who fancies themselves an expert on a specific methodology or tool.
What you need are people who are experts at understanding the business and the dynamics of team they're throwing at it.
Many companies and teams share similar structures and characteristics, but every single one has differences (even at the same company). Just because something worked for some company and team (even ones which are similar to yours) does not mean it will work for you.
There have been so many times where a group I've been involved with has rushed headlong into a specific methodology or tool without having a decent grasp on the team dynamics and goals, and then spent precious hours configuring Jira or arguing about how many hours equals a scrum point. Lord help all of you who get that one person who fancies themselves an expert on a specific methodology or tool.
What you need are people who are experts at understanding the business and the dynamics of team they're throwing at it.
They don't work because they're pseudoscience. Just because a methodology appears to work for one or even multiple organizations doesn't mean it's going to work in every case.
No one actually knows that FrAgile, SCUM, or TeeDeeDee are universally better than just having a bunch of programmers self-organize. There's no well controlled studies that show anything other than a weak association between hip methodologies and measures like productivity or profit, and no one has demonstrated actual cause and effect. That probably won't happen because these are purely human systems, and good luck controlling for that.
It's fine to consider methodologies, but there's no reason to believe that the people who invented or tout said methodologies should be blindly trusted. They discovered something that they believe worked for them, and that's it. They're not smarter than you. Only use aspects of methodologies that you would use or that you have seen work, and don't do anything that seems stupid or that you would dread.
No one actually knows that FrAgile, SCUM, or TeeDeeDee are universally better than just having a bunch of programmers self-organize. There's no well controlled studies that show anything other than a weak association between hip methodologies and measures like productivity or profit, and no one has demonstrated actual cause and effect. That probably won't happen because these are purely human systems, and good luck controlling for that.
It's fine to consider methodologies, but there's no reason to believe that the people who invented or tout said methodologies should be blindly trusted. They discovered something that they believe worked for them, and that's it. They're not smarter than you. Only use aspects of methodologies that you would use or that you have seen work, and don't do anything that seems stupid or that you would dread.
That's right. Plenty of great software has been developed by the "lock a smart, creative, determined nerd who's _obsessed_ with his/her product in a garage for a month" methodology.
Folks who have bought into the vision of the project and are motivated to "do it right, make it good" have a much higher chance of a successful product than a team who are attending the religious ceremonies and cargo-culting. These methodologies are like painted-lines and highway-signs; they can be great guidelines, but ultimately the driver has to want to avoid getting into an accident and aware enough to realize blindly following the lines/signs won't achieve that on its own.
Edit: *I use "nerd" here as a term of affection, not derogatorily. I proudly call myself a nerd. :)
Folks who have bought into the vision of the project and are motivated to "do it right, make it good" have a much higher chance of a successful product than a team who are attending the religious ceremonies and cargo-culting. These methodologies are like painted-lines and highway-signs; they can be great guidelines, but ultimately the driver has to want to avoid getting into an accident and aware enough to realize blindly following the lines/signs won't achieve that on its own.
Edit: *I use "nerd" here as a term of affection, not derogatorily. I proudly call myself a nerd. :)
Plenty of software that doesn't actually solve the goal and ends up being unmaintainable also comes out of locking a bunch of smart people in a room.
You make it too complicated, no one can modify it without tons of domain knowledge, you make it too abstract and flexible and the abstraction leaks and the flexibility means a ton of extra time spent.
You can really only lock devs in a room if you have very very clear product expectations and a longer term vision that allows people to add flexibility where it's needed for future projects. This simply won't happen with most companies because that's HARD.
You make it too complicated, no one can modify it without tons of domain knowledge, you make it too abstract and flexible and the abstraction leaks and the flexibility means a ton of extra time spent.
You can really only lock devs in a room if you have very very clear product expectations and a longer term vision that allows people to add flexibility where it's needed for future projects. This simply won't happen with most companies because that's HARD.
If your development methodology requires smart, creative, determined geniuses who are obsessed with your product... you will not be able to scale your organization beyond the founding team.
I gotta gatekeep this. When did nerd and geek switch places? Since the 90s, geeks and nerds are two totally different things.
Geek: a person who is knowledgeable about and obsessively interested in a particular subject, especially one that is technical or of specialist or niche interest. "a computer geek"
I'm a proud geek, but after bullying as a kid calling me a nerd is fighting words. A geek nowadays socially ranks above the people that tried to stand above others by calling them nerds, turning labels into strength.
Geek: a person who is knowledgeable about and obsessively interested in a particular subject, especially one that is technical or of specialist or niche interest. "a computer geek"
I'm a proud geek, but after bullying as a kid calling me a nerd is fighting words. A geek nowadays socially ranks above the people that tried to stand above others by calling them nerds, turning labels into strength.
Looks like maybe you got some downvotes - but not from me. Geek & Nerd can be sensitive labels for the likes of folk who hang out here on HN. I wasn't trying to start a flame-war. But I'm happy to discuss it further. Speaking for myself (and myself only), I'm proud of both labels and more-or-less treat them as interchangeable in regards to usage by the general public. Though, I have my-own thoughts on the differences. I take neither as an insult or fighting-word unless, of course, it's obviously being hurled as one, in which case it's not the word, per-se, it's the antagonist as a whole...
I was always told that if you can define the difference you're probably both.
When I hear "geek" all I think of now is Geek Squad, i.e. IT.
Seems as though this is rephrasing the old adage from small-a-agile "Individuals and interactions over processes and tools". Until we normalize asking "who is problem?" rather than "what's wrong with our process?" we're doomed to miss the mark. Excising counterproductive individuals will make any process work well. Discussing methodologies in isolation from individuals is a waste of time.
Interesting, but I'm not sure I agree. Your approach could easily degenerate into hunting for the scapegoat-for-this-reporting-cycle.
But I will say that agile (real agile, not agile-in-name-only) demands quite a bit of discipline and maturity from your people. If you don't have the people for it, it won't work.
But I will say that agile (real agile, not agile-in-name-only) demands quite a bit of discipline and maturity from your people. If you don't have the people for it, it won't work.
I think the costs of avoiding individual-oriented conversations are higher. Asking "which process is the problem" is rarely the issue. I can think of two sane guardrails that are usually applied for large-scale collaboration:
1) your team's code must have a clear, sane, documented interface/API
2) all teams should have a homogenous intake process for requests for change
Everything else becomes a matter of either priority or performance. These areas are where changes have real impact, so it's better to focus the conversation there.
> agile demands quite a bit of discipline
I'd say small-a-agile requires more discipline from managers rather than staff/line employees. Namely, discipline to refrain from imposing significant process overhead on their teams so they have a better feeling of control and predictability. Manager-driven, observability-oriented process changes seldom give managers more actual control. Instead, managers should embrace the uncertainty that comes with software development, demand only to see real progress on working code in short intervals (no milestones, delivery dates, etc.), and set ambitious goals for their teams only in these intervals.
1) your team's code must have a clear, sane, documented interface/API
2) all teams should have a homogenous intake process for requests for change
Everything else becomes a matter of either priority or performance. These areas are where changes have real impact, so it's better to focus the conversation there.
> agile demands quite a bit of discipline
I'd say small-a-agile requires more discipline from managers rather than staff/line employees. Namely, discipline to refrain from imposing significant process overhead on their teams so they have a better feeling of control and predictability. Manager-driven, observability-oriented process changes seldom give managers more actual control. Instead, managers should embrace the uncertainty that comes with software development, demand only to see real progress on working code in short intervals (no milestones, delivery dates, etc.), and set ambitious goals for their teams only in these intervals.
Any methodology that requires discipline to work is a bad methodology. Trying hard ALWAYS works. That is how work got done before agile existed.
The goal is to find a methodology that brings ease. So you can stop putting effort into the organization and meta work and instead put more effort into the work that actually brings value.
The goal is to find a methodology that brings ease. So you can stop putting effort into the organization and meta work and instead put more effort into the work that actually brings value.
> No one actually knows that FrAgile ... are universally better than just having a bunch of programmers self-organize.
Huh? The entire Agile Manifesto is about how programmers should just self-organize as they see fit and highlights some key areas that developers need to be consider in the absence of a manager who would traditionally coordinate things, such as "talk to the business people".
Huh? The entire Agile Manifesto is about how programmers should just self-organize as they see fit and highlights some key areas that developers need to be consider in the absence of a manager who would traditionally coordinate things, such as "talk to the business people".
An entertainment for a rainy afternoon: track down the signatories of the Agile Manifesto and count how many of them were most recently selling tools, processes, and/or consulting for agile software development methodologies.
In fairness, the signatories and even the Agile Manifesto itself admits that it takes a special kind of person to thrive in an environment free of management. It is abundantly clear that you are making a mistake if you venture into Agile if your team is not comprised of those special people. It makes sense that something else will be needed for 90%+ of the remaining organizations happy to have been able to hire anyone for the job. And, well, make hay when the sun is shining, as they say.
The problem is that “Agile” can mean:
* Applying the principles of the Agile Manifesto, or
* Top-down semi-ritualistic application of a canned methodology, usually some variant of either SAFe or Scrum (but rarely, in the latter case, much like the version in The Scrum Guide, but instead something that played telephone through many layers of consultants, distant managers, and the direct manager of the team, is poorly documented, and changes arbitrarily via management fiat based on outside influences without team input.)
* Applying the principles of the Agile Manifesto, or
* Top-down semi-ritualistic application of a canned methodology, usually some variant of either SAFe or Scrum (but rarely, in the latter case, much like the version in The Scrum Guide, but instead something that played telephone through many layers of consultants, distant managers, and the direct manager of the team, is poorly documented, and changes arbitrarily via management fiat based on outside influences without team input.)
I would go as far as to say that management methodologies in general are pseudoscience. Nobody knows how to do it, but some powerful people get paid a lot of money to pretend that they do.
"better than just having a bunch of programmers self-organize"
The problem is right there, most people are not organized.
To do coding for sure, to scope things, evaluate, prioritize etc ... not so sure.
The problem is right there, most people are not organized.
To do coding for sure, to scope things, evaluate, prioritize etc ... not so sure.
Inevitably in any group someone will emerge as the central organizer. I think the idea is that it should allow to happen naturally.
If truly no one is able to get a team organized I’d say treat it as an exception rather than a rule and figure out what is hold the team back from being more organized
If truly no one is able to get a team organized I’d say treat it as an exception rather than a rule and figure out what is hold the team back from being more organized
Sure, someone will emerge. I've seen that scenario happen over and over. Will the result be good? No, not in a single case i observed because managing a software product is a distinct art which too many software developers believe goes naturally hand-in-hand with their coding skills.
Note I mean organize, not manage a product.
Team organization isn't the same thing as managing a product. Self organization is about teams having autonomy to organize and plan units of work and drive the teams forward. This isn't some magical vacuum where the business has no input on what those things are, and you very likely should have some distinct product management that engineers aren't in charge of.
Team organization isn't the same thing as managing a product. Self organization is about teams having autonomy to organize and plan units of work and drive the teams forward. This isn't some magical vacuum where the business has no input on what those things are, and you very likely should have some distinct product management that engineers aren't in charge of.
> Just because a methodology appears to work for one or even multiple organizations doesn't mean it's going to work in every case
the only justification for a thing is if it works. If they regularly do, as you just acknowledged they do multiple times, they're of value.
> and no one has demonstrated actual cause and effect
If repeated success S correlates with repeated use of methodology M, that's a damn strong sign of causation, and if it isn't, I'd still use it.
Actually your whole post is so relentlessly negative and petty (SCUM? FrAgile?) I won't give it credence. I personally use for my own projects TDD and plenty of comments in my code and it works (or correlates if you prefer...) very well with good results.
the only justification for a thing is if it works. If they regularly do, as you just acknowledged they do multiple times, they're of value.
> and no one has demonstrated actual cause and effect
If repeated success S correlates with repeated use of methodology M, that's a damn strong sign of causation, and if it isn't, I'd still use it.
Actually your whole post is so relentlessly negative and petty (SCUM? FrAgile?) I won't give it credence. I personally use for my own projects TDD and plenty of comments in my code and it works (or correlates if you prefer...) very well with good results.
> Actually your whole post is so relentlessly negative and petty (SCUM? FrAgile?) I won't give it credence.
Have a sense of humor. If TDD works for you, continue using it. I've done TDD before and sometimes still do.
Sometimes people are negative for a reason. I've seen enough iterations of these methodologies that I don't think they have any special value. Should a cattle ranch be more "agile?" Maybe, but honestly, I doubt that would end well. That's an extreme example, but even different software products may not necessitate the same workflows that these methodologies are intended to create.
The point is there isn't necessarily anything in particular about any of these loosely related methodologies that makes them special or effective for everything. In fact, they fail to live up to their promise quite often because they're treated as if they've been proven to be more effective than hypothetical alternatives, which simply isn't true.
> the only justification for a thing is if it works. If they regularly do, as you just acknowledged they do multiple times, they're of value.
Yes. However, I've personally never been with an organization that actually attempted to measure whether a methodology was working or not. My guess is, the vast majority of the time, methodologies are a magic talisman to ward off the bad C-level spirits and bring good fortune to middle management, and sometimes make it look like more work is being done than is actually.
I'm sure those organizations exist, but if they are actually willing to do such honest self assessment, they're probably capable of arriving at the same place without needing a pre-built methodology to start with.
Have a sense of humor. If TDD works for you, continue using it. I've done TDD before and sometimes still do.
Sometimes people are negative for a reason. I've seen enough iterations of these methodologies that I don't think they have any special value. Should a cattle ranch be more "agile?" Maybe, but honestly, I doubt that would end well. That's an extreme example, but even different software products may not necessitate the same workflows that these methodologies are intended to create.
The point is there isn't necessarily anything in particular about any of these loosely related methodologies that makes them special or effective for everything. In fact, they fail to live up to their promise quite often because they're treated as if they've been proven to be more effective than hypothetical alternatives, which simply isn't true.
> the only justification for a thing is if it works. If they regularly do, as you just acknowledged they do multiple times, they're of value.
Yes. However, I've personally never been with an organization that actually attempted to measure whether a methodology was working or not. My guess is, the vast majority of the time, methodologies are a magic talisman to ward off the bad C-level spirits and bring good fortune to middle management, and sometimes make it look like more work is being done than is actually.
I'm sure those organizations exist, but if they are actually willing to do such honest self assessment, they're probably capable of arriving at the same place without needing a pre-built methodology to start with.
> If repeated success S correlates with repeated use of methodology M, that's a damn strong sign of causation, and if it isn't, I'd still use it.
the problem is that several different methodologies "worked multiple times" in practice, over the time, often in the same company, and every time the managers of the era sold it as "a great innovation" and abandoned it for the new trendy fad few years later or because the new manager had different ideas and brought a different "culture" (scrum masters that charged thousands euro/day COUGH COUGH).
See many Google engineers that considered agile nonsense (for Google), no more than 3-4 years ago.
So basically it doesn't matter which one you chose.
the problem is that several different methodologies "worked multiple times" in practice, over the time, often in the same company, and every time the managers of the era sold it as "a great innovation" and abandoned it for the new trendy fad few years later or because the new manager had different ideas and brought a different "culture" (scrum masters that charged thousands euro/day COUGH COUGH).
See many Google engineers that considered agile nonsense (for Google), no more than 3-4 years ago.
So basically it doesn't matter which one you chose.
There was a discussion on HN just yesterday that said that bureaucrats write rules that make life easier for the bureaucrats, not for everybody else.
No matter what the methodology, if the rules for your organization's implementation of it are written by bureaucrats, the result won't be developer productivity.
No matter what the methodology, if the rules for your organization's implementation of it are written by bureaucrats, the result won't be developer productivity.
Without proper understanding of the problem software is trying to solve, no methodology will help, period
The problem is always people.
Even if everyone buys into a process the process is only as good as the people in it.
A process doesn't guarantee results - it guarantees consistency. Sometimes that means you get consistently bad results. But the good thing about having an actual process is that it's easier to change it to see if it works if it isn't delivering.
The latter is what most process people forget - the process is a living thing, not a stone tablet of commandments.
But really, "Conceptual Integrity" is the key. When everyone is working towards a goal and cranking away it's magic, because things seem to happen on their own. They don't, though.
Even if everyone buys into a process the process is only as good as the people in it.
A process doesn't guarantee results - it guarantees consistency. Sometimes that means you get consistently bad results. But the good thing about having an actual process is that it's easier to change it to see if it works if it isn't delivering.
The latter is what most process people forget - the process is a living thing, not a stone tablet of commandments.
But really, "Conceptual Integrity" is the key. When everyone is working towards a goal and cranking away it's magic, because things seem to happen on their own. They don't, though.
Congratulations for discovering agile:
,,Individuals and interactions over processes and tools''
https://agilemanifesto.org
,,Individuals and interactions over processes and tools''
https://agilemanifesto.org
The reason processes get treated by stone tablets rather than living documents is that in most companies processes get handed down from on high, to the the people who actually have to live them.
In my view software development is largely a social problem. You can apply tools methodologies for certain parts successfully but there will never be an overarching methodology that solves all problems. In the end it's about people and their creativity, skills and diligence and you have to manage that on a case by case base. I feel a lot of software methodologies fall into the same trap as economic models. They look scientific and are very appealing to leaders but they don't connect to reality.
[deleted]
There is a software development methodology that actually works:
Manage everything with a prioritised list of things to get done. Always work on what is #1 priority. Don’t interrupt work that has already started.
I have used it for small personal projects and when managing large teams of developers. It’s simple. It works.
Manage everything with a prioritised list of things to get done. Always work on what is #1 priority. Don’t interrupt work that has already started.
I have used it for small personal projects and when managing large teams of developers. It’s simple. It works.
I just read your comments about you JIT compiler using reference counting with global optimization (see https://news.ycombinator.com/item?id=32283392, unfortunately reply is disabled, so I comment here).
Could you please provide more details, or some relevant paper or book references on how this works? I'm currently looking for a lean, sufficiently efficient solution for my Oberon+ runtime (see https://github.com/rochus-keller/Oberon ); I evaluated different solutions, one e.g. based on MPS, but I would prefer something which is lean and as simple as possible; so hints are welcome.
Could you please provide more details, or some relevant paper or book references on how this works? I'm currently looking for a lean, sufficiently efficient solution for my Oberon+ runtime (see https://github.com/rochus-keller/Oberon ); I evaluated different solutions, one e.g. based on MPS, but I would prefer something which is lean and as simple as possible; so hints are welcome.
They're too general. I think we'll start to see progress when methods say something about what is being built: a small site, a worldwide site, an internal bookkeeping app, car software, or whatever. Each kind of project needs to have different directives and its own knowledge base.
Primarily because knowledge work is hard to quantify. If you can't measure, you can't improve.
You can improve without measurement by using reasoning and experience. As an example, Groupon drove itself into the ground by only improving itself in ways it could measure. They added many nagging features that a/b tests showed worked. However, the CEO ignored his less measurable feeling that this was cheapening the brand.
The only methodology that worked for me and the teams i work with, is contract-driven development.
When two services talk to each other, you must define a clear contract first. We can name it "specification".
But in real world, bad task management will break the law !
When two services talk to each other, you must define a clear contract first. We can name it "specification".
But in real world, bad task management will break the law !
> Why don't simple models accurately describe complex systems and processes?
Which art has a good methodology for a group to collaborate on a work? There are really few examples in most arts of wide spread collaboration and those that do have it (eg. movies) produce very mediocre content.
My experience, stand ups, kanban and kick ass people who care about the job and less steps between support and dev.
For some reason the number of bugs did go up the more testers we had ..
For some reason the number of bugs did go up the more testers we had ..
Because people that get way into development methodologies spend more time thinking about development methodologies than actual development.
It's always about reorganizing workers output, and never about why there are so many bosses to produce for.
Try all the methodology you want, my experience is the most effective tool is competent, motivated people.
Software development methodologies exist on several fault lines:
Software development isn't like most orgs, where the boss can do the job of their underling (even in most engineering disciplines this isn't true). This disrupts the normal MBA expectation of power dynamic and replaceability.
The power dynamic disruption is due to a communication barrier. It is probably mathematically impossible to encode all the issues and complexities in whatever IT system smorgasborg some IT person's day to day exists at to a box-and-arrows spreadsheet manager.
I almost suspect this is like many theory of computation proofs where complexity is either extremely high even in seemingly trivial circumstances, or exists in mathematical impossibility.
Anyway, that means the methodology exists not only at a push-and-pull fault line of power and control, it exists at a communication barrier that is fundamentally impossible to overcome.
The power dynamic disruption is such that: who manages the company, the managers, or the automated IT systems that do 90% of the management work, silently and in ways the human managers can't even fathom? Yet every modern company will only survive in the markets, even with cartel/monopoly advantages, with extensive IT systems automation. Even if they maintain position, the profit demands from shareholders will doom a management group if they can't implement IT.
But of course MBAs and management schools still don't get this. Accounting is needed by all MBAs, but IT is for "MIS people", it's for grunt work / low level MBAs.
Now add this power dynamic to heavy demand for labor, and a hatred of MBAs to pay labor good wages, possibly more than THEY make. They won't pay Developers per the real power dynamic. So:
- there's always turnover, since Devs make money by job hopping, the MBAs won't give massive amounts of money to a Dev except in rare places like Silicon Valley
- or they outsource, and there's a 12 hour delay and a language barrier on top of the normal communication barrier
So aside from the Mangement<->Labor comm barrier, there is either a System Documentation comm shortfall, so labor turnover / outsourcing destroys that, which eventually undermines productivity of a project long term, so the methodology, which is SUPPOSED to protect that long term, but has no provisions to do so, fails.
ANother dynamic is that the methodology doesn't really address disagreement. Methodologies can only address devleopment where people agree, but if there are technical, approach, economic/scope, requirements, or other differences in opinions between different groups that paralyze things, and the Management (because of the comm barrier) cannot decide or even realize they need to decide, things drag. The "methodology" fails, but software development methodologies don't have dispute resolution in them.
Software development isn't like most orgs, where the boss can do the job of their underling (even in most engineering disciplines this isn't true). This disrupts the normal MBA expectation of power dynamic and replaceability.
The power dynamic disruption is due to a communication barrier. It is probably mathematically impossible to encode all the issues and complexities in whatever IT system smorgasborg some IT person's day to day exists at to a box-and-arrows spreadsheet manager.
I almost suspect this is like many theory of computation proofs where complexity is either extremely high even in seemingly trivial circumstances, or exists in mathematical impossibility.
Anyway, that means the methodology exists not only at a push-and-pull fault line of power and control, it exists at a communication barrier that is fundamentally impossible to overcome.
The power dynamic disruption is such that: who manages the company, the managers, or the automated IT systems that do 90% of the management work, silently and in ways the human managers can't even fathom? Yet every modern company will only survive in the markets, even with cartel/monopoly advantages, with extensive IT systems automation. Even if they maintain position, the profit demands from shareholders will doom a management group if they can't implement IT.
But of course MBAs and management schools still don't get this. Accounting is needed by all MBAs, but IT is for "MIS people", it's for grunt work / low level MBAs.
Now add this power dynamic to heavy demand for labor, and a hatred of MBAs to pay labor good wages, possibly more than THEY make. They won't pay Developers per the real power dynamic. So:
- there's always turnover, since Devs make money by job hopping, the MBAs won't give massive amounts of money to a Dev except in rare places like Silicon Valley
- or they outsource, and there's a 12 hour delay and a language barrier on top of the normal communication barrier
So aside from the Mangement<->Labor comm barrier, there is either a System Documentation comm shortfall, so labor turnover / outsourcing destroys that, which eventually undermines productivity of a project long term, so the methodology, which is SUPPOSED to protect that long term, but has no provisions to do so, fails.
ANother dynamic is that the methodology doesn't really address disagreement. Methodologies can only address devleopment where people agree, but if there are technical, approach, economic/scope, requirements, or other differences in opinions between different groups that paralyze things, and the Management (because of the comm barrier) cannot decide or even realize they need to decide, things drag. The "methodology" fails, but software development methodologies don't have dispute resolution in them.
> Methodologies can only address devleopment where people agree
Methodologies are largely about managing, resolving, and/or moving forward in the face of disagreeement. Some may be unrealistic in how they do that (e.g., assuming consensus is always attainable).
> software development methodologies don't have dispute resolution in them.
I know of no software development methodology that does not address dispute resolution (usually, with different mechanisms for different kinds of disputes.)
Methodologies are largely about managing, resolving, and/or moving forward in the face of disagreeement. Some may be unrealistic in how they do that (e.g., assuming consensus is always attainable).
> software development methodologies don't have dispute resolution in them.
I know of no software development methodology that does not address dispute resolution (usually, with different mechanisms for different kinds of disputes.)
1. The paper methodology that everybody completely ignores - this is Scrum or waterfall or rational or whatever they call it
2. The management ideology that management actually insists on and bases your pay on - the ticketing system (nowadays it's JIRA, but there's always been something similar). In theory it's driven by the paper methodology but in practice it's somewhat random.
3. The support methodology that everybody follows - drop everything and work on this emergency because Somebody Important mentioned it. This is what your reputation is built around, and is always independent of the other two methodologies.