13 ms·

Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sel

Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own. The fact that there is so much B.S. in Scrum doesn't mean that it has nothing of value to offer, though. Here's what I get out of it: 1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this. 2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line. 3. Ship functional products as frequently as possible. This is better than waiting until everything is done, because you can get feedback early and often from the end user. Okay, so that's 3 ideas. It's better than most.

walshemj 8y ago
You also missed the trade off's for increased speed compared to traditional wf projects. One of the problems with the Scrum model is its used for every thing - just like they used to try and do every project with WF and IS9000/BS5750
- nickelcitymario 8y ago
  Are you suggesting Waterfall projects are faster? I don't think you are, but that's how I read your sentence. Also I don't know what IS9000 or BS5750 are but they sound like they had amazing naming committees.
  - walshemj 8y ago
    Oh bum I meant ISO9000 BS5750 is the Uk equivalent (and I worked at my first job on a joint project with the BSI on BS5750) But and its a big but some times you need the rigor a properly done waterfall process provides Air traffic control for example. You seriously don't understand the trade offs you make with "agile" vs waterfall? I have done both very successfully.
    - nickelcitymario 8y ago
      Nope, don't understand the trade offs if you're suggesting scrum is slower than waterfall. That just doesn't line up with my experience. "Results may vary," though. The issue I've had with every other project management approach is the illusion of structure. I'm not an expert on all or any approach. But my experience is that everyone wants me to be able to project, since absolute certainty, what my team can get done in 12, 24, 36 months. And I can't. No one can. It's all bull shiitake. Scrum does not solve this problem. But it's honest about it. It says: "We can't tell you what could be done in 2 years. But we can probably tell you fairly accurately what we can do in the next 2 weeks. And if you let us proceed in these honest 2 week intervals, we'll probably get way more done than if we all agreed to the collective insanity of the waterfall lie." If you've done waterfall successfully, meaning you delivered a project on time, on budget, and on scope based on your original estimates for all three, then congratulations, you're a mythical beast. I, for one, cannot do that. I've failed every time. Every team I've worked with has failed every time. I've never seen it work.
      - AllegedAlec 8y ago
        > Nope, don't understand the trade offs if you're suggesting scrum is slower than waterfall. That just doesn't line up with my experience. "Results may vary," though. The idea is that if you have a well defined problem domain and you know exactly what the software is that you have to deliver, you don't need the short cycles, and all the meetings and pokering and whatnot would just be a waste of time. You know what you need to make, so you can just continue working.
        nickelcitymario 8y ago
        I suppose that makes sense "if you have a well defined problem domain and you know exactly what the software is that you have to deliver". I don't have a lot of experience in such areas though, and i can't help but wonder how often that's the case. If my problem domain was well defined, the problem would probably already be solved by someone and I'd use their code. Why reinvent? Am I being too simplistic?
tomtimtall 8y ago
The scrum manifesto is not overly verbose. It explains the value and concepts in a manor that does not lend itself to misrepresentation. There is definatly a lot of companies peddling hype around scrum but it has a very lean and strong core which is in no way pulling in that direction.
- HolyHaddock 8y ago
  What's the scrum manifesto?
  - specialist 8y ago
    Paraphrasing: The Agile Methodology is to argue about The Agile Methodology. Source: Certified Scrum Master training. Three times. Still have no idea what these charlatans are talking about.
    - jmulho 8y ago
      Which is a higher distinction, Scrum Master, Web Master, or Dungeon Master?
      - s73v3r_ 8y ago
        Dungeon Master. They're the only ones that can do something as simple as place an apple on a table, and tear apart your entire team.
  - zwily 8y ago
    Maybe they meant the Agile Manifesto? It’s short and hopefully not controversial: http://agilemanifesto.org http://agilemanifesto.org
    - nickelcitymario 8y ago
      But... my eyes. They burn. Thank heavens for developer tools and the ability to delete backgrounds. Jokes aside, good call linking that. Super short, super influential, super relevant to the conversation at hand.
Uberphallus 8y ago
> This does not sell books and consulting, so it evolved into a field of its own. It's funny how it turned into UML
- wpietri 8y ago
  UML comes out of a different culture of development, that of the Rational software crew. They had their own much more heavyweight process than the Agile folks: RUP, or the Rational Unified Process: https://en.wikipedia.org/wiki/Rational_Software#UML_and_RUP https://en.wikipedia.org/wiki/Rational_Software#UML_and_RUP There was a little overlap; in particular, Martin Fowler wrote an intentionally thin book called "UML Distilled". But the UML world was generally heavy on both up-front architecture and formal, heavyweight design process. The Agile world at the time was energetically opposed to that, thinking that the main value of UML was in having a consistent language for us to all sketch on whiteboards together.
  - cabalspecter 8y ago
    Too bad people didn't bother reading the Unified Process book, which clearly specifies the use of iterative and incremental development and the creation of just enough UML diagrams to communicate and document a system design. It even argues that working software should be used to describe an architecture in the Elaboration phase rather than a 10000 words document. It can actually be considered as one of the first agile methodologies. RUP and other flavors of UP just added tools and guides aimed to facilitate the implementation of UP, but it was misunderstood that every template and section must be filled out instead of actually thinking what to use depending on the project. Unfortunately the whole thing was ultimately bastardized by the non-technical template zombies that thought software development is like building a skyscraper.
    - specialist 8y ago
      The CASE motivated tooling got in the way. My go to joke: RationalRose is like an 800lb angry gorilla sitting between you and your work. Alistair Cockburn did a great post mortem about that era. Characterizing people as non-linear, first-order components in software development [1999] http://alistair.cockburn.us/Characterizing+people+as+non-linear%2c+first-order+components+in+software+development http://alistair.cockburn.us/Characterizing+people+as+non-lin... During that time, I strongly preferred lo-fi paper prototyping for UI. And I'd scratch out UML diagrams. Worked fine for intra-team. But it just didn't fly with management. We had to make everything more formal and pretty. Oh well.
