Wednesday, April 25, 2012

We Use Scrum

Do you? Do you really? I hate dumb ass IT managers that say, "We're Agile." or "We use Scrum."  No you're not.  Just stop!  When you visit to see how they are actually implementing Scrum, it's usually some half ass, jacked up version of Scrum.  Hey! Guess what dumb ass!? If you're not using the foundational principles of the Scrum Guide, THEN YOU'RE NOT USING SCRUM, DAMN IDIOT!

Ohhhhhh GOD don't even get me started on User Stories... Screw it, I can't help it. OK, PEOPLE. It's called a "User Story."  It is an application requirement from the user's perspective. The word "User" pertains to the "person" or "role" that is using the system or application.  Now... come closer.  Don't be shy silly, come closer.  OK, are you ready?  THE USER DOES NOT PERTAIN TO A DAMN PHYSICAL SYSTEM NOR PROCESS. YOU MULE HEADED IDIOT!

Oh yeah, for those that know how to properly scrum and write user stories, there are companies out there writing stories like this:

"As a ETL process, I need to send a message to System P, so that it knows I completed my work."


Are you fucking kidding me? NO, seriously, this is happening for real. Stupid IT Project Managers are real!  What's the reason behind writing stories like this? This is what they will tell you: Well, we need to be able to estimate tasks for building background processes or setting up the environment.


Listen, don't do that. Stop it. You're embarrassing yourself, your team, and your organization.  If someone actually convenced you into doing this, they were highly misinformed, and you need to slap them.  If you want to use User Stories, use them appropriately.  Their entire purpose is to express clear enough requirements so the development team can estimate  and implement them.  Anything needed to get the job done is estimated.  That includes the background shit.  If the team says a story will require 8 story points, then that's what it is. Scrum teams manage themselves.  You don't manage a damn thing. Your only purpose is to make sure they have what they need to get the job done and leave them alone. If a user story is too large, appropriately partition the story. Large stories are often 2 or more stories wrapped into one. Challenge the BAs (Business Analysts) to pull out those hidden stories. Everything should mostly fit into its own context.  If a story does not have enough detail, your team will let you know.

Don't get so wrapped up into thinking you need user stories to document all requirements the same way. That would be silly. User Stories are requirements for the application. They should not be used for design nor infrastructure specifications.

Let's see... What else... Oh! I almost forgot. Why would you use both Use Cases and User Stories??? Yeah, there are some stupid tards forcing their team to do this.  They write stories with the business and rewrite them as Use Cases for development. STOP IT! If you claim to be a scrum shop, then you should be using User Stories!  Duplicating work is a classic mistake only good for wasting time.  With Use Cases, your team will hate you forever.  Why do people hate Use Cases?  It is because they are boring by nature, so if the formatting is not beautiful, don't even bother.  They don't work in agile practices because they are always written, in non-story-format, by people not doing the work.  These peope don't think like development, which means they don't care like development, which means the requirements will be more confusing.  With stories, everyone gets it.  There is no rigid format.  It's just a plain read.  You will only put readers to sleep with Use Cases.  I'm not talking about the modeling aspect of Use Cases.  I'm talking about the boring written requirements.  For those that are wondering why stupid managers are allowing both requirement gathering styles, it's because their dumb asses like the User Story sentence structure, but want the details of a Use Case...


YOU DOUCHEBAG! Don't do that.  Scrum development teams are meant to implement products using the User Story format.  If you really feel the need to additionally use the Use Case format, then your stories are lacking clarity. Wowwww, really? Would that be safe?  Could I do that? Yes, POP TART!


As a teacher, I need to grade student tests, so their grade average is tracked throughout the semester.
  1. Allow teacher to select the appropriate test to begin grading students.
  2. Present teacher with a list of students.
    1. Student names should begin with last name first (e.g., Doe, John).
    2. The student list item should display a their current grade average.
      1. This view of their current grade average should be uneditable.
    3. The list item should also allow the teacher to enter the student's test grade.
  3. Allow teacher to save grades for all students in the list.
    1. Teacher should be able to save grades regardless if they have not finished grading all students.
    2. Teacher is allowed to finish grading students at a later time.
Pretend the above is a complete User Story vetted by the business. Why redo it as a Use Case? That is stupid.  A scrum development team can take it from there.  I understand there are some companies with senior management that have been brainwashed into thinking they need Use Cases for everything.  Have you ever thought about telling them "No?" I could go on and on about this topic, but you should get the gist of what I'm saying.

