10 ms·

Poor Man’s Agile: Scrum in 5 Simple Steps

90 points by scottporad 14y ago

Glyptodon 14y ago
I always get a kick out of it when I see job ads that make a big deal about applicants having experience with 'Agile' or 'Scrum' like it's some sort of hard-earned skill that's it'd be worth using to filter applicants. I can just imagine some recruiter or HR person looking at resumes: Applicant A - dozens of accepted to commits to the Linux Kernel, or leader of some 'known' open source project. Hmm. Applicant B - Scrum OMG! We have a winner!!!
- skylan_q 14y ago
  I've considered making a resume where the first half of the first page is just a paragraph filled with as many high-profile buzzwords as possible. I'm still curios to see what would happen.
  - Zombieball 14y ago
    The real trick is to put this in the footer of the resume in size 1pt font. When you print off or look @ your resume it is pretty much not visible. But, you can kick resume scanning software in the face, hi-ya!
    - mappu 14y ago
      + Set the font colour to white!
      - Zombieball 14y ago
        So simple! How did I not think of this? Cheers mate!
  - aerique 14y ago
    I did have a buzzwords section in my last resume exactly like you mentioned. Me and the people that interviewed me for the company I currently work for had a good laugh about it.
  - arethuza 14y ago
    I've seen CVs that literally have most of a page filled with buzz words and acronyms - pretty much SEO for whatever tools recruiters use to search. Unfortunately, candidates who take this kind of approach seem to list a lot of technologies they have only heard of or been in the same room as. If someone lists a technology in their CV I do rather expect them to know what it is and what it is generally used for and good and bad points.
- adrianhoward 14y ago
  For me Scrum wouldn't be a "skill" that I would be looking for. I have... issues... with Scrum (not the process itself - which is a damn fine process improvement and project management framework - but the industry that has sprung up around it). However - your comparison is pretty much a straw man. I'm not looking for good Scrum / Agile experience instead of code experience. I'm looking for code experience and good agile team experience. Because - over the last ten years - the teams I've seen using agile approaches have been darn effective. When I'm helping build a technical team you need great coders and you need great team players working in a way that makes everybody happy and effective. Ideally you want to recruit folk who are already great coders and are already used to working in effective team environments. If you think either of those is a natural skill or simple then you're mistaken or very lucky. I can mentor folk up on both sides - sometimes it's actually easier to turn a good coder into a great one than it is to turn an asocial fuckwit prima-donna coder into an efffective team player ;-)
submersible 14y ago
This doesn't say anything about grooming your product backlog, which to me is one of the major benefits of scrum: 6. Once a week, everybody gets together for a few hours and roughly plans out the features that the product is going to have. The features are compiled into a list with the ones you're going to do first at the top, in the most detail. Without having the feature set already groomed, those step 2 planning meetings are going to be brutal.
Kuytu 14y ago
I have always considered scrum to be like a beginners workout routine. It's never best for you, but it's better than doing what you feel like is good for you. Because if you've been lying on the sofa for the last ten years, you don't know what's good for you. Chances are that you don't know what suites you, that's why you are looking into scrum in the first place. First you do it strictly by the book and in time you will learn what works for you and what doesn't. Then you can start customizing become mature agile team/organization. OP has probably achieved this, but I think it can be harmful to suggest "pro" techniques to someone just starting out :)
- minimax 14y ago
  To borrow your analogy, to me Scrum is like the guy who reads some stuff about working out on the Internet and proceeds to try and correct everyone in the gym on their form.
- samd 14y ago
  That's a great analogy. I think you need a high-functioning team that really understands the Agile manifesto and its principles to roll-your-own solution. If you are going to roll-your-own solution, start with retro and build from there. Retro is the most important part of the process. There's a reason it's the only explicit activity mentioned in the manifesto. As long as you keep reflecting on past performance and continually try to improve you'll probably end up with a good process.
  - taligent 14y ago
    Retro is one of the worst parts about agile IMHO. It encourages everyone to ignore/bottle up issues until the magical retro day where everyone can spend a couple of hours venting their frustration. At which point nothing gets done and the process repeats. Project issues should be resolved immediately, directly with the people responsible and with actionable outcomes. Not during a glorified weekly/fortnightly 'meeting'.
    - adrianhoward 14y ago
minimax 14y ago
The only thing I appreciate about my experience with Scrum was that I could use the hours long "sprint planning" meetings to reflect on my long term goal of never having to sit through another hours long "sprint planning" meeting ever again.
- vailripper 14y ago
  My experience has been that, while planning meetings are quite painful, they're the most valuable part of Agile. Forcing yourself to sit down every week and decide what really matters is extremely valuable and keeps teams focused.
  - vbl 14y ago
    Short of actually making (good, working) stuff, informed and merciless prioritization is the most important thing you can do in producing software.
    - thirdtruck 14y ago
      And for life in general.
  - darkxanthos 14y ago
    Where in the Agile manifesto does it say "Thou shalt have planning meetings."?