mmusson 8y ago
My experience is that a good team does a good job. A bad team doesn’t. I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice. There are no quick fixes. People can improve but it takes time, dedication, and support.
- some_account 8y ago
  I really dislike agile. A product owner asked me once if I get some benefit from them...and no, I don't. Thry get a lot of benefit from me sharing what I'm doing because they can then keep track of it and communicate it to other people, but I don't get any benefit personally. I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the middle of that. It just complicates everything and makes me less connected and known in the company.
  - vannevar 8y ago
    I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. How exactly does agile prevent you from talking to your teammates and getting feedback from them?
    - betenoire 8y ago
      If I have a full and well-groomed backlog waiting for me at my desk, what's there to talk about? Sure, you can, but the the whole point of the PM is to take that off your shoulders and the parent is saying he doesn't want that lifted from him.
      - vannevar 8y ago
        A well-groomed backlog is not working code. So I don't get how that somehow means there's nothing to talk about. If there's an agile MVP, it's "write some working code, get feedback on it, then repeat until everyone's happy within some tolerance." Scrum is designed to increase feedback, but it's a floor, not a ceiling.
specialist 8y ago
You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management".
- rch 8y ago
  But you have to include 'estimates', which ruins everything (in non-trivial cases, yadda, yadda).
  - specialist 8y ago
    Estimating is my Achilles heel. Always has been. I'm way too optimistic. My workaround was to do jelly bean estimating. Get guesses from everyone, then use the average. Worked surprisingly well. We did other things to meet that target date, honor that estimate, of course. But that's a longer story.
    - commandlinefan 8y ago
      > I'm too optimistic Have you ever thought much about why, though? When I was young, I was super optimistic - and I got burned by all of the surprises (including the underspecified or unstated requirements), so I started to estimate pessimistically based on experience. But then I got stuck in this loop: "How long will this take?" "Probably two weeks" "What? Why two weeks? Why not two days? We only have two days. Say it will only take two days, or tell me everything you're going to be doing on an hour-by-hour basis to justify this high estimate!" So now I've just gotten really good at figuring out how long they want me to say it will take, say it will take that long, and shrug my shoulders when it takes longer. Since everybody else is doing the same thing (as they don't have any choice), it doesn't surprise anybody.
      - specialist 8y ago
        I have thought about it. A lot. I'm told I work too slow, dive too deep. Now I'm trying to figure out how to do just 80%, "good enough". When I was a kid, I published shareware. After getting a few 3:00am wake up calls from irate customers, I said "never again". I spent 15 years designing, engineering away technical support calls. It mostly worked. Later on... When my team(s) burned a CD, we rarely had to issue patches, hot fixes. Customers loved us. I thought that was the pinnacle of human achievement. Now, I feel like I'm still fighting battles over things no one cares about any more.
dvfjsdhgfv 8y ago
> 2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line. This point is of general usefulness and applies to many areas of our lives, not just software development.
- nickelcitymario 8y ago
  Preach
salty_biscuits 8y ago
My mental model was that ideally it is a greedy algorithm for job shop scheduling (dev time) with dt = two weeks and a horizon as long as your backlog. The biggest and most common failure mode I saw was having a bad product owner (it can be a single point of failure, devs have a team to help them out).
nwhatt 8y ago
Great job distilling the essence of scrum into three bullet points, I wouldn't disagree with those. Here's the common pitfalls as I see them: 1. Sprints offer flexibility but unless you educate the whole company waterfall + gantt charts are what the business side wants 2. Unless you educate all members of a scrum team on what the retrospective is, and let the developers drive it, you won't be effectively improving processes 3. I've always felt conflicted about the agile "working software over comprehensive documentation value". To me it implies that documentation is easier when the product is working and/or the product might change based on feedback, so you don't want to re-write the docs. To people who don't learn scrum/agile it means "don't write documentation"
- peder 8y ago
  That last point is simply working software _over_ documentation, meaning that in a world of finite resources what would you rather have? A pile of requirements and technical design docs _or_ a working product? All teams need to determine the right amount of documentation that maximizes total output of working software, but agility was--in part--a response to analysis paralysis and high overhead of many software implementations of the time.
  - HelloNurse 8y ago
    Not all documentation is equal. While design documentation tends to be anti-agile (but sometimes useful to avoid wasting more time on miscommunication and mistakes), end user documentation is, for all practical purposes, part of the valuable software product, as it enables end users to do what they want to do. Unfortunately, being able to neglect end user documentation makes many outfits treat it as a useless luxury, either because they are only judged on software (e.g. passing a test instead of having satisfied users) or because they don't care (e.g. many introverted hacker/artist open source maintainers). It's purely delusional agility, like driving fast by not stopping for fuel.
