I’ve been frustrated lately by the flippant use of the words “Scrum” and “Agile” in our industry.
Actually, I’m STILL frustrated. I originally wrote this article January 2015. Not only is it still true. It is more true.
Our industry has been treating Scrum and Agile as “buzzwords that mean nothing.” These words 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.
And even if it doesn’t show up in the job description. Once you get into the organization, you find out they are no different than any other organization. All those promises about running “Agile” or “Scrum” as a well of figuring out how long a project will take fly right out the window as soon as a manager wants something done by a specific date.
If management ain’t Agile, ain’t no one Agile.
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 scramble 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…
But I won’t