- adrianhoward 14y ago
  And just by the fact that the sprint planning meeting is taking hours I can tell that they're not doing Scrum effectively ;-)
  - ryanbrunner 14y ago
    In what way? I think multiple hours long sprint planning meetings can be necessary in some cases, if the alternative is even more meetings spread out throughout the sprint. It's definitely an art form finding the right balance of how much to plan at the start and how much to leave to a conversation, but overcorrecting away from planning meetings can very easily cause frustrations and disagreements about what a story "really meant".
jdlshore 14y ago
There's more to Agile than Scrum. And there's more to Scrum than Scott's saying. Diana Larsen and I sat down last year and wrote down all the different ways we saw people doing Agile, what worked, what didn't, and why so few teams were getting the promised benefits of what the agile movement promised, lo, those many years ago. The nice version is here: http://www.agilefluency.com http://www.agilefluency.com The nasty (but much shorter) version is here: People care more about slapping the "Agile" label on their door than they care about doing the hard work of changing their organization's work habits. Change is hard. Doing Agile well takes change. It's easier to get a certification and call it a day. (Not bitter. Nooooo... not bitter at all. But so very tired of the bullshit.)
- mikestew 14y ago
  An upvote to you for probably saying what I was trying to in a more succinct manner. Sprinkle a little "agile" on top and call it a day, rather than rework the way things are done.
- HNLogInShit 14y ago
  Here's a recap: Scrum is bullshit. Xcode is the primary impediment to any project. Questions? File a Radar.
- adrianhoward 14y ago
  There's more to Agile than Scrum. And there's more to Scrum than Scott's saying. Ah good - somebody else go there first ;-) To James' link I'd add reading the Agile Manifesto values (http://agilemanifesto.org/ http://agilemanifesto.org/) and principles (http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html - everybody forgets the principles). If folk want to learn a bit more about Scrum the Scrum Guide is a nice summary and not that much longer than Scott's mild oversimplification (http://www.scrum.org/Scrum-Guides http://www.scrum.org/Scrum-Guides). (And since he's too polite to pimp it himself - James' book co-authored with Shane Warden is one of the ones I recommend to folk wanting to learn about agile http://www.jamesshore.com/Agile-Book/ http://www.jamesshore.com/Agile-Book/ - well worth a read if you're interested).
- Glide 14y ago
mikestew 14y ago
478 pages, huh? A book on Scrum of that size seems to reflect my observation of some organizations that have implemented Scrum: little extras will be added along the way until it's no longer "agile" and just as unwieldy as the process it replaced. For an organization, that can be fine. Maybe Scrum is too simplistic, maybe it's missing a few pieces vital to your organization. Experiment, season to taste. But I believe that there often isn't enough thought put into how badly that seasoning is needed. Rather, someone along the chain says "but we don't have that thing from the old way", whether that old thing is vital or was nothing but a procedure weight around the neck of the team. As for a 478 page book, someone must have worked really hard to come up with enough fluff, diagrams, and humorous anecdotes to fill that many pages on something that's supposed to be "agile".
- brazzy 14y ago
  Someone was simply connecting the two dots: 1) Scrum has been getting buzzword traction, so there is demand for books about it. 2) A book has to have a couple of hundred pages to justify the price tag.
samd 14y ago
Don't read this article either. Instead read the actual Agile manifesto. It's really short, but very insightful. After you've read it stop and think (we're programmers, we're supposed to be good at that) about how your current process, or a potential process matches the principles laid out. http://agilemanifesto.org/ http://agilemanifesto.org/ http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html
- brazzy 14y ago
  The problem is that the manifesto doesn't give you a concrete way of doing things; Scrum does, and it can be really as simple as this article says. Basically, the article is a backlash to things like http://programming-motherfucker.com/ http://programming-motherfucker.com/ , which is a backlash to people doing Scrum, XP, etc. so wrong that it seems no better than the beaurocratic monstrosities that the agile manifesto was a backlash to.
  - samd 14y ago
    Alright, read the manifesto first, understand it, then go read about Scrum.