wpietri 8y ago
I think you are entirely right that the "sell books and consulting" is a major driver of what Agile became. I got involved in the Agile world circa 2000, but by 2010 or so my main feeling was increasing horror: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got together in 2001 to figure out what was common, and that's where the Agile Manifesto came from. Of the Agile Manifesto signatories, I think only two of them were Scrum people. These days, though, most people thing that Scrum is Agile and Agile is Scrum. I see three reasons for that. One, Scrum was the simplest, arguably the lowest common denominator; it had no technical practices. Two, it could be installed in place at existing waterfall companies doing what is effectively mini-waterfall, so there would be little disruption to the hierarchy. And three, it had a "certification" program, where a) anybody wanting a career bump could spend 2 days to get a "Master" certificate without taking any test or proving any competence, and b) any "consultant" wanting easy money could quickly become a Scrum trainer. Basically, Scrum became the Amway of software processes. If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished". And my point here isn't "Scrum bad", really. There are some great people in the Scrum world. My point is, "Business models shape outcomes, so be careful which you pick."
- mlthoughts2018 8y ago
  > "If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished"." I think this is a key insight, and I suspect for many people (myself included), the phrase you use when you say "Low-end Scrum" is just the only type of widespread Scrum we've ever seen practiced anywhere, ever, to the point that it makes us question whether Scrum itself is partly responsible, even in an idealized format. One of my good friends came up with the idea he called "barriers to anti-quality" to describe this. A good workflow process establishes inviolable norms that act like preventative barriers to doing things in an anti-quality way -- so that you specifically arrange the world such that trying to take a quality shortcut actually costs you more than just doing it in the quality way. We proposed trying to judge workflow and management practices based on how willing upper management was to give up control of the process in exchange for erecting barriers to anti-quality. If they wanted to force a team to pivot in some quality-destructive way, just on their whimsical preferences for reprioritizing different tasks according to vague business needs, they could not do it. Barriers to anti-quality would be like Odysseus pre-committing to be tied to the mast, so then when the Siren song comes, he cannot give in the temptation. I think a lot of the spirit of early Agile was meant to suggest something like this. Even though the method talks about being flexible and adapting when there are real business needs to adapt to, this gets bastardized when middle and upper management conflate adapting to real business priorities, and begrudgingly paying a cost in terms of quality lost due to pivoting developers, with demanding that people have to adapt to the management flavor of the month, unsubstantiated ideas about business priorities, often stemming from political power struggles, restructurings, quarterly earnings, etc. etc. What I really wish Scrum or Agile had, was a more unbreakable way to let development teams say no, and decline work or decline pivots. Basically to veto changes made to the backlog, and say that it violates an anti-quality principle for no good reason. A key failing of modern Agile / Scrum is that it doesn't create any type of stop-increasing-our-entropy-with-unsubstantiated-management-preferences notion of a barrier to anti-quality. Don't get me wrong, this is hardly a failing that us unique to Agile / Scrum. But I think when people talk about why in principle these methods fail, it's that they lack any mechanism of enforcement for this. As a result, they can be so easily politically subverted to just be a pivoting, bludgeoning tool of misguided or unexplained management choices, that almost always trade-off quality for anything else, and instead of ever looking back to understand when an under-investment in quality actually cost them, they just explain it away as some other team's fault. In a sense, Agile / Scrum (or 'Low-end Scrum' as you call it), is a tool to create managerial Dutch books. A manager gets to unilaterally disrupt on-going investment in quality without ever being held accountable when that gamble on short-term anti-quality causes losses. By the end, it makes developers very cranky that they are being jerked around with all this prescriptive and time-wasting overhead of meetings, planning, estimating, etc., only for this political anti-quality nonsense to go uncorrected anyway. If that's going to happen anyway, then what's the supposed value of all that costly Agile-specific overhead?
abritinthebay 8y ago
You’re absolutely right - and that’s the e tire core point of Scrum: to promote agile methodology (which can be summed up as you just did) However the reason there is “bs” (by which I assume you mean the process/meetings/etc) is that most teams suck at being agile. Scrum provides a more rigid framework so that a team can develop agile skills and then, when ready, move beyond scrum. Most people think Story Points or terminology like Standups comes from Scrum too - they don’t! They’re from XP. Scrum is exceedingly simple and suffers from being over complicated and dismissed by those who don’t understand it, The blog post above is no exception.
mraison 8y ago
I'm probably oversimplifying, but this looks like 3 different ways of saying "get feedback often" :)
- nickelcitymario 8y ago
  That's... actually pretty accurate? Dang.
  - funkymike 8y ago
    So it becomes this? * Get feedback often from the business owners * Get feedback often from the developers * Get feedback often from the users
    - s73v3r_ 8y ago
      And act on that feedback.
- virgilp 8y ago
  I argue that's actually a misconception of many scrum practitioners. It's not really "get feedback often", it's "get feedback early". "Often" is just a bad approximation of that. The difference is most obvious with retrospectives - if you just do them often they feel like a burden. What you want is to get early opportunities to improve .... but that's not necessarily through a very frequent retrospective! You have to let things crystallize a bit, so that people can observe the effect of process changes & give accurate+reasonable feedback on it.
OnlyRepliesToBS 8y ago
Scrum intentionally takes away power from the developers and puts it in the hands of a new manager class. It makes moving paperclip more important than making them. And that's evil.
termau 8y ago
Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to meet some stupid concept isn't funny ultimately it's a waste of time in itself
- monksy 8y ago
  That or having to estimate work based on your sprint. This is a 130 pointed task? Oh we only go up to 8.
- srtjstjsj 8y ago
  Are you saying you have projects that show 0 progress of any kind after 1 month, but still succeed later? What is happening in that first month?
  - lordnacho 8y ago
    Laying the foundations. Doesn't look like a house even after you've done it.
    - AnimalMuppet 8y ago
      Exactly. You need the end-to-end backbone working so that you can start adding end-to-end user-visible behaviors on it, a few at a time.
  - s73v3r_ 8y ago
    Research? Experimentation? Foundations?
    - Melchizedek 8y ago
      Pffft. We're talking crud apps here. Has any innovative software ever been developed in "sprints" using "user stories" and "story points" with a "product owner" and a "scrum master"? I doubt it.