Thanks for reading. Keep this blog relevant by leading IT managers and actual workers here for laughs, insight, and further debates. Continue to submit your management stories to[(at)] Your identity will be kept private.


  1. Doesn’t Scrum and the agile methodology simply get back to what I as a programmer did all along, making happen what other team members wanted and making it look like we all did something? The concept is vague am i wrong, the programmer knows, the qa knows shit, the PM knows shit, and the so called master knows shit, until something’s done by say me who isn’t happy till it works anyway. So back to the cowboy days, only now I'm not solely accountable. YAHOO.. Am I missing something???

    1. Well - agile methodologies like Scrum are supposed to prevent waste. Waste in Scope, Time, and Cost. Now these methodologies have been around for the longest, yet they weren't actually mainstream. The truth is before Scrum got some hype, mainstream practices were very wasteful and a lot companies to this day still practice those wasteful techniques. Only a very small percentage were doing things the right way, which is still the case in general. It may feel like Scrum is mainstream, but it is not. The reason it is not is because of impatient people that keep forgetting how to communicate and when to communicate.

      Sales people are the absolute worst to work with and commonly forget to communicate properly with development efforts. They're too busy trying to run their damn mouth to get the sale or to make themselves look good. They will tell you they want a controlled process in place, yet complain when they have to follow the rules they asked for. We all know that Agile is a tool to do things better, yet for some reason the powers that be keep screwing it up. It's no different than handling a saw. There is a proper way to handle it or you could hurt yourself or someone else. The only people that understand this is the actual people doing the work - the engineers or programmers. They know how dangers the tool is if not handled properly. The children - the managers, do not.

      If you were implementing good unwasteful practices back in the day, good. A lot of individuals and companies were not. As far as accountability, that hasn't changed. Your team will point fingers behind your back with a grin as they walk out the manager's office including some spineless executives. In general, Agile hasn't changed the way products are built. It just introduces less wasteful methods of building those products in a way that management (the children) is 'supposed' to understand.

    2. I am an IT helpdesk technician. I create helpdesk tickets as they come, resolve issues and close ticekts with fulll explanations. At my work there is a new mangement introduced us to scrum. I don't know how to answer three questions that I answer to my Scrum Master everyday: what did I do yesterday, what will I do today, is there any roadblock? I am writing all these in the ticket system when I close any ticket. We meet every morning for 15 minutes to answer 3 questions, I think it is waste of time and duplication of work.

    3. What the hell... See, this is the problem with upper management falling asleep during their first agile conference or trying to implement something without fully taking the time to know what they're dealing with. It results in them looking like complete DUMB ASSES. If I were you, I would 'anonymously' direct them to this page.

      You are absolutely correct. It is a complete waste of time for your situation. I am truly sorry you have to deal with those idiots. They have no business trying to introduce scrum. If they're not micromanagement idiots, then what they're really asking for is frequent status updates, yet daily is too frequent for that department.

      I highly recommend influencing your coworkers to band together and bring up this issue at the next morning meeting. Either you or a coworker needs to start the conversation off with, "We've been talking and...". It needs to be expressed in an isolated manner why scrum doesn't apply to the nature of your operations. They're not going to let go of the frequent feedback, yet it needs to be expressed that they should only need weekly or bi-weekly feedback on 'interesting' issues.

      The type of things they should be asking is:

      "Did you have interesting issues?"
      if so, then for each issue they should ask, "What is the status?", "What caused it?", and if applicable, "How was it resolved?"

      The route they are currently going is a complete waste of time and effort, which is only good for adding stress to the actual workers. If possible, let me know how it goes by replying to this thread. I hope you're able to get out of that unnecessary protocol.

  2. Hey men,

    I have nothing to against the "scrum" or any models of of processing, those make things happen

    However, my comment on this is that "scrum" is not all "we" are doing, at least what's my carrier is

    In fact scrum is just one half of what "we" are doing

    First, you or some one must have the idea, I mean a valuable idea, not craps ideas

    You know what I mean, don't you ? When you acquire that valuable" idea then scrum kick in and process it in an efficient way to make it happens, or to bring that new product or new idea to the users

    Now, I can imagine those idiots you talking about;
    You know, lot of people have such idiots ideas, but guess what, those dumb asses are trained to use scrum and they use scrum correctly - efficiency just, .... just to produce garbage

    Last thing, I don't know if Bill Gate is master of scrum, but the next time I see someone talking about scrum, I rather look at his vest or his bank statement to see if he's a liar or not.

  3. The only way SCRUM makes any sense is if Development == Operations. Sometimes it does, perhaps in a global 24/7 development effort. Perhaps that's what we're headed for.

    In real 24/7 operations, we meet at the beginning of the shift to take status turnover from swingshift, at the end of the shift we meet again with the chronically miserable day shift to turn over status to them. Those are standups or sitdown and smokes, whatever. The effort is turned over to other people--a completely separate team including separate shift managers--for them to continue pressing the operations forward.

    In SCRUM we meet once a day in the middle of our shift to turn over status to ourselves, as if we couldn't remember what we did the previous 10 minutes and had to stand and look in the mirror and remind ourselves what we are doing in this place.

    Seen in this light SCRUM is laughably inefficient.

    Please direct everyone you know to this comment so that the waste can stop... or let's take off the training wheels and actually do 24/7.