In This Corner, SCRUM
The misconceptions of Agile and Scrum are amazing in the industry today. You have your Agile fanatics and your old-school waterfall professionals facing off in what seems like an endless fight.
I’ve been practicing Scrum since 2003 and a Certified Scrum Master since 2006. I’ve implemented Scrum in many different organizations and industries. I’ve provided training to developers, business analysts, project managers, quality assurance analysts and executives on the concepts of Scrum and how it could fit into their organizations. I’ve been asked to help save failing Scrum projects missing deadlines and threatening to go severely over budget.
I adopted Scrum not to follow the latest trend, but because to me, it’s a natural way of thinking. It’s tasking and priority management with guidelines and discipline.
As the time goes on, I’ve seen a very strong up-take on the words Scrum and Agile, not so much on what they stand for. But let’s face it, the IT industry is FULL of buzz words and acronyms.
I’d love to tell you that through my experience I've seen the industry gain a really good understanding of Scrum and Agile. Well unfortunately its been evident more times than not that we don’t. We use the word Scrum to explain what we are doing, but we don’t understand the concepts, discipline or principals that go along with it.
We grasp onto Scrum because it promises to deliver quality product in shorter timelines. IT’s been historically bad at doing both. I mean, why wouldn’t I grasp onto Scrum? I get more for less right? Win… Win…! So we bring Scrum into our projects, organizations, teams, and companies.
Now our waterfall brains love status reports, so we implement a daily stand-up. mmmMMmm, status reports every day….<insert drooling face here>. We understand the concept of iterations, but don’t understand the concept of creating stories, managing shifting priorities, and working as a cohesive unit with our business sponsors.
A Requirements document is all I need as long as it’s complete, approved, and won’t ever, ever, change. And what is this “Points” thing I hear about?! How do you estimate based on… what do they call it? Bigness? Give me a break! I use hours, been doing it for years!
So, we implement 1-2 month sprints. We create large stories and estimate them with little success. We go over time on most of our stories and don't meet our Sprint goals. We sidetrack our daily stand-ups to be status meetings. Hey, if we have a status meeting every day, we’re golden right?! But we struggle trying to manage these shifting priorities, how can you shift priorities 3 weeks into a month iteration?!
When the project starts failing, we strengthen our micro-tasking (I knew I shouldn’t of trusted Scrum!), we demand more detail in our daily stand-ups and start cutting half completed stories from our iteration to be done at another time. We start segregating the team into individual meetings and priorities instead of working as a single, transparent unit. We don’t have time for questions! We have our BA’s work an iteration ahead of our Development sprint, and the QA team a sprint behind. The calendars of project members are slowly filling with meetings, some of which covering the same or similar topics with different participants.
By segregating out team members because of failing timelines, because we don’t have time for working things out as a team, our team members end up with more work and less time to do it in… how’s this possible!? When our iterations don’t produce releasable products as promised, we shake our firsts and curse Ken Schwaber and Jeff Sutherland for every dreaming up this concept!
Scrum? Bah, humbug!
But let’s be honest, we didn’t really implement Scrum, did we? Sure we created something called stories, but we didn’t implement proper Story sizes. We didn't estimate them properly. We don't manage proper sprints. We didn’t implement proper priority and backlog management. We didn’t even work that closely as a team and with our sponsors. I bet we didn’t even properly compensate for testing and remediation time in our Stories and Sprints!
We simply created waterfall projects on 1-2 month iterations with daily status meetings. I bet you might have even called these sprints stage-gates or milestones. That’s all we truly implemented wasn’t it, a waterfall process of large monthly stage-gates or milestones and morning status meetings? We might have a Scrum board, cards, a fancy Scrum Management Application and even a burn down chart, but without proper stories, discipline and knowledge of how Scrum works or backlog management, they alone don't provide you the value of Scrum. Plus I bet you don’t pay much attention to them because they're mostly wrong.
Hmm, that’s interesting, so what is it that failed us then? In this corner, in the blue trunks we have SCRUM! In the Red corner, we have WATERFALL!
Before you post your comments:
Notice that I’m not telling you every failed implementation of Scrum follows this path. I’m not even telling you Scrum is better than Waterfall. I’ve never told you that you will be successful with Scrum and have disastrous outcomes with Waterfall. I’m challenging you to look back at your failed Scrum implementations, or even at your current failing implementations and ask yourself, did you really give it a fair chance? Have you implemented Scrum, or have you implemented some buzz words from scrum into your waterfall process?
Only you can answer that.