jayd16 8y ago
I'd like to add priority next to progress and problems in the second item. Being able to pull things in and out of planning is one of the biggest advantages over waterfall.
ownagefool 8y ago
I can probably agree that sprints are usually more realistic than old school waterfall (arguably it depends, like all things) but why do we feel the need to perpetually sprint? A simple kanban board seems to give all the same benefits without the constant pressure and weekly death march to meet the end of sprint commitments.
- ggregoire 8y ago
  Because a simple kanban doesn't have any scope/goal, it's just a disorganized TODO list. A sprint/milestone is a way to set goals for the next 2-4 weeks. At the end of the iteration, you redefine new goals according to what would bring the most values to the clients at this new moment T. If the sprint is not finished, well it's not a big deal. You move the tasks back to the backlog, or in the next sprint, or delete them if it doesn't make sense anymore. And you decrease the number of tasks in the next sprint. You shouldn't feel a constant pressure to finish sprints if the velocity of your team is taken in account correctly.
  - s73v3r_ 8y ago
    "Because a simple kanban doesn't have any scope/goal, it's just a disorganized TODO list." Not everything has to be encapsulated in the TODO list. I mean, a Jira backlog is also just a TODO list.
  - ownagefool 8y ago
    To be fair, the simple kanban doesn't stop you from creating a scope/goal, you need to generate your TODO list somewhere, which isn't any different from sprints, but it's less rigid when it comes to the deadlines. More to the point is, setting sprint goals is defacto pressure which many people and orginsations are poor at handling, and we can largely avoid it by not having people doing or managing the work care about end of sprints, but just that the tasks are scoped and are of a reasonble size.
- nradov 8y ago
  The business benefit of having a longer planning horizon is that it enables making some commitments outside the agile team. In the real world sometimes that's necessary. A sprint cadence also helps ensure that the team does real retrospectives rather than putting those off. But certainly Kanban can work as well or better in some environments. Pick what works for the circumstances.
mey 8y ago
Another observation I have had, it provides much clearer and realistic progress reports to management. You can track the normalized points per day executed by the team to see their overall velocity. You have clear check points about what has been accomplished (which is why a shipped product is critical, it removes any chance for something not to meet DOD) On the dev side, I have never attended so many meetings. Technical debt being addressed is generally against the feedback loop, unless the PO/Leads of the team make it their first priority. Grooming meetings are a mix of people who care, those who don't, and vague stories. To save time, any new story got sent to one of the devs for a sniff test before grooming, to help ask critical questions early. Typically, the request is reasonable, but may run into a contradiction of the system. I have also found that, forcing scrum (or waterfall) on a product that is running at a difference release methodology is horrible. Got a customer that needs a new thing built by a specific date? That won't fit, unless the date is flexible and customer stake holders can be deeply involved in the process. Waterfall at least forces the customer to define the project up front and allows for calling out changes to the plan and thus changes to the scope. As with all the above, this sits on how skilled your project manager/scrum master/product owner are at their jobs. Anti patterns abound.
ggregoire 8y ago
I completely agree. I don't get why people try to strictly follow the methodology (and then complain about it) instead of just taking the core of it and apply what work for them and their company. I've a SCRUM master certification and still, I follow only what's good for us. It's totally fine for me to add a task in a current sprint. If you care about finishing the sprint, you just move a task of same points back in the backlog. It's also totally fine to allow the technical lead to add his own tasks to the sprint. You can do 80/20 for instance (business/technical values). It's not going to kill your business and will make your developers happy (SCRUM is about people, not process, right?).
- s73v3r_ 8y ago
  Problem is, that's a recipe for management ignoring all the stuff that gives developers power and agency, and taking all the micromanaging things.
- squeaky-clean 8y ago
  My best experience with Scrum was with a team that was willing to completely overhaul our weekly process if we needed to. We finally settled on a structure pretty different from the general recommendations, the most significant being we had no daily standups. They felt kind of useless, one guy on the team particularly hated them and pushed for us to do a sprint with no standups. So we tried it out once and kept it that way permanently, turns out our team really didn't benefit from them. When the rest of the company saw our productivity, they moved every other team over to Scrum, hired a Scrum coach, etc... And it didn't work because they were extremely strict about the "process" and any changes to the process were like arguing against the bible. They even made our team begin doing daily standups every morning again. I'm not certified or anything but the entire point of Scrum to me is that you frequently re-evaluate your situation and team and adapt to that. Everything else is just a good baseline to start with.
nlawalker 8y ago
I feel like the books and consulting came from the fact that Scrum, while it can be explained in a paragraph or two, is very hard to reconcile with the idea that what the business wants is for you to be able to guarantee that you'll be "done" (and define exactly what that means) by a particular date in the future.
siruncledrew 8y ago
"This does not sell books and consulting, so it evolved into a field of its own." Exactly. This is why it's stupid when managers get all hyped up about <present software development trend/> and decide everything needs to be shaken up based on what they learned at a seminar or heard from some consultant/"coach". For the most part, those 3 points seem like easily understandable ideas, and have been used in some form by other industries, such as manufacturing, for a long time before they were presented for software development. Replace "PM" or "Scrum Master" with "Foreman" and you can get the picture of what activities are involved with a worker managing other workers and the work that gets produced. There is so much over-complication with the current system of methodologies and nebulous acronyms that accompany it[0]. There's SAFe, Agile, Scrum, Scrum of Scums (recursive scrum??), RAD, LeSS, etc. It gets confusing and messy very quickly. Instead of focusing on doing the work, it's easy for managers to get swept up in the semantics of these frameworks and end up hurting the work by over-thinking and over-applying the principles on the workers. Scrum methodologies are guidelines that can be tweaked to fit the situation, and don't have to implemented if they don't make sense. Instead of thinking "Does this make sense?", the manager/business side tends to think "Well, it worked for X, so it must work for me!". Scrum is an editable template that should help eliminate wasted effort and mindless work, and if that's not the case then it isn't being done right. [0]https://en.wikipedia.org/wiki/Scrum_(software_development) https://en.wikipedia.org/wiki/Scrum_(software_development)
wolfi1 8y ago
>1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this. There are so many people who say, Agile or Scrum, respectively, do not need specs, the specs are just incremented with every sprint as the product itself, leading to software projects with undefined goals and overlong project time

