11 ms·

Scrum is the new waterfall

127 points by snow_mac 11y ago

cechner 11y ago
I don't really agree with this - Scrum isn't really easy to do but in many situations it is the simplest approach to take. If you need to monitor your progress in 'real' terms (i.e., whats actually completed) Scrum is pretty much the minimum ceremony you can get away with in my experience. If you don't need to do that, say if you don't have a deadline that you need to know you wont hit ASAP, then Scrum is likely not a good fit. > It’s boring, its old, it leads to pointless meetings run by people who don’t write software, who don’t understand the technical process behind writing software and don’t always care I dont think these people are meant to be running scrums. > Adhere to the sprint commitment, even if you have to work over time. Yeah, and you will be if you dont adjust your commitments as soon as you realise youre not going to meet them. > Agile is about moving fast, building working software today and delivering with changing requirements Yes it is. And scrum adds time tracking on top of that. It sounds like you dont really know what the purpose of scrum is. And this is fair enough, because I dont think they had a very good explanatory service - it was pushed as the 'next big thing' like XML and SOAP was in the 90s.
- JoshTriplett 11y ago
  Having worked on a team using Scrum, I agree with this: it's pretty much the least process you can have while still fairly accurately predicting when work will get done and when any given feature will show up in the product. But it can be done well or badly: the team I worked on rigorously adhered to the process, and only cautiously diverged from it after careful consideration. Scrum done badly will rapidly become micromanagement instead.
  - wadetandy 11y ago
    I feel like every time I complain about scrum and my frustrations with it to people who believe in it, the response is always "well you just don't understand scrum," or, "you're just not doing scrum correctly." If the process is really as good as it is supposed to be and espoused to be by scrum evangelists (including many of the coaches my companies have hired to help us implement it), then I wonder why it's so hard to do correctly. I have worked with great engineering teams that have hummed along in informal processes that were similar to Kanban (though not defined as such). As soon as we were forced to switch to scrum, out productivity absolutely tanked, and we couldn't get the things we needed done because we were either in planning meetings all the time or we had to spend longer deciding whether to change our priorities mid-sprint as things would come up or lessons were learned, because that meant a lot of time and energy spent communicating up the chain why things did not get finished or the priorities changed.
    - JoshTriplett 11y ago
      > If the process is really as good as it is supposed to be and espoused to be by scrum evangelists (including many of the coaches my companies have hired to help us implement it), then I wonder why it's so hard to do correctly. I'm quite skeptical of "agile coaches" and similar. But in general, I'd suggest that it's easy to break by either swapping out or eliminating one of the defined roles, having someone unsuitable for those roles doing them (e.g. a manager or program manager serving as "scrum master", which instantly turns scrum into micromanagement), having an excessive number of mid-sprint changes (if changing a sprint's work mid-sprint happens every other sprint, something is very wrong), or not having any acceptance from the broader organization for getting work done at a regular cadence without constant "emergency interrupts". You should not be spending any significant fraction of your time in planning meetings; those occur once a sprint at most, and the sprint-planning portion should mostly consist of quickly doublechecking priorities and grabbing the top stories by priority. The other significant effort lies in breaking down and "sizing" stories (which is the job of the development team, not the person providing requirements). I do agree that Kanban can work as well; it just doesn't (in my opinion) have good predictive power for when work will get done. (On the other hand, some of our teams ended up switching to Kanban because Scrum doesn't work at all with a distributed team.)
- kibibu 11y ago
  I agree with you. "Scrum is the new waterfall" is true in this case in that both have been built as total strawmen. Scrum says nothing about unit tests, nor does it require sticking to the commitment (although it used to) > I dont think they had a very good explanatory service The most recent documentation on "Core" scrum is very simple and easy to parse.
  - irix 11y ago
    Yup, this guy sets up a total strawman which doesn't accurately describe how I've seen Scrum run at two major telecom software companies. We change mid-sprint (when we need to), we don't have non-programmers running scrums or writing user stories and if you don't complete a story in a sprint then you roll it over to the next one. If you have deadlines and contractual commitments to meet his suggestion of "use Kanban" strikes me as somewhat absurd. Running a team off of a Kanban board has its place (some of our support / platform teams use it) but I'm pretty sure your business owners want a better answer for when something is going to be delivered than 'when my Kanban board is empty'.
    - jdbernard 11y ago
      This isn't a straw man. This is exactly how Scrum gets implemented when management is running the process and not the development team.
      - snow_mac 11y ago
        +1
    - snow_mac 11y ago
      What it delivered soon? Put it in the top of the Kanban board and set a rule that the stuff in the top of the defined list gets worked first.
- cechner 11y ago
  edit: I just noticed they said 'sprint commitment', and that they should adhere to it even if it runs overtime. This is probably the most wrong part of the article - you get done what you can, and let it affect your velocity. It is this velocity that is the central indicator of how much you can realistically achieve
  - theptip 11y ago
    I read "adhere to the sprint commitment" as being an undesirable aspect of Scrum that the author was complaining about, not something that Scrum is lacking. It's certainly one of the bad parts of Scrum as commonly interpreted; c.f. http://www.peterkretzman.com/wp-content/uploads/2014/10/Asking-for-estimates.png http://www.peterkretzman.com/wp-content/uploads/2014/10/Aski.... (That's why newer docs tend to substitute "commitment" with "forecast", to clarify the Manifesto author's intent).
    - cechner 11y ago
      interesting - I recently heard someone call it a forecast and thought 'man why don't they use that term in scrum?' Nice to know that they actually do (I havent read up on it in some time, probably should)
- mwhuber 11y ago
  > It sounds like you dont really know what the purpose of scrum is. Agreed. People lose sight of this being a "framework" far too often. Make it fit your needs and run with it.
- ubernostrum 11y ago
  It sounds like you dont really know what the purpose of scrum is. Unfortunately, every response to "we tried process/technique X and it failed" in this space is ultimately "you didn't understand it" or "you did it wrong". So no true scrum would have... No true Agile shop would have... And where does that get us? It appears that the success rate of people understanding and implementing these things is very close to 0%. Maybe the problem is with the processes/techniques after all.
  - Laaw 11y ago
    You only hear about the people struggling with agile because the people not struggling are busy working on stuff.
  - matthewmacleod 11y ago
    It appears that the success rate of people understanding and implementing these things is very close to 0% I don't think this is the case. You're likely only hearing about the failures. Here's a counterpoint – we implemented Scrum. It didn't cause any real issues, increased the speed with which we delivered features to customers, and increased the visibility of everything that was happening both within the development team and within the wider business. Part of that was having a dedicated individual responsible for managing and implementing that process who made sure that it was actually achieving things we wanted to, rather than being a tick-box exercise, and who isn't afraid to make modifications such that the process better reflects the needs of the team. In fact, I'd argue that the problem is completely the opposite to what you imply – it's not that people don't implement 'true' agile or 'true' scrum, but that they try to do so, rather than using these systems as a basis for building a development process that works for their team. No true agile team is slavishly adherent to rules that don't work.
  - cechner 11y ago
    well allow me to put a note here as someone who uses it successfully regularly. Also I explain several times why he doesn't seem to understand it - having non-technical people running his scrums, working overtime and screwing up their velocity measurements, not being able to cope with changing requirements. These are things that scrum was built to _directly address_. I say again, if you're criticising scrum as being too onerous, you are probably either using it wrong or using it where you shouldnt (where you dont need to track your progress.)
- anon4 11y ago
  I think we can just summarize the entire thing now and forever as "Management leading developer meetings always leads to tears".
dbg31415 11y ago
This is so negative. Look... the process can't be, "Hey you get all the time in the world to build undefined requirements with out providing any sort of insight." The reason you let people who don't code in to the meetings is because they pay your salary -- right? So translate. Give them something that makes them feel you are spending their money correctly. It's not all that hard to just define requirements, put a line in the sand for what you think you can get done in a two week block, and show your progress on a board -- is it? This article seems to take the stance, "Devs are the only ones who matter and everyone else is someone who is going to make me sit in a meeting I don't want to be in." It's really immature to think this way, and short sighted. You need some sort of process, some sort of roadmap, so your sales and marketing team can drum up interest for the product and the team can be successful growing the business. This isn't an academic exercise, it's a job, and you work on a team that requires communication to operate.
- 6d0debc071 11y ago
  If the primary way information flows between teams in your organisation is by throwing everyone in a room on a bi-weekly basis, you don't have much of an organisation. That's not professionalism, it's bad management under the heading, 'better than nothing.'
lordlarm 11y ago
But then you're working in a bigger business where you do actually need to interact with managers and internal/external stakeholders. And they're all asking you: «When can you deliver?». Yes, estimating is hard. It's impossible really, but everyone knows this and accept the consequences of delayed deliveries and blocking events. But they want status updates and delivery schedules all the same. Pointless exercise maybe? But in real life and in business actually having someone thinking longer than three days ahead is usually a necessity, in my experience. I agree though that you should minimize the amount of pointless meetings and solve blocking issues as they come - this is more a sign of a good tech lead and healthy work environment rather than weaknesses in the Scrum methodology.
bkjelden 11y ago
The fatal flaw of any process - scrum, kanban, waterfall, etc, is when engineering teams try to use them as a replacement for communication rather than as a communication aide.
- Laaw 11y ago
  Yep. Process is compensation for lack of talent, which may sound cruel or arrogant but it's not. If you're great, you can self direct, design, and implement what needs to happen in your project with no help or management at all. It's totally okay not to be great, but when you're not great you need help, and help comes in the form of management, and management needs a way to set and manage expectations. Agile is one way, waterfall is another.
badloginagain 11y ago
I've been at a few studios, all expounding how they're "Agile! Scrum! Fast-Moving!" And I've seen true "agile" horror shows. Stand-ups consisting of everyone either A) trying to prove they actually did work yesterday in as many words as possible or B) taking this as a chance to have a nice chat with everyone. Hour-long daily stand-ups are not agile. The worst though was the planning meeting for next sprint, where no one had a #$%^ing clue what they needed to do, what the priority was, where the dependencies lay. A day every two weeks you dread. I think the big take-away is not to do Agile for Agile's sake. Do it to solve a problem- if developers don't know what each-other is doing, there's solutions. Working on a product with changing requirements? Work in sprints to be able to respond to that. But don't do it because it's what all the cool kids are doing. EDIT: The inverse is also true, people. It's not supposed to be a religion, you can pick and choose practices and processes to fit your requirements. Do what you need to do to achieve the goals you want to achieve.
- kuschku 11y ago
  At the university where I am, we were discussing today in one compsci class how agile is something that only works if you don’t care about consistent quality and only care about always having the newest, shiniest, greatest. And how, if you are working on software for ESA, or working for one of the largest internet retailers, or if you’re writing a control software for railway switches, waterfall is the only possible option. Even if the target is moving, agile is never able to provide quality. Some of my professors were hired before by large internet retailers to spend weeks trying to understand even their business processes, as the retailer had built their infrastructure without oversight and every employee was working on whatever they wanted. Just this "trying to understand what even is going on" helped them improve their processes and greatly increase their profit margin, as they were able to make many things more efficient with rethinking and rewriting. EDIT: I’ll add my definition of quality here: Your software is able to interact with third parties without them ever having to rewrite their software, your software can run for decades without or with little maintenance, and your software is well documented. In my opinion, Agile is very ill suited for these requirements. One example is the Internet of Things, where you can be sure no one is ever going to update their smart washing machine
calinet6 11y ago
Any system implemented without an understanding of how systems work, and how humans interact with them, will be painful. We need systems thinking, not any one prescribed process.
- dragonwriter 11y ago
  > We need systems thinking, not any one prescribed process. Problem is, its hard to get people doing systems thinking, especially about systems they are part of.
  - calinet6 11y ago
    It's hard, but it's the only problem remaining.
mmanfrin 11y ago
Scrum works fine when it's just programmers. Scrum and Agile become shackles when management gets involved and sees it as a status-checkup for their top-down view. The latter scenario seems to be 90% of situations, unfortunately.
- deleted 11y ago
  [deleted]
andy_ppp 11y ago
The best project manager I ever worked with just wrote everyone's names on the board, asked what they were working on today, writing it on the board next to their name. You can imagine how the next day went; "So Andrew, how did X go yesterday, any blockers? Is it done? What are the issues, can we break this down further?" It's all you need.
carsongross 11y ago
It's amazing to me the lengths organizations will go to avoid the one thing that actually works: hiring a small team of really good developers, paying them a lot of money and giving them hard ship date.
- skylan_q 11y ago
  But if you have a few people develop and ship a product, what's everyone else going to do besides look stupid?
- rev_bird 11y ago
  That seems like laissez-faire waterfall to me. The problem with the "hard ship date" is that it usually comes with a set of expectations for what is ready on that date: If you need software X on July 1, what happens when software Y becomes more necessary on April 15?
  - carsongross 11y ago
    A hard ship date and flexible requirements is the way to do it: you force the issue and require your (great) developers to immanentize the software. It clarifies the mind and, assuming you didn't start off with absurd goals anyway, you get most of what you want. Most importantly, it gets you to ship.
- matthewmacleod 11y ago
  I've seen that go completely balls-up in several cases. The thing is, even really good developers can struggle to define what a complete and working system looks like.
PythonicAlpha 11y ago
As I experienced Scrum in practice, it is said that people should be "empowered". In reality, something totally different is happening: People are not empowered, but the management just delegates the responsibilities for the project to the developers and lays back, assured that they just have to wait for the "agile fruits" to be reaped. They have done everything, they could do, now the "empowered" employees have to see ... Those poor employees might feel "empowered", but in reality, they are "impoverished". They are now responsible for the project, but often without amble resources needed. For example, when they need additional hardware or rooms or .... they are not empowered to get it. They are still beggars. Instead, they are empowered to work longer hours to reach the project goals they have set themselves. Why did they such a stupid thing? Because they wanted to look bright or because of group pressure or because they want a raise ... And after they set their goals themselves, they are on their own. This is not "empowerment", it is not about people -- it is just a good excuse for the management to get rid of the responsibilities and to "motivate" people to work longer hours. It is the newest "silver bullet" process of a project management that already lost control.
- yexponential 11y ago
  This. 1000x. This is definitely one of the pitfalls of poorly implemented scrum. For bigger companies, scrum tends to be a decision by the higher ups and implemented by the lower ranks keeping middle management is disarray over their role in the change. Moreover as the author mentions agile is about people first, but followed by processes. If scrum teams don't have the power, or empowerment, to change the processes, to become more agile, to remove blockers/impediments, the team burns out / self destructs for the precise reason you mention about spending longer hours achieve the committed (not to mention the committed is affected by the deadlines which are manipulated by management/or worse, external stakeholders) in order to uphold their word/project. To me there is a flaw here. I do believe scrum can be an effective tool for a few use cases, but people often underestimate the warning signs. "Scrum is easy to learn, but difficult to master." - https://www.scrumalliance.org/community/articles/2011/may/scrum-from-student-to-master https://www.scrumalliance.org/community/articles/2011/may/sc...
  - 11y ago
plet 11y ago
Whats wrong with waterfall? Surely mis-using waterfall was the culprit. I'm guessing same goes for Scrum. I've never followed true scrum so my opinion might be jaded however the devil generally lies in the implementation of the process. You cannot fit the same tire on a truck and a kid's tricycle, same way you cannot fit the same process for all development cycle. If you team needs clear direction and everything well defined (written in stone), follow waterfall. If your team needs formal process but can do some things on their own (say a team filled with new hires and one lone experienced dev), scrum might not be so bad. Kanbaan is good when everyone knows what they're doing and you really just want to know which stages do you need to focus more on. You're best bet is probably to try all three and whatever else exists, mix and match until you can successfully deliver your products without a whole lotta overhead and then keep tweaking the process when conditions change (new hires, folks leaving, change in goals/features).
- anon4 11y ago
  Waterfall is literally a strawman methodology made up to illustrate the worst possible way to build software (short of having a million monkeys trying random programs), in order to serve as contrast to a way that actually works.
  - plet 11y ago
    I wasn't really going towards defending waterfall[1] but lemme give it a try. Waterfall might be not bad when you cannot have feedback mechanisms, you cannot roll out changes in phases, where requirements/scopes are fixed, tech stack is well defined and products have matured enough. [1] : wanted to more say, use the right tool for the right thing in the right way. I don't think its easy but its doable.
matdrewin 11y ago
Similar to choosing a web framework, most often the issue is with the people, not the methodology/framework.
kaspm 11y ago
I don't understand why this is on the top of Hacker News. It seems to be one person's opinions and experiences about complex issues that face hundreds of thousands of engineers in thousands of companies across the world. Nothing in the article makes me trust this persons perspective over any other. It's not thoroughly investigated with metrics over many case studies. There's no empirical evidence to back up his assertions. He doesn't have a reputation for other work that would make me trust his informed opinion over any others. There seems to be hundreds of articles touting every possible side of this issue, why did this one strike a chord?
- snow_mac 11y ago
  Your right, I presented no evidence. Honestly it was a rhetorical post that I did not expect to strike the cord that it did.
antiffan 11y ago
Scrum at its core is about setting your team up to LEARN and improve by introducing feedback cycles. That's it. If your team learns after one cycle that they are more effective without one of the common ceremonies, then your team should drop it. The problem that Adam is observing is not with Scrum itself - it's that too many miseducated managers lose sight of the point and are obsessing over the wrong details. Source: I have been on extremely successful Scrum teams, I have seen Scrum done properly dramatically transform "stale" teams, and I have trained with Jeff Sutherland, one of Scrum's founders.
a3n 11y ago
I'm at a small BigCo. We have a few pilot agile projects. Based on what I see them doing, and what I read in the article, it looks like scrums are two week death marches.
FatalBaboon 11y ago
Straying away from any consideration of "how well agile was implemented", I've never been at a shop that seemed to get any real advantage by saying they are "agile". Although my experience is only 4 shops on that matter. I would argue that since the method is deliberately left unclear, in reality it mostly profits to whoever wants to game it to his/her advantage. And if everybody wants the project to succeed as their respective primary goal, then you do not need such methodology anyway. Do whatever seems to work best for the team, and don't name it. Don't waste time writing blog posts about how you found a new groundbreaking way to work, as these matters are subjective. For example, now I work by asking whatever needs most attention right now, getting it done, and then asking again. No backlog, no notes anywhere, nothing. If we forget about something and it is important, it will come back up. It has no name and it works perfectly for us!
parasubvert 11y ago
The problem is that Scrum is rather lukewarm agile. It's mostly about toe-dipping, not making big changes in how you think about how you work. It can lead to this, but it just really often doesn't. Firstly, Scrum too often becomes the waterSCRUMfall - you don't deal with the problem end-to-end, you insert a version of Scrum in the middle of a broken organizational context. Secondly, Scrum also mostly has a lot to say about team organizational structure, reporting, and process (which managers like) but not so much about software development practices (which help you do your job). This can lead to busy work and misinterpretation from those who "manage" software rather than those who "do" software. Thirdly, I have a theory that a lot of the fallout from Scrum and agile not working is due to people trying to find something easier to digest than Extreme Programming, which includes nearly all the development practices that scrum teams pick and choose. Once you look for something easier to adapt to, meaning you don't have to change everything, it becomes easier for agile consultants to keep modifying the already lukewarm process to be a 10% improvement of the mess you already have rather than a leapfrog replacement. And the few times a leapfrog is OK, it requires a lot of organizational air cover and buy-in, top to bottom, because you can't "force" people to work in a very different way without it being rejected. My view is - if your approach to building software is broken, and you want to do something different, you have two choices: a) build a process organically from the top down and bottom up simultaneously - perhaps a mix of Kanban for change management, and individual development practices that the software teams & senior developers want to do. b) if you have the willpower and lack the knowledge or patience, adopt a "more extreme" agile method like Extreme Programming, and complement it with organizational change management techniques like Kanban. And ensure you have people or partners that can really help you with it (at all levels - not just as "coaches"). Finally, Kanban is not a software development process. It's a change management process. You an evolve a software development process out of Kanban and picking/choosing from other ideas from XP or others. Kanban is good in that it allows you to tailor an approach that deals with "big picture" organizational change issues first -- trying to do too much and piling up requirements inventory or work-in-progress. But it doesn't say anything about how to build software.
j_mcnally 11y ago
Where do I send my money! Scrum is the worst! Kill Scrum
- snow_mac 11y ago
  This made me laugh. Send money to adam dot bourg at gmail
je42 11y ago
If you got a bad development process it doesn't matter how you label it SCRUM, Waterfall or Kanban. The main is issue is to implement SCRUM properly. If I have seen it both ways. The difference is like night and day.

127 points by snow_mac 11y ago

I don't really agree with this - Scrum isn't really easy to do but in many situations it is the simplest approach to take. If you need to monitor your progress in 'real' terms (i.e., whats actually completed) Scrum is pretty much the minimum ceremony you can get away with in my experience. If you don't need to do that, say if you don't have a deadline that you need to know you wont hit ASAP, then Scrum is likely not a good fit. > It’s boring, its old, it leads to pointless meetings run by people who don’t write software, who don’t understand the technical process behind writing software and don’t always care I dont think these people are meant to be running scrums. > Adhere to the sprint commitment, even if you have to work over time. Yeah, and you will be if you dont adjust your commitments as soon as you realise youre not going to meet them. > Agile is about moving fast, building working software today and delivering with changing requirements Yes it is. And scrum adds time tracking on top of that. It sounds like you dont really know what the purpose of scrum is. And this is fair enough, because I dont think they had a very good explanatory service - it was pushed as the 'next big thing' like XML and SOAP was in the 90s.

JoshTriplett 11y ago
Having worked on a team using Scrum, I agree with this: it's pretty much the least process you can have while still fairly accurately predicting when work will get done and when any given feature will show up in the product. But it can be done well or badly: the team I worked on rigorously adhered to the process, and only cautiously diverged from it after careful consideration. Scrum done badly will rapidly become micromanagement instead.
- wadetandy 11y ago
  I feel like every time I complain about scrum and my frustrations with it to people who believe in it, the response is always "well you just don't understand scrum," or, "you're just not doing scrum correctly." If the process is really as good as it is supposed to be and espoused to be by scrum evangelists (including many of the coaches my companies have hired to help us implement it), then I wonder why it's so hard to do correctly. I have worked with great engineering teams that have hummed along in informal processes that were similar to Kanban (though not defined as such). As soon as we were forced to switch to scrum, out productivity absolutely tanked, and we couldn't get the things we needed done because we were either in planning meetings all the time or we had to spend longer deciding whether to change our priorities mid-sprint as things would come up or lessons were learned, because that meant a lot of time and energy spent communicating up the chain why things did not get finished or the priorities changed.
  - JoshTriplett 11y ago
    > If the process is really as good as it is supposed to be and espoused to be by scrum evangelists (including many of the coaches my companies have hired to help us implement it), then I wonder why it's so hard to do correctly. I'm quite skeptical of "agile coaches" and similar. But in general, I'd suggest that it's easy to break by either swapping out or eliminating one of the defined roles, having someone unsuitable for those roles doing them (e.g. a manager or program manager serving as "scrum master", which instantly turns scrum into micromanagement), having an excessive number of mid-sprint changes (if changing a sprint's work mid-sprint happens every other sprint, something is very wrong), or not having any acceptance from the broader organization for getting work done at a regular cadence without constant "emergency interrupts". You should not be spending any significant fraction of your time in planning meetings; those occur once a sprint at most, and the sprint-planning portion should mostly consist of quickly doublechecking priorities and grabbing the top stories by priority. The other significant effort lies in breaking down and "sizing" stories (which is the job of the development team, not the person providing requirements). I do agree that Kanban can work as well; it just doesn't (in my opinion) have good predictive power for when work will get done. (On the other hand, some of our teams ended up switching to Kanban because Scrum doesn't work at all with a distributed team.)
kibibu 11y ago
I agree with you. "Scrum is the new waterfall" is true in this case in that both have been built as total strawmen. Scrum says nothing about unit tests, nor does it require sticking to the commitment (although it used to) > I dont think they had a very good explanatory service The most recent documentation on "Core" scrum is very simple and easy to parse.
- irix 11y ago
  Yup, this guy sets up a total strawman which doesn't accurately describe how I've seen Scrum run at two major telecom software companies. We change mid-sprint (when we need to), we don't have non-programmers running scrums or writing user stories and if you don't complete a story in a sprint then you roll it over to the next one. If you have deadlines and contractual commitments to meet his suggestion of "use Kanban" strikes me as somewhat absurd. Running a team off of a Kanban board has its place (some of our support / platform teams use it) but I'm pretty sure your business owners want a better answer for when something is going to be delivered than 'when my Kanban board is empty'.
  - jdbernard 11y ago
    This isn't a straw man. This is exactly how Scrum gets implemented when management is running the process and not the development team.
    - snow_mac 11y ago
      +1
  - snow_mac 11y ago
    What it delivered soon? Put it in the top of the Kanban board and set a rule that the stuff in the top of the defined list gets worked first.
cechner 11y ago
edit: I just noticed they said 'sprint commitment', and that they should adhere to it even if it runs overtime. This is probably the most wrong part of the article - you get done what you can, and let it affect your velocity. It is this velocity that is the central indicator of how much you can realistically achieve
- theptip 11y ago
  I read "adhere to the sprint commitment" as being an undesirable aspect of Scrum that the author was complaining about, not something that Scrum is lacking. It's certainly one of the bad parts of Scrum as commonly interpreted; c.f. http://www.peterkretzman.com/wp-content/uploads/2014/10/Asking-for-estimates.png http://www.peterkretzman.com/wp-content/uploads/2014/10/Aski.... (That's why newer docs tend to substitute "commitment" with "forecast", to clarify the Manifesto author's intent).
  - cechner 11y ago
    interesting - I recently heard someone call it a forecast and thought 'man why don't they use that term in scrum?' Nice to know that they actually do (I havent read up on it in some time, probably should)
mwhuber 11y ago
> It sounds like you dont really know what the purpose of scrum is. Agreed. People lose sight of this being a "framework" far too often. Make it fit your needs and run with it.
ubernostrum 11y ago
It sounds like you dont really know what the purpose of scrum is. Unfortunately, every response to "we tried process/technique X and it failed" in this space is ultimately "you didn't understand it" or "you did it wrong". So no true scrum would have... No true Agile shop would have... And where does that get us? It appears that the success rate of people understanding and implementing these things is very close to 0%. Maybe the problem is with the processes/techniques after all.
- Laaw 11y ago
  You only hear about the people struggling with agile because the people not struggling are busy working on stuff.
- matthewmacleod 11y ago
  It appears that the success rate of people understanding and implementing these things is very close to 0% I don't think this is the case. You're likely only hearing about the failures. Here's a counterpoint – we implemented Scrum. It didn't cause any real issues, increased the speed with which we delivered features to customers, and increased the visibility of everything that was happening both within the development team and within the wider business. Part of that was having a dedicated individual responsible for managing and implementing that process who made sure that it was actually achieving things we wanted to, rather than being a tick-box exercise, and who isn't afraid to make modifications such that the process better reflects the needs of the team. In fact, I'd argue that the problem is completely the opposite to what you imply – it's not that people don't implement 'true' agile or 'true' scrum, but that they try to do so, rather than using these systems as a basis for building a development process that works for their team. No true agile team is slavishly adherent to rules that don't work.
- cechner 11y ago
  well allow me to put a note here as someone who uses it successfully regularly. Also I explain several times why he doesn't seem to understand it - having non-technical people running his scrums, working overtime and screwing up their velocity measurements, not being able to cope with changing requirements. These are things that scrum was built to _directly address_. I say again, if you're criticising scrum as being too onerous, you are probably either using it wrong or using it where you shouldnt (where you dont need to track your progress.)
anon4 11y ago
I think we can just summarize the entire thing now and forever as "Management leading developer meetings always leads to tears".

dbg31415 11y ago

This is so negative. Look... the process can't be, "Hey you get all the time in the world to build undefined requirements with out providing any sort of insight." The reason you let people who don't code in to the meetings is because they pay your salary -- right? So translate. Give them something that makes them feel you are spending their money correctly. It's not all that hard to just define requirements, put a line in the sand for what you think you can get done in a two week block, and show your progress on a board -- is it? This article seems to take the stance, "Devs are the only ones who matter and everyone else is someone who is going to make me sit in a meeting I don't want to be in." It's really immature to think this way, and short sighted. You need some sort of process, some sort of roadmap, so your sales and marketing team can drum up interest for the product and the team can be successful growing the business. This isn't an academic exercise, it's a job, and you work on a team that requires communication to operate.

6d0debc071 11y ago
If the primary way information flows between teams in your organisation is by throwing everyone in a room on a bi-weekly basis, you don't have much of an organisation. That's not professionalism, it's bad management under the heading, 'better than nothing.'

lordlarm 11y ago

But then you're working in a bigger business where you do actually need to interact with managers and internal/external stakeholders. And they're all asking you: «When can you deliver?». Yes, estimating is hard. It's impossible really, but everyone knows this and accept the consequences of delayed deliveries and blocking events. But they want status updates and delivery schedules all the same. Pointless exercise maybe? But in real life and in business actually having someone thinking longer than three days ahead is usually a necessity, in my experience. I agree though that you should minimize the amount of pointless meetings and solve blocking issues as they come - this is more a sign of a good tech lead and healthy work environment rather than weaknesses in the Scrum methodology.

bkjelden 11y ago

The fatal flaw of any process - scrum, kanban, waterfall, etc, is when engineering teams try to use them as a replacement for communication rather than as a communication aide.

Laaw 11y ago
Yep. Process is compensation for lack of talent, which may sound cruel or arrogant but it's not. If you're great, you can self direct, design, and implement what needs to happen in your project with no help or management at all. It's totally okay not to be great, but when you're not great you need help, and help comes in the form of management, and management needs a way to set and manage expectations. Agile is one way, waterfall is another.

badloginagain 11y ago

I've been at a few studios, all expounding how they're "Agile! Scrum! Fast-Moving!" And I've seen true "agile" horror shows. Stand-ups consisting of everyone either A) trying to prove they actually did work yesterday in as many words as possible or B) taking this as a chance to have a nice chat with everyone. Hour-long daily stand-ups are not agile. The worst though was the planning meeting for next sprint, where no one had a #$%^ing clue what they needed to do, what the priority was, where the dependencies lay. A day every two weeks you dread. I think the big take-away is not to do Agile for Agile's sake. Do it to solve a problem- if developers don't know what each-other is doing, there's solutions. Working on a product with changing requirements? Work in sprints to be able to respond to that. But don't do it because it's what all the cool kids are doing. EDIT: The inverse is also true, people. It's not supposed to be a religion, you can pick and choose practices and processes to fit your requirements. Do what you need to do to achieve the goals you want to achieve.

kuschku 11y ago
At the university where I am, we were discussing today in one compsci class how agile is something that only works if you don’t care about consistent quality and only care about always having the newest, shiniest, greatest. And how, if you are working on software for ESA, or working for one of the largest internet retailers, or if you’re writing a control software for railway switches, waterfall is the only possible option. Even if the target is moving, agile is never able to provide quality. Some of my professors were hired before by large internet retailers to spend weeks trying to understand even their business processes, as the retailer had built their infrastructure without oversight and every employee was working on whatever they wanted. Just this "trying to understand what even is going on" helped them improve their processes and greatly increase their profit margin, as they were able to make many things more efficient with rethinking and rewriting. EDIT: I’ll add my definition of quality here: Your software is able to interact with third parties without them ever having to rewrite their software, your software can run for decades without or with little maintenance, and your software is well documented. In my opinion, Agile is very ill suited for these requirements. One example is the Internet of Things, where you can be sure no one is ever going to update their smart washing machine

calinet6 11y ago

Any system implemented without an understanding of how systems work, and how humans interact with them, will be painful. We need systems thinking, not any one prescribed process.

dragonwriter 11y ago
> We need systems thinking, not any one prescribed process. Problem is, its hard to get people doing systems thinking, especially about systems they are part of.
- calinet6 11y ago
  It's hard, but it's the only problem remaining.

mmanfrin 11y ago

Scrum works fine when it's just programmers. Scrum and Agile become shackles when management gets involved and sees it as a status-checkup for their top-down view. The latter scenario seems to be 90% of situations, unfortunately.

deleted 11y ago
[deleted]

andy_ppp 11y ago

The best project manager I ever worked with just wrote everyone's names on the board, asked what they were working on today, writing it on the board next to their name. You can imagine how the next day went; "So Andrew, how did X go yesterday, any blockers? Is it done? What are the issues, can we break this down further?" It's all you need.

carsongross 11y ago

It's amazing to me the lengths organizations will go to avoid the one thing that actually works: hiring a small team of really good developers, paying them a lot of money and giving them hard ship date.

skylan_q 11y ago
But if you have a few people develop and ship a product, what's everyone else going to do besides look stupid?
rev_bird 11y ago
That seems like laissez-faire waterfall to me. The problem with the "hard ship date" is that it usually comes with a set of expectations for what is ready on that date: If you need software X on July 1, what happens when software Y becomes more necessary on April 15?
- carsongross 11y ago
  A hard ship date and flexible requirements is the way to do it: you force the issue and require your (great) developers to immanentize the software. It clarifies the mind and, assuming you didn't start off with absurd goals anyway, you get most of what you want. Most importantly, it gets you to ship.
matthewmacleod 11y ago
I've seen that go completely balls-up in several cases. The thing is, even really good developers can struggle to define what a complete and working system looks like.

PythonicAlpha 11y ago

As I experienced Scrum in practice, it is said that people should be "empowered". In reality, something totally different is happening: People are not empowered, but the management just delegates the responsibilities for the project to the developers and lays back, assured that they just have to wait for the "agile fruits" to be reaped. They have done everything, they could do, now the "empowered" employees have to see ... Those poor employees might feel "empowered", but in reality, they are "impoverished". They are now responsible for the project, but often without amble resources needed. For example, when they need additional hardware or rooms or .... they are not empowered to get it. They are still beggars. Instead, they are empowered to work longer hours to reach the project goals they have set themselves. Why did they such a stupid thing? Because they wanted to look bright or because of group pressure or because they want a raise ... And after they set their goals themselves, they are on their own. This is not "empowerment", it is not about people -- it is just a good excuse for the management to get rid of the responsibilities and to "motivate" people to work longer hours. It is the newest "silver bullet" process of a project management that already lost control.

yexponential 11y ago
This. 1000x. This is definitely one of the pitfalls of poorly implemented scrum. For bigger companies, scrum tends to be a decision by the higher ups and implemented by the lower ranks keeping middle management is disarray over their role in the change. Moreover as the author mentions agile is about people first, but followed by processes. If scrum teams don't have the power, or empowerment, to change the processes, to become more agile, to remove blockers/impediments, the team burns out / self destructs for the precise reason you mention about spending longer hours achieve the committed (not to mention the committed is affected by the deadlines which are manipulated by management/or worse, external stakeholders) in order to uphold their word/project. To me there is a flaw here. I do believe scrum can be an effective tool for a few use cases, but people often underestimate the warning signs. "Scrum is easy to learn, but difficult to master." - https://www.scrumalliance.org/community/articles/2011/may/scrum-from-student-to-master https://www.scrumalliance.org/community/articles/2011/may/sc...
- 11y ago

plet 11y ago

Whats wrong with waterfall? Surely mis-using waterfall was the culprit. I'm guessing same goes for Scrum. I've never followed true scrum so my opinion might be jaded however the devil generally lies in the implementation of the process. You cannot fit the same tire on a truck and a kid's tricycle, same way you cannot fit the same process for all development cycle. If you team needs clear direction and everything well defined (written in stone), follow waterfall. If your team needs formal process but can do some things on their own (say a team filled with new hires and one lone experienced dev), scrum might not be so bad. Kanbaan is good when everyone knows what they're doing and you really just want to know which stages do you need to focus more on. You're best bet is probably to try all three and whatever else exists, mix and match until you can successfully deliver your products without a whole lotta overhead and then keep tweaking the process when conditions change (new hires, folks leaving, change in goals/features).

anon4 11y ago
Waterfall is literally a strawman methodology made up to illustrate the worst possible way to build software (short of having a million monkeys trying random programs), in order to serve as contrast to a way that actually works.
- plet 11y ago
  I wasn't really going towards defending waterfall[1] but lemme give it a try. Waterfall might be not bad when you cannot have feedback mechanisms, you cannot roll out changes in phases, where requirements/scopes are fixed, tech stack is well defined and products have matured enough. [1] : wanted to more say, use the right tool for the right thing in the right way. I don't think its easy but its doable.

matdrewin 11y ago

Similar to choosing a web framework, most often the issue is with the people, not the methodology/framework.

kaspm 11y ago

I don't understand why this is on the top of Hacker News. It seems to be one person's opinions and experiences about complex issues that face hundreds of thousands of engineers in thousands of companies across the world. Nothing in the article makes me trust this persons perspective over any other. It's not thoroughly investigated with metrics over many case studies. There's no empirical evidence to back up his assertions. He doesn't have a reputation for other work that would make me trust his informed opinion over any others. There seems to be hundreds of articles touting every possible side of this issue, why did this one strike a chord?

snow_mac 11y ago
Your right, I presented no evidence. Honestly it was a rhetorical post that I did not expect to strike the cord that it did.

antiffan 11y ago

Scrum at its core is about setting your team up to LEARN and improve by introducing feedback cycles. That's it. If your team learns after one cycle that they are more effective without one of the common ceremonies, then your team should drop it. The problem that Adam is observing is not with Scrum itself - it's that too many miseducated managers lose sight of the point and are obsessing over the wrong details. Source: I have been on extremely successful Scrum teams, I have seen Scrum done properly dramatically transform "stale" teams, and I have trained with Jeff Sutherland, one of Scrum's founders.

a3n 11y ago

I'm at a small BigCo. We have a few pilot agile projects. Based on what I see them doing, and what I read in the article, it looks like scrums are two week death marches.

FatalBaboon 11y ago

Straying away from any consideration of "how well agile was implemented", I've never been at a shop that seemed to get any real advantage by saying they are "agile". Although my experience is only 4 shops on that matter. I would argue that since the method is deliberately left unclear, in reality it mostly profits to whoever wants to game it to his/her advantage. And if everybody wants the project to succeed as their respective primary goal, then you do not need such methodology anyway. Do whatever seems to work best for the team, and don't name it. Don't waste time writing blog posts about how you found a new groundbreaking way to work, as these matters are subjective. For example, now I work by asking whatever needs most attention right now, getting it done, and then asking again. No backlog, no notes anywhere, nothing. If we forget about something and it is important, it will come back up. It has no name and it works perfectly for us!

parasubvert 11y ago

The problem is that Scrum is rather lukewarm agile. It's mostly about toe-dipping, not making big changes in how you think about how you work. It can lead to this, but it just really often doesn't. Firstly, Scrum too often becomes the waterSCRUMfall - you don't deal with the problem end-to-end, you insert a version of Scrum in the middle of a broken organizational context. Secondly, Scrum also mostly has a lot to say about team organizational structure, reporting, and process (which managers like) but not so much about software development practices (which help you do your job). This can lead to busy work and misinterpretation from those who "manage" software rather than those who "do" software. Thirdly, I have a theory that a lot of the fallout from Scrum and agile not working is due to people trying to find something easier to digest than Extreme Programming, which includes nearly all the development practices that scrum teams pick and choose. Once you look for something easier to adapt to, meaning you don't have to change everything, it becomes easier for agile consultants to keep modifying the already lukewarm process to be a 10% improvement of the mess you already have rather than a leapfrog replacement. And the few times a leapfrog is OK, it requires a lot of organizational air cover and buy-in, top to bottom, because you can't "force" people to work in a very different way without it being rejected. My view is - if your approach to building software is broken, and you want to do something different, you have two choices: a) build a process organically from the top down and bottom up simultaneously - perhaps a mix of Kanban for change management, and individual development practices that the software teams & senior developers want to do. b) if you have the willpower and lack the knowledge or patience, adopt a "more extreme" agile method like Extreme Programming, and complement it with organizational change management techniques like Kanban. And ensure you have people or partners that can really help you with it (at all levels - not just as "coaches"). Finally, Kanban is not a software development process. It's a change management process. You an evolve a software development process out of Kanban and picking/choosing from other ideas from XP or others. Kanban is good in that it allows you to tailor an approach that deals with "big picture" organizational change issues first -- trying to do too much and piling up requirements inventory or work-in-progress. But it doesn't say anything about how to build software.

j_mcnally 11y ago

Where do I send my money! Scrum is the worst! Kill Scrum

snow_mac 11y ago
This made me laugh. Send money to adam dot bourg at gmail

je42 11y ago

If you got a bad development process it doesn't matter how you label it SCRUM, Waterfall or Kanban. The main is issue is to implement SCRUM properly. If I have seen it both ways. The difference is like night and day.