cpeterso 14y ago
If Scrum is so agile, why do projects using Scrum spend so much time talking about Scrum?
- taligent 14y ago
  One reason is to shift blame. I've seen countless developers use the "if only we were truly agile the project would be fine" excuse. Another reason is ego/power. Developers can use the "we know agile better than the project managers" mantra to drive change within a project that they couldn't before. At the end of the day successful projects happen because of good communication, clear requirements and hard work. No amounts of tricks can save you if you don't have all three.
  - CodeMage 14y ago
    Funny, what you call out here is quite similar to what I've witnessed, too, only I have a different point of view. For example, "we know agile better than the project managers" often comes from people who find themselves in yet another cargo-cult agile environment with a Scrum master who not only doesn't have a clue about Scrum, but is also pretty much convinced that it's a wrong idea and therefore doesn't give a shit about what he's doing and whether the latest process-related brainwave coming from above is one step forward or -- more likely -- two step backwards. In such circumstances, you really do know more about agile than managers when you 1) say that it defeats the purpose of Scrum to have people filling out how many hours they've spent working on an item alongside how many they have left, 2) point out the inefficiency and banality of hour-long discussions on whether we move the user story from one sprint into the next one or create a copy of it, 3) complain about having 1-2 hours of sprint planning, a 1-hour mid-sprint review meeting and 1-2 hours of sprint review on top of 30-minute daily meetings in a 2-week sprint and 4) wonder why nobody seems to have read the bloody agile manifesto itself. So when you hear "if only we were truly agile" coming from a dev, maybe it's not an incompetent egomaniac on a power trip looking to shift the blame for the things that don't work. Maybe it's someone like me who is sick to the core of managers who can't hear you because their head is up their ass -- yet somehow there's always enough place in their for yet another "Agile" consultant's shaft to get cozy with. Yes, I'm bitter. That doesn't make me wrong.
happywolf 14y ago
No techniques or technology will save a project if there is no mandate from the management. In other words, if the requirements are vague, inconsistent, or down right incorrect but management isn't doing anything about it. No amount of scrum can save you. Yeah I am right into this kind of shit now. Ask me about it.
HNLogInShit 14y ago
You want to piss off your team and become a joke? Implement SCRUM.
chenster 14y ago
He didn't explain why it is call Scrum!!
- mrmincent 14y ago
  because in the game of rugby (where the term scrum comes from), the part where the game is won or lost is called the breakdown, which is a terrible name for a methodology you're trying to sell. So they call it the scrum, which although is useful and looks pretty cool, isn't really as important as other parts of the game.
  - gee_totes 14y ago
    I always thought it was called Scrum because when doing Agile development, typically everyone has a 5 min stand up meeting some time during the day. Normally when people are standing around, then tend to arrange in a circle, and since you have a group of people in a circle moving a project (ball) towards it's goal (down the field), it resembles a scrum in rugby. Of course, this definition was imbued on me many many moons ago before the consultants hijacked the language.
