At what point do you stop trying?
My day-to-day business is being a software tester and next to that, I’m also a Scrum master. Being a tester doesn’t give me much trouble, other than the usual stuff: acceptance criteria are a challenge to overcome, looking heartfelt into a developers eyes and trying to get to the bottom of his coding choices and generally following your gut while testing (either with or without script).
As a Scrum master I work with Scrum teams. As you can google: a Scrum master is the person who makes the team ‘follow the rules of Scrum’. These rules are giving me a headache. This particular team existed before I became Scrum master, and this project consists of more than one scrumteam. Problems we (me and the other scrum masters) run into on a daily basis usually consists at least partly of: how do we make this Scrum rule work for OUR team? Then from project management (very old-world style) we get wishes and rules laid upon us that usually do nothing good for our team, or our Scrum process. Needless to say, I face a fair few ‘bitter’ people in relation to Scrum. They are convinced it does not work.
Let me make myself clear: I love Scrum. I believe in it, I use it in all sorts of business outside of work, for me it has definitely been my savior. In my personal opinion, Scrum can solve a lot of problems you come across in ‘waterfall’ projects. It can teach you lessons, it improve you as a person and as a team. Especially combined with other beliefs, techniques and communication studies, like: ‘Find your drive’, ‘Gettings things done’ or any other effectiveness or communication strategy. It helps build a team and it helps create better (in this case) software. What more could you want?
Let me explain why I choose ‘savior’. I’m an analytical person. I like to have an overview of what is going on around me. In a large scale project, without iterations, this can be overwhelming. It’s impossible for anyone, even the project manager or team leads, to oversee the whole picture. If at any stage something happens, the repercussions are immense. This we already know. Scrum helps give aim, to give focus, and to make things clear. Abundantly clear, for everyone involved understandable. In that sight, Scrum is the ‘savior’ of project management. It’s completely clear what is being worked on, and there’s a clear outline when this will be finished. This is always near-future and hopefully business driven. Even if it’s not business driven: business will see it soon enough and there will be a chance to steer the project or product in the right direction.
Now let’s move on to ‘saint’. Scrum is being put out there by a lot of people as ‘this is the ONLY way, and you must do ALL of it for it to work’. This is like telling people you can only call your daughter Sandra, because all other names are taken and this is clearly the best one. It’s being idealised and that’s not doing a lot of good to the development method. It’s kind of like ‘saints’ of the old religtions, telling people how it ‘is’. Every work environment is different and work environments will ask for tweaks or adjustments. It’s not a set way of ‘how to work’, it’s open for change, that’s (correct me if i’m wrong) in the Agile Manifesto.
Responding to change over following a plan.
Dear ‘saints’ out there who are ‘spreading the one word of Scrum’: please use your (our) own guidelines and let go of always sticking to the one possibility of it working. By sticking to your plan, and telling other people to only follow only *that* plan, you’re completely ignoring the more important part of that line: ‘Responding to change’. If you need to do things differently, by all means: do it if it works for you. And share your learned lessons with others. It’s worthwhile and who knows, you might be helping people who are struggling with the same problem.
And up last: ‘villain’. There are meriad workplaces, projects and companies where ‘Scrum’ is the word. Only one version of Scrum. That needs to be done exactly this way. By acting as a saint and spreading just your word, you’re creating villains. They are the people doing the work, your ‘pigs’. They’ve been led into the Scrum process by a saint. They’ve been told: ‘These are the rules, do this, and only this’. They’ve seen it didn’t work as well as they hoped. If this was because of Scrum? Probably not, but that’s not what they see. Scrum was new, this turned bad, so it must be Scrum. By following the plan you undermined the method. These people will not easily be swayed into the other corner of the ring. They’ve seen it does not work and will believe this from now on. But these people still have to work in scrumteams and will, sooner or later, taint others in that scrumteam, too.
This is what I often see happening. It’s a real shame, I truely believe that if we would start to actually look at Scrum and understand it’s manifesto, we would see that firmly gripping the protocol and sticking to that NO MATTER WHAT.. is rarely going to work. Obviously to teach people about the method, it’s good to have a set of groundrules. But after they know the general idea, respond to the needed change and make Scrum work. Anywhere.
Which leads me up to my question: at what point do you stop trying? I don’t feel it’s a battle with or within my team I’m trying to win, it’s a battle against the villains. Getting people to see the good in a really, really great method. While they’ve seen it does not work and would not like to ‘go through all that again’. Are these people lost? Personally, I don’t think you should give up on people. Maybe the team setting can be altered, maybe the Scrum process could be revived. But until that day, that wonderful day that the whole teams ‘believes’ again, it’s going to be a struggle. Not just for me, but for my team. And for Scrum.