walshemj 8y ago

You also missed the trade off's for increased speed compared to traditional wf projects. One of the problems with the Scrum model is its used for every thing - just like they used to try and do every project with WF and IS9000/BS5750

nickelcitymario 8y ago
Are you suggesting Waterfall projects are faster? I don't think you are, but that's how I read your sentence. Also I don't know what IS9000 or BS5750 are but they sound like they had amazing naming committees.
- walshemj 8y ago
  Oh bum I meant ISO9000 BS5750 is the Uk equivalent (and I worked at my first job on a joint project with the BSI on BS5750) But and its a big but some times you need the rigor a properly done waterfall process provides Air traffic control for example. You seriously don't understand the trade offs you make with "agile" vs waterfall? I have done both very successfully.
  - nickelcitymario 8y ago
    Nope, don't understand the trade offs if you're suggesting scrum is slower than waterfall. That just doesn't line up with my experience. "Results may vary," though. The issue I've had with every other project management approach is the illusion of structure. I'm not an expert on all or any approach. But my experience is that everyone wants me to be able to project, since absolute certainty, what my team can get done in 12, 24, 36 months. And I can't. No one can. It's all bull shiitake. Scrum does not solve this problem. But it's honest about it. It says: "We can't tell you what could be done in 2 years. But we can probably tell you fairly accurately what we can do in the next 2 weeks. And if you let us proceed in these honest 2 week intervals, we'll probably get way more done than if we all agreed to the collective insanity of the waterfall lie." If you've done waterfall successfully, meaning you delivered a project on time, on budget, and on scope based on your original estimates for all three, then congratulations, you're a mythical beast. I, for one, cannot do that. I've failed every time. Every team I've worked with has failed every time. I've never seen it work.
    - AllegedAlec 8y ago
      > Nope, don't understand the trade offs if you're suggesting scrum is slower than waterfall. That just doesn't line up with my experience. "Results may vary," though. The idea is that if you have a well defined problem domain and you know exactly what the software is that you have to deliver, you don't need the short cycles, and all the meetings and pokering and whatnot would just be a waste of time. You know what you need to make, so you can just continue working.
      - nickelcitymario 8y ago
        I suppose that makes sense "if you have a well defined problem domain and you know exactly what the software is that you have to deliver". I don't have a lot of experience in such areas though, and i can't help but wonder how often that's the case. If my problem domain was well defined, the problem would probably already be solved by someone and I'd use their code. Why reinvent? Am I being too simplistic?

tomtimtall 8y ago

The scrum manifesto is not overly verbose. It explains the value and concepts in a manor that does not lend itself to misrepresentation. There is definatly a lot of companies peddling hype around scrum but it has a very lean and strong core which is in no way pulling in that direction.

HolyHaddock 8y ago
What's the scrum manifesto?
- specialist 8y ago
  Paraphrasing: The Agile Methodology is to argue about The Agile Methodology. Source: Certified Scrum Master training. Three times. Still have no idea what these charlatans are talking about.
  - jmulho 8y ago
    Which is a higher distinction, Scrum Master, Web Master, or Dungeon Master?
    - s73v3r_ 8y ago
      Dungeon Master. They're the only ones that can do something as simple as place an apple on a table, and tear apart your entire team.
- zwily 8y ago
  Maybe they meant the Agile Manifesto? It’s short and hopefully not controversial: http://agilemanifesto.org http://agilemanifesto.org
  - nickelcitymario 8y ago
    But... my eyes. They burn. Thank heavens for developer tools and the ability to delete backgrounds. Jokes aside, good call linking that. Super short, super influential, super relevant to the conversation at hand.

Uberphallus 8y ago

> This does not sell books and consulting, so it evolved into a field of its own. It's funny how it turned into UML

wpietri 8y ago
UML comes out of a different culture of development, that of the Rational software crew. They had their own much more heavyweight process than the Agile folks: RUP, or the Rational Unified Process: https://en.wikipedia.org/wiki/Rational_Software#UML_and_RUP https://en.wikipedia.org/wiki/Rational_Software#UML_and_RUP There was a little overlap; in particular, Martin Fowler wrote an intentionally thin book called "UML Distilled". But the UML world was generally heavy on both up-front architecture and formal, heavyweight design process. The Agile world at the time was energetically opposed to that, thinking that the main value of UML was in having a consistent language for us to all sketch on whiteboards together.
- cabalspecter 8y ago
  Too bad people didn't bother reading the Unified Process book, which clearly specifies the use of iterative and incremental development and the creation of just enough UML diagrams to communicate and document a system design. It even argues that working software should be used to describe an architecture in the Elaboration phase rather than a 10000 words document. It can actually be considered as one of the first agile methodologies. RUP and other flavors of UP just added tools and guides aimed to facilitate the implementation of UP, but it was misunderstood that every template and section must be filled out instead of actually thinking what to use depending on the project. Unfortunately the whole thing was ultimately bastardized by the non-technical template zombies that thought software development is like building a skyscraper.
  - specialist 8y ago
    The CASE motivated tooling got in the way. My go to joke: RationalRose is like an 800lb angry gorilla sitting between you and your work. Alistair Cockburn did a great post mortem about that era. Characterizing people as non-linear, first-order components in software development [1999] http://alistair.cockburn.us/Characterizing+people+as+non-linear%2c+first-order+components+in+software+development http://alistair.cockburn.us/Characterizing+people+as+non-lin... During that time, I strongly preferred lo-fi paper prototyping for UI. And I'd scratch out UML diagrams. Worked fine for intra-team. But it just didn't fly with management. We had to make everything more formal and pretty. Oh well.