tomelders 14y ago
I can't take this Agile crap any longer. It's lunacy. It has all the hall marks of a religion. A lot of literature, a lot of disciples, hoards of money grabbing snake oil selling evangelists, and no evidence at all that it works. In fact, as far as I can see, there's more evidence that it doesn't work. And the next person that says to me "derp derp derp, well it's better than waterfall herp derp" can go fly a kite. If you think we live in a world where there's only two ways to manage/build software, then you're a fool and have no business being in this business. Either start applying critical thinking or go sell crazy some place else. Maybe there is a perfect project out there, somewhere, and they're doing Agile right, and it makes the product better, and everyone on the team is happier and more productive. But I've never seen a project like that. In five Agile projects I've had the misfortune of working on or alongside, All I've seen is stakeholders making implementation decisions in ivory towers, developers being told to not implement that "delete" function because it's out of scope (it's out of scope because the designer and UX people forgot to put it in, but fuck it, we'll pretend you're right and it's meant to be like that), and teams pretending stuff works and everything is ok when in actual fact, it doesn't, and it isn't and if people could just stop looking a Jira and start looking at the code then maybe we could start to fix this hunking pile of crap and actually start being proud of our work. And before anyone weighs in with "Well those project clearly weren't doing Agile right", please, save your breath. Every project has been infested with people who have stacks of books on the subject. They love it, they suck it all up, they obsess over the minutiae of how to implement scrum, retrospectives, and sprints. They can talk of nothing else at work, at home, or in the pub. If they can't do it right, who can? And herein lies the point, there is no way to do agile right. What there is, is good project managers and bad project managers. There are good devs and bad devs. Good designers, bad designers. The good people will make good things in spite of having Agile forced upon them. Then the agile non-thinkers will jump on the bandwagon and lap up the good peoples success as if it were their own. Then someone will write a blogpost about how Agile made it all possible and it will all be lies piled on top of lies. Do I sound angry? Good, because I am. Agile is a con. People like agile because it absolves them of the responsibility to think and do their job. It makes my job a misery and it sucks money out of a clients pockets and to my mind is no better than theft. If you think I'm wrong, prove it. And I mean PROVE AGILE WORKS, WITH EVIDENCE or shut up. Extraordinary claims require extraordinary evidence. I didn't come into your life and tell you how to suck eggs, but if you're going to come into mine and do that, you'd better have data to back you up.
Proleps 14y ago
Lots of people use this thread to spill their hate about Agile. But I actually think this is a good article. A lot of small companies have no process whatsoever. Most don't even have a list of requirements or bugs. I think this article gives you a good start with creating a decent development process for your company.
alexkus 14y ago
Trying to implement Scrum in a $VBC is even more fun, especially when senior management are so entrenched with waterfall based processes where there is much more information (almost) set in stone upfront/earlier. "What are you going to commit to delivering in this project?" "points This stuff is pretty much guaranteed, unless you change your minds on the priorities." "But that's only about 40% of the dev time we've got until our planned release date[1]." "Yes, that's all we can commit to definitely doing. They'll be more, don't worry, but what depends on what the priorities become at a later date and where we get led with customer feedback[2]." "But I can't go to my management team with this, they won't understand why we're not committing to much!" "They should understand, they told us to do Agile in the first place[3]" Project starts... "Can I get copies of the detailed design docs?" "We don't have any detailed design docs, you can have a look at the design docs we've got but just remember that they're 'Barely Good Enough'." "But I can't go to...[4]" 1. Ok, we can handle an upfront release date. 2. Ha, like we'll be able to get any of that. 3. With little or no actual understanding of how it works. But it's a nice buzzword to spray around with customers... 4. etc, etc, etc
Rabei 14y ago
THe issue of agile is people do not understand how to properly apply it. If you do a Product you want fixed budget, fixed releases and flexible scope, scrum/agile is the best fit. If you do Projects you want fixed release and fixed scope and flexible budget. Use waterfall and don't close the budget until the end of the design phase.
pikewood 14y ago
There is one very important step that the author missed: ensure you have customer buy-in. This is also the hardest step to do, but I feel like a lot of scrum-talk glosses over this. A medium bug appears in your production environment. Will your customer really wait till the next sprint to get it prioritized, then fixed? Or, your customers expect functionality, time, and dollar estimates in a proposal before they start a project. Sure, some teams think they can do scrum under the covers, and give them what they really want, but in the end do you have the right language in your contract to address changes made during the project? Will the customer really care that feature X didn't make it because it wasn't prioritized high enough at the last grooming? Until you get this buy-in from the people paying you, there is a huge conflict about how you want to do things vs. what the customer expects. And generally, they'll win until you convince them. But why should they change? They're happy with how things are going the way it is.
darkxanthos 14y ago
Seeing comments where Agile is called out as a process comparable to Scrum and Waterfall is frustrating. Agile is a set of principles and as such, it doesn't preclude a Waterfall process or any process for that matter. In that way, Agile is purposely vague and ambiguous and it's hard to really say Agile doesn't work for you. What you can say is those aren't your values. There's nothing needed to be proven that way, it's just a disagreement based on what you value.
mcgwiz 14y ago
This misses the point. Scrum is not merely a prescription of sequential high-level actions. Fundamentally, scrum is a recognition of certain risk-bearing concerns in projects, and the assignment of those separate concerns to specific roles. The division of concerns sets up a structural tension that drives attention to risks and which are necessarily resolved through open negotiation. To truly reap the benefits of Scrum is to appreciate the value of this tension. All the steps listed fall from this basic understanding.
lucisferre 14y ago
I'm confused that this post received so much attention and this (https://news.ycombinator.com/item?id=5390897 https://news.ycombinator.com/item?id=5390897) received almost none. Wade's lightweight process didn't add the bullshit layers of Scrum's painful "retrospectives" and standups. Scott's approach may be "Scrum lite" but it still isn't helpful or productive. Standups are painful and often about as effective as asking your kids how their day at school went. Retrospectives are practically like water-boarding your entire team once a week. Didn't get everything you planned done this week? Welcome to the real world, get used to it and figure out how to get the most important things delivered instead. Teams need ownership and accountability not babysitting and handholding.
ksh 14y ago
tomelders, i can agree with you but the main reason for scrum (waterFAIL or whatever metodology you take) will fail is the inital bullshit in software development, instead of hiring competent and motivated people you rather pay less and hire larger crew of idiots or even worse, out of mgmt own, complete incompetency, hire headcount. The agile methodologies imho are comming from someone that had luck and instead of winning 7 on national lottery hired competent and motivated people by sheer luck and due to his own self centered line of thought (egocentrism, etc), he thought his "inovative" way, brought in the success and started to market it. The mgmt is still far too stupid to realize that you cant streamline software development, you cant get revolutionary ideas on requirement and you cant JUSTIFY THEIR POSITIONS! (oh and btw, my cv consist of 18+ years of c/c++ software developent from world largest IT companies to startups and i think i have seen all the crap the white collars can offer, they just cant comprehend that the creativitye cant be streamlined and are always searching for a silver bullet to pay less and get the breakthrough technology for peanuts)
deleted 14y ago
[deleted]

