Home » Scrum » You Aren’t Doing Scrum If…

You Aren’t Doing Scrum If…

You Aren't Doing Scrum If...I’ve been frustrated lately by the flippant use of the words “Scrum” and “Agile” in our industry.  They’ve officially made it to the point of “buzzwords that mean nothing” that get slapped onto job requirements like the typical requirements we’ve all seen.

  • Must be able to communicate
  • Must be able to work in a team environment
  • Must be able to work under pressure
  • Must be able to work in an Agile environment

What’s really funny is when I see

  • Meet tight deadline
  • Expert in Agile

together in the same job request.

Really?  Do you know what you’re saying?!

Many people even use the words “Agile” and “Scrum” interchangeably.  Most because they really do think they are the same thing.

I’m finding that what most people mean when they use these words is, either, “we work really fast”, “we work iteratively”, or “we don’t really have a plan.”

So, the first thing we need to clarify is, what is Scrum and what is Agile.

Agile is a set of values.  It is what we believe about software development specifically and, I would argue, also impacts how we view life.  You might have other beliefs that live on top of Agile, but these beliefs will have an impact on how you manage the software development process specifically and your organization in general.

Check out the Agile Manifesto.  This is what it means to be Agile.

In contrast to this, Scrum is a methodology that helps an organization BE agile.

Now here is where things get tricky for some people.  They read in the manifesto that we should value “Individuals and interactions over processes and tools” and think that they can make Scrum be whatever they want it to be because, they would say, “we don’t value processes and tools”.

But the Agile Manifesto never says that.  It says we value individuals and interactions MORE than, not INSTEAD of, processes and tools.

So, yes, you can adapt and modify Scrum to fit your situation.  You may need to.  But there are some specific elements of Scrum that you simply can’t ignore because to do so would mean either that you are no longer Agile or you are not implementing Scrum.

And so, you aren’t doing Scrum if:

You have deadlines, especially if you have “tight deadlines”

“Now wait a minute,” you say, “I heard that Scrum has these things called ‘Sprints’ that are a fixed length.  Don’t those qualify as ‘deadlines?’”

Well, yes and no.  You see, I don’t think what Scrum treats as a “deadline” is what most managers mean by “deadline.”

At the end of the day you’ll get to the end of the Sprint and you’ll show what you’ve got.  The GOAL is to have a complete set of code that you wouldn’t be embarrassed to show to another programmer.  You should have only selected what could reasonably get done in the timeframe of a sprint so that all that needs to be done to complete the task could get done.

One of the confusions is that somewhere along the line we were told that at the end of each sprint we should have a “shippable unit of software” and we’ve confused that with “a viably marketable product”  All that shippable means is, “if the customer thinks what you’ve completed so far is something they can use, you would not respond with, ‘but it still needs…’”

This ties in with the other way you know you aren’t doing Scrum

You aren’t doing scrum if you don’t have a “definition of done.”

And once again, there is confusion.  To most people, the “definition of done” is “I can ship this code.”  But that may not be appropriate.  You’re definition of done during your first sprint may be “a set of stories that begin to describe the application we are trying to build.”  As you are learning scrum, you’re definition of done may be as simple as, “all of the code we’ve written so far have Unit Test, appropriate documentation, and we’ve learned something of how long a story point will take our team.”

Definition of done doesn’t always have to mean “I’ve written code I can ship.”

You aren’t doing Scrum if you HAVE to work more than 40 hours a week.

One of the benefits of Scrum is that it allows us to pace ourselves.  We no longer scrabble to get stuff done.  We work consistently toward the goal.  But it isn’t a race.

I have a rule.  If I tell you something will be done by a set time, I’ll bust my butt to make that happen.  If you tell me when it will be done, good luck with that.

Of course, even when I tell someone when something will be done, I pad the estimate with enough hours that I never work more than 45 hours a week.  There is one day, in the 26 years I’ve been doing this where I worked longer than 12 hours.

In fact, I had one manager who called me into his office and asked me to come in on Saturdays.  I was already working 10 hour days 5 days a week!  Talk about getting blood out of a turnip!

I looked him straight in the eye and said, “I have 50 hours a week in me.  I’d prefer to give them to you Monday through Friday.  But if you want me to come in on Saturday, I can do that, but you are still only going to get 50 hours a week.”

Needless to say, I never came in on Saturday.

I could go on…

I could go on, but these are the really big ones.

So, what do you think?  What examples do you have of places that say they are Agile/Scrum environments but don’t have a clue what that means?

Leave a comment below.

 

Other post in Scrum

Related Post

  • Technical Debt Is InevitableTechnical Debt Is Inevitable loading... Whoa there Dave.  What are you talking about?  Have you given up the fight? You who have preached the TDD religion.  You who’ve struggled to get organizations to […]
  • Being Agile Is About The Journey…Being Agile Is About The Journey… … Not The Destination This post first started as I was discussing my post “You Aren’t Doing Scrum If …” with a friend who had read the post and was worried that I might not fit in an […]
  • 3 Reasons Agile Will Not Succeed3 Reasons Agile Will Not Succeed I’ve written about Agile and Scrum before and most of my regular readers know that I am a huge fan.  But recently I am starting to believe the Agile movement is doomed.  In fact, the most […]
  • Limiting Beliefs of ProgrammersLimiting Beliefs of Programmers At the risk of making half of my audience think I’ve gone off the deep end, I’m going to address a topic that I’ve only recently REALLY begun to understand, in part thanks to Soft […]
  • Agile/Scrum Task Board for “Real Life”Agile/Scrum Task Board for “Real Life” The agile “Task Board,” also known as a “Scrum Board” has become a staple of the agile programming world.“Getting Things Done” (GTD) is a process for managing task in the business […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

2 Pingbacks/Trackbacks

  • Pingback: Dew Drop – January 22, 2015 (#1938) | Morning Dew()

  • Software development companies should read this article when starting to implement Scrum. They have huge expectations from the Agile methodology but they forget that they cannot measure results immediately. It can take up to 6 months to decide if it’s working or not – at least that’s how long it took us.

    And while analysing the process, companies need to make sure that there aren’t any other hidden obstacles and that all employees are open to this new approach. It’s very true that Agile can streamline the processes but it cannot perform miracles if the team doesn’t embrace it or if there is lack of knowledge involved.

  • Brian

    How about this one, you aren’t doing Scrum if every developer has their ‘own’ stories in the sprint.

    • Meaning everyone gets assigned task rather than being able to grab the next available task that is most suitable to them?

      • Brian

        I meant a developer signs up or gets assigned a task and they are the only one expected to touch that code. There is no collective ownership of the code.

        • What if your scrum team only has one “developer”? I could quickly get a scrum team to an optimum size of 5 or 6 with just one person who knows how to write code, especially when the team is just getting started. Others on the team would be:
          * Subject Matter Experts
          * Designers
          * End user documentation authors
          * QA – those responsible for finding the edge cases we didn’t program for
          * And of course, the scrum master.

          Could some of that work be done by the developers? Could some of them potentially do the work of the developer? Yeah, sure. But if you are going to make that a requirement to be doing Scrum, you run the risk of making a team bigger than it should be.

          On the other hand, if you have only programmers on your scrum team, that in itself, is an indication that you probably aren’t doing Scrum

  • Pingback: Scrum everywhere. - May of cherries()

  • Kevin O’Shaughnessy

    You aren’t doing Scrum if you are skipping your retrospectives.

    Without the retrospectives you won’t appreciate many of the difficulties your colleagues are having, and will miss out on the good ideas for improving your process.