mmusson 8y ago

My experience is that a good team does a good job. A bad team doesn’t. I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice. There are no quick fixes. People can improve but it takes time, dedication, and support.

some_account 8y ago
I really dislike agile. A product owner asked me once if I get some benefit from them...and no, I don't. Thry get a lot of benefit from me sharing what I'm doing because they can then keep track of it and communicate it to other people, but I don't get any benefit personally. I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the middle of that. It just complicates everything and makes me less connected and known in the company.
- vannevar 8y ago
  I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. How exactly does agile prevent you from talking to your teammates and getting feedback from them?
  - betenoire 8y ago
    If I have a full and well-groomed backlog waiting for me at my desk, what's there to talk about? Sure, you can, but the the whole point of the PM is to take that off your shoulders and the parent is saying he doesn't want that lifted from him.
    - vannevar 8y ago
      A well-groomed backlog is not working code. So I don't get how that somehow means there's nothing to talk about. If there's an agile MVP, it's "write some working code, get feedback on it, then repeat until everyone's happy within some tolerance." Scrum is designed to increase feedback, but it's a floor, not a ceiling.

specialist 8y ago

You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management".

rch 8y ago
But you have to include 'estimates', which ruins everything (in non-trivial cases, yadda, yadda).
- specialist 8y ago
  Estimating is my Achilles heel. Always has been. I'm way too optimistic. My workaround was to do jelly bean estimating. Get guesses from everyone, then use the average. Worked surprisingly well. We did other things to meet that target date, honor that estimate, of course. But that's a longer story.
  - commandlinefan 8y ago
    > I'm too optimistic Have you ever thought much about why, though? When I was young, I was super optimistic - and I got burned by all of the surprises (including the underspecified or unstated requirements), so I started to estimate pessimistically based on experience. But then I got stuck in this loop: "How long will this take?" "Probably two weeks" "What? Why two weeks? Why not two days? We only have two days. Say it will only take two days, or tell me everything you're going to be doing on an hour-by-hour basis to justify this high estimate!" So now I've just gotten really good at figuring out how long they want me to say it will take, say it will take that long, and shrug my shoulders when it takes longer. Since everybody else is doing the same thing (as they don't have any choice), it doesn't surprise anybody.
    - specialist 8y ago
      I have thought about it. A lot. I'm told I work too slow, dive too deep. Now I'm trying to figure out how to do just 80%, "good enough". When I was a kid, I published shareware. After getting a few 3:00am wake up calls from irate customers, I said "never again". I spent 15 years designing, engineering away technical support calls. It mostly worked. Later on... When my team(s) burned a CD, we rarely had to issue patches, hot fixes. Customers loved us. I thought that was the pinnacle of human achievement. Now, I feel like I'm still fighting battles over things no one cares about any more.

dvfjsdhgfv 8y ago

> 2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line. This point is of general usefulness and applies to many areas of our lives, not just software development.

nickelcitymario 8y ago
Preach

salty_biscuits 8y ago

My mental model was that ideally it is a greedy algorithm for job shop scheduling (dev time) with dt = two weeks and a horizon as long as your backlog. The biggest and most common failure mode I saw was having a bad product owner (it can be a single point of failure, devs have a team to help them out).

nwhatt 8y ago

Great job distilling the essence of scrum into three bullet points, I wouldn't disagree with those. Here's the common pitfalls as I see them: 1. Sprints offer flexibility but unless you educate the whole company waterfall + gantt charts are what the business side wants 2. Unless you educate all members of a scrum team on what the retrospective is, and let the developers drive it, you won't be effectively improving processes 3. I've always felt conflicted about the agile "working software over comprehensive documentation value". To me it implies that documentation is easier when the product is working and/or the product might change based on feedback, so you don't want to re-write the docs. To people who don't learn scrum/agile it means "don't write documentation"

peder 8y ago
That last point is simply working software _over_ documentation, meaning that in a world of finite resources what would you rather have? A pile of requirements and technical design docs _or_ a working product? All teams need to determine the right amount of documentation that maximizes total output of working software, but agility was--in part--a response to analysis paralysis and high overhead of many software implementations of the time.
- HelloNurse 8y ago
  Not all documentation is equal. While design documentation tends to be anti-agile (but sometimes useful to avoid wasting more time on miscommunication and mistakes), end user documentation is, for all practical purposes, part of the valuable software product, as it enables end users to do what they want to do. Unfortunately, being able to neglect end user documentation makes many outfits treat it as a useless luxury, either because they are only judged on software (e.g. passing a test instead of having satisfied users) or because they don't care (e.g. many introverted hacker/artist open source maintainers). It's purely delusional agility, like driving fast by not stopping for fuel.

wpietri 8y ago

I think you are entirely right that the "sell books and consulting" is a major driver of what Agile became. I got involved in the Agile world circa 2000, but by 2010 or so my main feeling was increasing horror: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got together in 2001 to figure out what was common, and that's where the Agile Manifesto came from. Of the Agile Manifesto signatories, I think only two of them were Scrum people. These days, though, most people thing that Scrum is Agile and Agile is Scrum. I see three reasons for that. One, Scrum was the simplest, arguably the lowest common denominator; it had no technical practices. Two, it could be installed in place at existing waterfall companies doing what is effectively mini-waterfall, so there would be little disruption to the hierarchy. And three, it had a "certification" program, where a) anybody wanting a career bump could spend 2 days to get a "Master" certificate without taking any test or proving any competence, and b) any "consultant" wanting easy money could quickly become a Scrum trainer. Basically, Scrum became the Amway of software processes. If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished". And my point here isn't "Scrum bad", really. There are some great people in the Scrum world. My point is, "Business models shape outcomes, so be careful which you pick."