90 points by scottporad 14y ago

I always get a kick out of it when I see job ads that make a big deal about applicants having experience with 'Agile' or 'Scrum' like it's some sort of hard-earned skill that's it'd be worth using to filter applicants. I can just imagine some recruiter or HR person looking at resumes: Applicant A - dozens of accepted to commits to the Linux Kernel, or leader of some 'known' open source project. Hmm. Applicant B - Scrum OMG! We have a winner!!!

skylan_q 14y ago
I've considered making a resume where the first half of the first page is just a paragraph filled with as many high-profile buzzwords as possible. I'm still curios to see what would happen.
- Zombieball 14y ago
  The real trick is to put this in the footer of the resume in size 1pt font. When you print off or look @ your resume it is pretty much not visible. But, you can kick resume scanning software in the face, hi-ya!
  - mappu 14y ago
    + Set the font colour to white!
    - Zombieball 14y ago
      So simple! How did I not think of this? Cheers mate!
- aerique 14y ago
  I did have a buzzwords section in my last resume exactly like you mentioned. Me and the people that interviewed me for the company I currently work for had a good laugh about it.
- arethuza 14y ago
  I've seen CVs that literally have most of a page filled with buzz words and acronyms - pretty much SEO for whatever tools recruiters use to search. Unfortunately, candidates who take this kind of approach seem to list a lot of technologies they have only heard of or been in the same room as. If someone lists a technology in their CV I do rather expect them to know what it is and what it is generally used for and good and bad points.
adrianhoward 14y ago
For me Scrum wouldn't be a "skill" that I would be looking for. I have... issues... with Scrum (not the process itself - which is a damn fine process improvement and project management framework - but the industry that has sprung up around it). However - your comparison is pretty much a straw man. I'm not looking for good Scrum / Agile experience instead of code experience. I'm looking for code experience and good agile team experience. Because - over the last ten years - the teams I've seen using agile approaches have been darn effective. When I'm helping build a technical team you need great coders and you need great team players working in a way that makes everybody happy and effective. Ideally you want to recruit folk who are already great coders and are already used to working in effective team environments. If you think either of those is a natural skill or simple then you're mistaken or very lucky. I can mentor folk up on both sides - sometimes it's actually easier to turn a good coder into a great one than it is to turn an asocial fuckwit prima-donna coder into an efffective team player ;-)

submersible 14y ago

This doesn't say anything about grooming your product backlog, which to me is one of the major benefits of scrum: 6. Once a week, everybody gets together for a few hours and roughly plans out the features that the product is going to have. The features are compiled into a list with the ones you're going to do first at the top, in the most detail. Without having the feature set already groomed, those step 2 planning meetings are going to be brutal.

Kuytu 14y ago

I have always considered scrum to be like a beginners workout routine. It's never best for you, but it's better than doing what you feel like is good for you. Because if you've been lying on the sofa for the last ten years, you don't know what's good for you. Chances are that you don't know what suites you, that's why you are looking into scrum in the first place. First you do it strictly by the book and in time you will learn what works for you and what doesn't. Then you can start customizing become mature agile team/organization. OP has probably achieved this, but I think it can be harmful to suggest "pro" techniques to someone just starting out :)

minimax 14y ago
To borrow your analogy, to me Scrum is like the guy who reads some stuff about working out on the Internet and proceeds to try and correct everyone in the gym on their form.
samd 14y ago
That's a great analogy. I think you need a high-functioning team that really understands the Agile manifesto and its principles to roll-your-own solution. If you are going to roll-your-own solution, start with retro and build from there. Retro is the most important part of the process. There's a reason it's the only explicit activity mentioned in the manifesto. As long as you keep reflecting on past performance and continually try to improve you'll probably end up with a good process.
- taligent 14y ago
  Retro is one of the worst parts about agile IMHO. It encourages everyone to ignore/bottle up issues until the magical retro day where everyone can spend a couple of hours venting their frustration. At which point nothing gets done and the process repeats. Project issues should be resolved immediately, directly with the people responsible and with actionable outcomes. Not during a glorified weekly/fortnightly 'meeting'.
  - adrianhoward 14y ago

minimax 14y ago

The only thing I appreciate about my experience with Scrum was that I could use the hours long "sprint planning" meetings to reflect on my long term goal of never having to sit through another hours long "sprint planning" meeting ever again.

vailripper 14y ago
My experience has been that, while planning meetings are quite painful, they're the most valuable part of Agile. Forcing yourself to sit down every week and decide what really matters is extremely valuable and keeps teams focused.
- vbl 14y ago
  Short of actually making (good, working) stuff, informed and merciless prioritization is the most important thing you can do in producing software.
  - thirdtruck 14y ago
    And for life in general.
- darkxanthos 14y ago
  Where in the Agile manifesto does it say "Thou shalt have planning meetings."?
adrianhoward 14y ago
And just by the fact that the sprint planning meeting is taking hours I can tell that they're not doing Scrum effectively ;-)
- ryanbrunner 14y ago
  In what way? I think multiple hours long sprint planning meetings can be necessary in some cases, if the alternative is even more meetings spread out throughout the sprint. It's definitely an art form finding the right balance of how much to plan at the start and how much to leave to a conversation, but overcorrecting away from planning meetings can very easily cause frustrations and disagreements about what a story "really meant".

jdlshore 14y ago

There's more to Agile than Scrum. And there's more to Scrum than Scott's saying. Diana Larsen and I sat down last year and wrote down all the different ways we saw people doing Agile, what worked, what didn't, and why so few teams were getting the promised benefits of what the agile movement promised, lo, those many years ago. The nice version is here: http://www.agilefluency.com http://www.agilefluency.com The nasty (but much shorter) version is here: People care more about slapping the "Agile" label on their door than they care about doing the hard work of changing their organization's work habits. Change is hard. Doing Agile well takes change. It's easier to get a certification and call it a day. (Not bitter. Nooooo... not bitter at all. But so very tired of the bullshit.)

mikestew 14y ago
An upvote to you for probably saying what I was trying to in a more succinct manner. Sprinkle a little "agile" on top and call it a day, rather than rework the way things are done.
HNLogInShit 14y ago
Here's a recap: Scrum is bullshit. Xcode is the primary impediment to any project. Questions? File a Radar.
adrianhoward 14y ago
There's more to Agile than Scrum. And there's more to Scrum than Scott's saying. Ah good - somebody else go there first ;-) To James' link I'd add reading the Agile Manifesto values (http://agilemanifesto.org/ http://agilemanifesto.org/) and principles (http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html - everybody forgets the principles). If folk want to learn a bit more about Scrum the Scrum Guide is a nice summary and not that much longer than Scott's mild oversimplification (http://www.scrum.org/Scrum-Guides http://www.scrum.org/Scrum-Guides). (And since he's too polite to pimp it himself - James' book co-authored with Shane Warden is one of the ones I recommend to folk wanting to learn about agile http://www.jamesshore.com/Agile-Book/ http://www.jamesshore.com/Agile-Book/ - well worth a read if you're interested).
Glide 14y ago

mikestew 14y ago

478 pages, huh? A book on Scrum of that size seems to reflect my observation of some organizations that have implemented Scrum: little extras will be added along the way until it's no longer "agile" and just as unwieldy as the process it replaced. For an organization, that can be fine. Maybe Scrum is too simplistic, maybe it's missing a few pieces vital to your organization. Experiment, season to taste. But I believe that there often isn't enough thought put into how badly that seasoning is needed. Rather, someone along the chain says "but we don't have that thing from the old way", whether that old thing is vital or was nothing but a procedure weight around the neck of the team. As for a 478 page book, someone must have worked really hard to come up with enough fluff, diagrams, and humorous anecdotes to fill that many pages on something that's supposed to be "agile".

brazzy 14y ago
Someone was simply connecting the two dots: 1) Scrum has been getting buzzword traction, so there is demand for books about it. 2) A book has to have a couple of hundred pages to justify the price tag.

samd 14y ago

Don't read this article either. Instead read the actual Agile manifesto. It's really short, but very insightful. After you've read it stop and think (we're programmers, we're supposed to be good at that) about how your current process, or a potential process matches the principles laid out. http://agilemanifesto.org/ http://agilemanifesto.org/ http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html

brazzy 14y ago
The problem is that the manifesto doesn't give you a concrete way of doing things; Scrum does, and it can be really as simple as this article says. Basically, the article is a backlash to things like http://programming-motherfucker.com/ http://programming-motherfucker.com/ , which is a backlash to people doing Scrum, XP, etc. so wrong that it seems no better than the beaurocratic monstrosities that the agile manifesto was a backlash to.
- samd 14y ago
  Alright, read the manifesto first, understand it, then go read about Scrum.

cpeterso 14y ago

If Scrum is so agile, why do projects using Scrum spend so much time talking about Scrum?