mlthoughts2018 8y ago
> "If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished"." I think this is a key insight, and I suspect for many people (myself included), the phrase you use when you say "Low-end Scrum" is just the only type of widespread Scrum we've ever seen practiced anywhere, ever, to the point that it makes us question whether Scrum itself is partly responsible, even in an idealized format. One of my good friends came up with the idea he called "barriers to anti-quality" to describe this. A good workflow process establishes inviolable norms that act like preventative barriers to doing things in an anti-quality way -- so that you specifically arrange the world such that trying to take a quality shortcut actually costs you more than just doing it in the quality way. We proposed trying to judge workflow and management practices based on how willing upper management was to give up control of the process in exchange for erecting barriers to anti-quality. If they wanted to force a team to pivot in some quality-destructive way, just on their whimsical preferences for reprioritizing different tasks according to vague business needs, they could not do it. Barriers to anti-quality would be like Odysseus pre-committing to be tied to the mast, so then when the Siren song comes, he cannot give in the temptation. I think a lot of the spirit of early Agile was meant to suggest something like this. Even though the method talks about being flexible and adapting when there are real business needs to adapt to, this gets bastardized when middle and upper management conflate adapting to real business priorities, and begrudgingly paying a cost in terms of quality lost due to pivoting developers, with demanding that people have to adapt to the management flavor of the month, unsubstantiated ideas about business priorities, often stemming from political power struggles, restructurings, quarterly earnings, etc. etc. What I really wish Scrum or Agile had, was a more unbreakable way to let development teams say no, and decline work or decline pivots. Basically to veto changes made to the backlog, and say that it violates an anti-quality principle for no good reason. A key failing of modern Agile / Scrum is that it doesn't create any type of stop-increasing-our-entropy-with-unsubstantiated-management-preferences notion of a barrier to anti-quality. Don't get me wrong, this is hardly a failing that us unique to Agile / Scrum. But I think when people talk about why in principle these methods fail, it's that they lack any mechanism of enforcement for this. As a result, they can be so easily politically subverted to just be a pivoting, bludgeoning tool of misguided or unexplained management choices, that almost always trade-off quality for anything else, and instead of ever looking back to understand when an under-investment in quality actually cost them, they just explain it away as some other team's fault. In a sense, Agile / Scrum (or 'Low-end Scrum' as you call it), is a tool to create managerial Dutch books. A manager gets to unilaterally disrupt on-going investment in quality without ever being held accountable when that gamble on short-term anti-quality causes losses. By the end, it makes developers very cranky that they are being jerked around with all this prescriptive and time-wasting overhead of meetings, planning, estimating, etc., only for this political anti-quality nonsense to go uncorrected anyway. If that's going to happen anyway, then what's the supposed value of all that costly Agile-specific overhead?

abritinthebay 8y ago

You’re absolutely right - and that’s the e tire core point of Scrum: to promote agile methodology (which can be summed up as you just did) However the reason there is “bs” (by which I assume you mean the process/meetings/etc) is that most teams suck at being agile. Scrum provides a more rigid framework so that a team can develop agile skills and then, when ready, move beyond scrum. Most people think Story Points or terminology like Standups comes from Scrum too - they don’t! They’re from XP. Scrum is exceedingly simple and suffers from being over complicated and dismissed by those who don’t understand it, The blog post above is no exception.

mraison 8y ago

I'm probably oversimplifying, but this looks like 3 different ways of saying "get feedback often" :)

nickelcitymario 8y ago
That's... actually pretty accurate? Dang.
- funkymike 8y ago
  So it becomes this? * Get feedback often from the business owners * Get feedback often from the developers * Get feedback often from the users
  - s73v3r_ 8y ago
    And act on that feedback.
virgilp 8y ago
I argue that's actually a misconception of many scrum practitioners. It's not really "get feedback often", it's "get feedback early". "Often" is just a bad approximation of that. The difference is most obvious with retrospectives - if you just do them often they feel like a burden. What you want is to get early opportunities to improve .... but that's not necessarily through a very frequent retrospective! You have to let things crystallize a bit, so that people can observe the effect of process changes & give accurate+reasonable feedback on it.

OnlyRepliesToBS 8y ago

Scrum intentionally takes away power from the developers and puts it in the hands of a new manager class. It makes moving paperclip more important than making them. And that's evil.

termau 8y ago

Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to meet some stupid concept isn't funny ultimately it's a waste of time in itself

monksy 8y ago
That or having to estimate work based on your sprint. This is a 130 pointed task? Oh we only go up to 8.
srtjstjsj 8y ago
Are you saying you have projects that show 0 progress of any kind after 1 month, but still succeed later? What is happening in that first month?
- lordnacho 8y ago
  Laying the foundations. Doesn't look like a house even after you've done it.
  - AnimalMuppet 8y ago
    Exactly. You need the end-to-end backbone working so that you can start adding end-to-end user-visible behaviors on it, a few at a time.
- s73v3r_ 8y ago
  Research? Experimentation? Foundations?
  - Melchizedek 8y ago
    Pffft. We're talking crud apps here. Has any innovative software ever been developed in "sprints" using "user stories" and "story points" with a "product owner" and a "scrum master"? I doubt it.

jayd16 8y ago

I'd like to add priority next to progress and problems in the second item. Being able to pull things in and out of planning is one of the biggest advantages over waterfall.

ownagefool 8y ago

I can probably agree that sprints are usually more realistic than old school waterfall (arguably it depends, like all things) but why do we feel the need to perpetually sprint? A simple kanban board seems to give all the same benefits without the constant pressure and weekly death march to meet the end of sprint commitments.