taligent 14y ago
One reason is to shift blame. I've seen countless developers use the "if only we were truly agile the project would be fine" excuse. Another reason is ego/power. Developers can use the "we know agile better than the project managers" mantra to drive change within a project that they couldn't before. At the end of the day successful projects happen because of good communication, clear requirements and hard work. No amounts of tricks can save you if you don't have all three.
- CodeMage 14y ago
  Funny, what you call out here is quite similar to what I've witnessed, too, only I have a different point of view. For example, "we know agile better than the project managers" often comes from people who find themselves in yet another cargo-cult agile environment with a Scrum master who not only doesn't have a clue about Scrum, but is also pretty much convinced that it's a wrong idea and therefore doesn't give a shit about what he's doing and whether the latest process-related brainwave coming from above is one step forward or -- more likely -- two step backwards. In such circumstances, you really do know more about agile than managers when you 1) say that it defeats the purpose of Scrum to have people filling out how many hours they've spent working on an item alongside how many they have left, 2) point out the inefficiency and banality of hour-long discussions on whether we move the user story from one sprint into the next one or create a copy of it, 3) complain about having 1-2 hours of sprint planning, a 1-hour mid-sprint review meeting and 1-2 hours of sprint review on top of 30-minute daily meetings in a 2-week sprint and 4) wonder why nobody seems to have read the bloody agile manifesto itself. So when you hear "if only we were truly agile" coming from a dev, maybe it's not an incompetent egomaniac on a power trip looking to shift the blame for the things that don't work. Maybe it's someone like me who is sick to the core of managers who can't hear you because their head is up their ass -- yet somehow there's always enough place in their for yet another "Agile" consultant's shaft to get cozy with. Yes, I'm bitter. That doesn't make me wrong.

happywolf 14y ago

No techniques or technology will save a project if there is no mandate from the management. In other words, if the requirements are vague, inconsistent, or down right incorrect but management isn't doing anything about it. No amount of scrum can save you. Yeah I am right into this kind of shit now. Ask me about it.

HNLogInShit 14y ago

You want to piss off your team and become a joke? Implement SCRUM.

chenster 14y ago

He didn't explain why it is call Scrum!!

mrmincent 14y ago
because in the game of rugby (where the term scrum comes from), the part where the game is won or lost is called the breakdown, which is a terrible name for a methodology you're trying to sell. So they call it the scrum, which although is useful and looks pretty cool, isn't really as important as other parts of the game.
- gee_totes 14y ago
  I always thought it was called Scrum because when doing Agile development, typically everyone has a 5 min stand up meeting some time during the day. Normally when people are standing around, then tend to arrange in a circle, and since you have a group of people in a circle moving a project (ball) towards it's goal (down the field), it resembles a scrum in rugby. Of course, this definition was imbued on me many many moons ago before the consultants hijacked the language.

tomelders 14y ago

I can't take this Agile crap any longer. It's lunacy. It has all the hall marks of a religion. A lot of literature, a lot of disciples, hoards of money grabbing snake oil selling evangelists, and no evidence at all that it works. In fact, as far as I can see, there's more evidence that it doesn't work. And the next person that says to me "derp derp derp, well it's better than waterfall herp derp" can go fly a kite. If you think we live in a world where there's only two ways to manage/build software, then you're a fool and have no business being in this business. Either start applying critical thinking or go sell crazy some place else. Maybe there is a perfect project out there, somewhere, and they're doing Agile right, and it makes the product better, and everyone on the team is happier and more productive. But I've never seen a project like that. In five Agile projects I've had the misfortune of working on or alongside, All I've seen is stakeholders making implementation decisions in ivory towers, developers being told to not implement that "delete" function because it's out of scope (it's out of scope because the designer and UX people forgot to put it in, but fuck it, we'll pretend you're right and it's meant to be like that), and teams pretending stuff works and everything is ok when in actual fact, it doesn't, and it isn't and if people could just stop looking a Jira and start looking at the code then maybe we could start to fix this hunking pile of crap and actually start being proud of our work. And before anyone weighs in with "Well those project clearly weren't doing Agile right", please, save your breath. Every project has been infested with people who have stacks of books on the subject. They love it, they suck it all up, they obsess over the minutiae of how to implement scrum, retrospectives, and sprints. They can talk of nothing else at work, at home, or in the pub. If they can't do it right, who can? And herein lies the point, there is no way to do agile right. What there is, is good project managers and bad project managers. There are good devs and bad devs. Good designers, bad designers. The good people will make good things in spite of having Agile forced upon them. Then the agile non-thinkers will jump on the bandwagon and lap up the good peoples success as if it were their own. Then someone will write a blogpost about how Agile made it all possible and it will all be lies piled on top of lies. Do I sound angry? Good, because I am. Agile is a con. People like agile because it absolves them of the responsibility to think and do their job. It makes my job a misery and it sucks money out of a clients pockets and to my mind is no better than theft. If you think I'm wrong, prove it. And I mean PROVE AGILE WORKS, WITH EVIDENCE or shut up. Extraordinary claims require extraordinary evidence. I didn't come into your life and tell you how to suck eggs, but if you're going to come into mine and do that, you'd better have data to back you up.

Proleps 14y ago