ggregoire 8y ago
Because a simple kanban doesn't have any scope/goal, it's just a disorganized TODO list. A sprint/milestone is a way to set goals for the next 2-4 weeks. At the end of the iteration, you redefine new goals according to what would bring the most values to the clients at this new moment T. If the sprint is not finished, well it's not a big deal. You move the tasks back to the backlog, or in the next sprint, or delete them if it doesn't make sense anymore. And you decrease the number of tasks in the next sprint. You shouldn't feel a constant pressure to finish sprints if the velocity of your team is taken in account correctly.
- s73v3r_ 8y ago
  "Because a simple kanban doesn't have any scope/goal, it's just a disorganized TODO list." Not everything has to be encapsulated in the TODO list. I mean, a Jira backlog is also just a TODO list.
- ownagefool 8y ago
  To be fair, the simple kanban doesn't stop you from creating a scope/goal, you need to generate your TODO list somewhere, which isn't any different from sprints, but it's less rigid when it comes to the deadlines. More to the point is, setting sprint goals is defacto pressure which many people and orginsations are poor at handling, and we can largely avoid it by not having people doing or managing the work care about end of sprints, but just that the tasks are scoped and are of a reasonble size.
nradov 8y ago
The business benefit of having a longer planning horizon is that it enables making some commitments outside the agile team. In the real world sometimes that's necessary. A sprint cadence also helps ensure that the team does real retrospectives rather than putting those off. But certainly Kanban can work as well or better in some environments. Pick what works for the circumstances.

mey 8y ago

Another observation I have had, it provides much clearer and realistic progress reports to management. You can track the normalized points per day executed by the team to see their overall velocity. You have clear check points about what has been accomplished (which is why a shipped product is critical, it removes any chance for something not to meet DOD) On the dev side, I have never attended so many meetings. Technical debt being addressed is generally against the feedback loop, unless the PO/Leads of the team make it their first priority. Grooming meetings are a mix of people who care, those who don't, and vague stories. To save time, any new story got sent to one of the devs for a sniff test before grooming, to help ask critical questions early. Typically, the request is reasonable, but may run into a contradiction of the system. I have also found that, forcing scrum (or waterfall) on a product that is running at a difference release methodology is horrible. Got a customer that needs a new thing built by a specific date? That won't fit, unless the date is flexible and customer stake holders can be deeply involved in the process. Waterfall at least forces the customer to define the project up front and allows for calling out changes to the plan and thus changes to the scope. As with all the above, this sits on how skilled your project manager/scrum master/product owner are at their jobs. Anti patterns abound.

ggregoire 8y ago

I completely agree. I don't get why people try to strictly follow the methodology (and then complain about it) instead of just taking the core of it and apply what work for them and their company. I've a SCRUM master certification and still, I follow only what's good for us. It's totally fine for me to add a task in a current sprint. If you care about finishing the sprint, you just move a task of same points back in the backlog. It's also totally fine to allow the technical lead to add his own tasks to the sprint. You can do 80/20 for instance (business/technical values). It's not going to kill your business and will make your developers happy (SCRUM is about people, not process, right?).

s73v3r_ 8y ago
Problem is, that's a recipe for management ignoring all the stuff that gives developers power and agency, and taking all the micromanaging things.
squeaky-clean 8y ago
My best experience with Scrum was with a team that was willing to completely overhaul our weekly process if we needed to. We finally settled on a structure pretty different from the general recommendations, the most significant being we had no daily standups. They felt kind of useless, one guy on the team particularly hated them and pushed for us to do a sprint with no standups. So we tried it out once and kept it that way permanently, turns out our team really didn't benefit from them. When the rest of the company saw our productivity, they moved every other team over to Scrum, hired a Scrum coach, etc... And it didn't work because they were extremely strict about the "process" and any changes to the process were like arguing against the bible. They even made our team begin doing daily standups every morning again. I'm not certified or anything but the entire point of Scrum to me is that you frequently re-evaluate your situation and team and adapt to that. Everything else is just a good baseline to start with.

nlawalker 8y ago

I feel like the books and consulting came from the fact that Scrum, while it can be explained in a paragraph or two, is very hard to reconcile with the idea that what the business wants is for you to be able to guarantee that you'll be "done" (and define exactly what that means) by a particular date in the future.

siruncledrew 8y ago

"This does not sell books and consulting, so it evolved into a field of its own." Exactly. This is why it's stupid when managers get all hyped up about <present software development trend/> and decide everything needs to be shaken up based on what they learned at a seminar or heard from some consultant/"coach". For the most part, those 3 points seem like easily understandable ideas, and have been used in some form by other industries, such as manufacturing, for a long time before they were presented for software development. Replace "PM" or "Scrum Master" with "Foreman" and you can get the picture of what activities are involved with a worker managing other workers and the work that gets produced. There is so much over-complication with the current system of methodologies and nebulous acronyms that accompany it[0]. There's SAFe, Agile, Scrum, Scrum of Scums (recursive scrum??), RAD, LeSS, etc. It gets confusing and messy very quickly. Instead of focusing on doing the work, it's easy for managers to get swept up in the semantics of these frameworks and end up hurting the work by over-thinking and over-applying the principles on the workers. Scrum methodologies are guidelines that can be tweaked to fit the situation, and don't have to implemented if they don't make sense. Instead of thinking "Does this make sense?", the manager/business side tends to think "Well, it worked for X, so it must work for me!". Scrum is an editable template that should help eliminate wasted effort and mindless work, and if that's not the case then it isn't being done right. [0]https://en.wikipedia.org/wiki/Scrum_(software_development) https://en.wikipedia.org/wiki/Scrum_(software_development)

wolfi1 8y ago

>1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this. There are so many people who say, Agile or Scrum, respectively, do not need specs, the specs are just incremented with every sprint as the product itself, leading to software projects with undefined goals and overlong project time