Lots of people use this thread to spill their hate about Agile. But I actually think this is a good article. A lot of small companies have no process whatsoever. Most don't even have a list of requirements or bugs. I think this article gives you a good start with creating a decent development process for your company.

alexkus 14y ago

Trying to implement Scrum in a $VBC is even more fun, especially when senior management are so entrenched with waterfall based processes where there is much more information (almost) set in stone upfront/earlier. "What are you going to commit to delivering in this project?" "points This stuff is pretty much guaranteed, unless you change your minds on the priorities." "But that's only about 40% of the dev time we've got until our planned release date[1]." "Yes, that's all we can commit to definitely doing. They'll be more, don't worry, but what depends on what the priorities become at a later date and where we get led with customer feedback[2]." "But I can't go to my management team with this, they won't understand why we're not committing to much!" "They should understand, they told us to do Agile in the first place[3]" Project starts... "Can I get copies of the detailed design docs?" "We don't have any detailed design docs, you can have a look at the design docs we've got but just remember that they're 'Barely Good Enough'." "But I can't go to...[4]" 1. Ok, we can handle an upfront release date. 2. Ha, like we'll be able to get any of that. 3. With little or no actual understanding of how it works. But it's a nice buzzword to spray around with customers... 4. etc, etc, etc

Rabei 14y ago

THe issue of agile is people do not understand how to properly apply it. If you do a Product you want fixed budget, fixed releases and flexible scope, scrum/agile is the best fit. If you do Projects you want fixed release and fixed scope and flexible budget. Use waterfall and don't close the budget until the end of the design phase.

pikewood 14y ago

There is one very important step that the author missed: ensure you have customer buy-in. This is also the hardest step to do, but I feel like a lot of scrum-talk glosses over this. A medium bug appears in your production environment. Will your customer really wait till the next sprint to get it prioritized, then fixed? Or, your customers expect functionality, time, and dollar estimates in a proposal before they start a project. Sure, some teams think they can do scrum under the covers, and give them what they really want, but in the end do you have the right language in your contract to address changes made during the project? Will the customer really care that feature X didn't make it because it wasn't prioritized high enough at the last grooming? Until you get this buy-in from the people paying you, there is a huge conflict about how you want to do things vs. what the customer expects. And generally, they'll win until you convince them. But why should they change? They're happy with how things are going the way it is.

darkxanthos 14y ago

Seeing comments where Agile is called out as a process comparable to Scrum and Waterfall is frustrating. Agile is a set of principles and as such, it doesn't preclude a Waterfall process or any process for that matter. In that way, Agile is purposely vague and ambiguous and it's hard to really say Agile doesn't work for you. What you can say is those aren't your values. There's nothing needed to be proven that way, it's just a disagreement based on what you value.

mcgwiz 14y ago

This misses the point. Scrum is not merely a prescription of sequential high-level actions. Fundamentally, scrum is a recognition of certain risk-bearing concerns in projects, and the assignment of those separate concerns to specific roles. The division of concerns sets up a structural tension that drives attention to risks and which are necessarily resolved through open negotiation. To truly reap the benefits of Scrum is to appreciate the value of this tension. All the steps listed fall from this basic understanding.

lucisferre 14y ago

I'm confused that this post received so much attention and this (https://news.ycombinator.com/item?id=5390897 https://news.ycombinator.com/item?id=5390897) received almost none. Wade's lightweight process didn't add the bullshit layers of Scrum's painful "retrospectives" and standups. Scott's approach may be "Scrum lite" but it still isn't helpful or productive. Standups are painful and often about as effective as asking your kids how their day at school went. Retrospectives are practically like water-boarding your entire team once a week. Didn't get everything you planned done this week? Welcome to the real world, get used to it and figure out how to get the most important things delivered instead. Teams need ownership and accountability not babysitting and handholding.

ksh 14y ago

tomelders, i can agree with you but the main reason for scrum (waterFAIL or whatever metodology you take) will fail is the inital bullshit in software development, instead of hiring competent and motivated people you rather pay less and hire larger crew of idiots or even worse, out of mgmt own, complete incompetency, hire headcount. The agile methodologies imho are comming from someone that had luck and instead of winning 7 on national lottery hired competent and motivated people by sheer luck and due to his own self centered line of thought (egocentrism, etc), he thought his "inovative" way, brought in the success and started to market it. The mgmt is still far too stupid to realize that you cant streamline software development, you cant get revolutionary ideas on requirement and you cant JUSTIFY THEIR POSITIONS! (oh and btw, my cv consist of 18+ years of c/c++ software developent from world largest IT companies to startups and i think i have seen all the crap the white collars can offer, they just cant comprehend that the creativitye cant be streamlined and are always searching for a silver bullet to pay less and get the breakthrough technology for peanuts)

deleted 14y ago

[deleted]