One time, I was asked to work in a project in an mixed role as Scrum master and requirements engineer. Many people will snub their noses at such an arrangement, and often with good reason. Mixed roles are not well received in the agile world, but for me this is right up my alley. I have a very broad set of interests and skills, and I like situations enabling me to bring as much of that skill set into play as possible.
But when I started to work at the place, I soon hit a major road block. Agility, as I understand it, wasn’t required or indeed welcome there at all.
How did I know? Well, they told me, and they didn’t beat around the bush either. “Agile is chaos,” one project manager let me know, “we don’t want that here.”
“We’ve hat bad experiences with agile work. That one team we tried it with just went about their own ways, and the end result wasn’t what we expected,” said another.
So you failed once. Not a big deal, considering that according to some sources 70% of classically managed software projects fail. Try again, fail again. Fail faster. (BTW, did you notice how this business often feels like phrasemongering? That’s because you need to repeat a few central ideas over and over, until the concept sticks in the brains of your teams. If you are starting agile work and do nothing else, choose a few crucial phrases well, try to understand the concepts behind them and stick with it.)
Of course, it wasn’t over with those blanket statements. In the course of the work, we stumbled every time the team was supposed to make a decision for itself, even small ones, like deciding on the time of day they want to have their daily. It was to be at 9 AM, come hell or high water, no input from the team required.
Why is that important? The framers of the agile manifesto had a crucial insight: People want to be helpful. They are motivated, if they feel trust and empowerment. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” I don’t know a more effective motivation killer than micromanagement, especially when working with highly qualified individuals.
And it doesn’t help if you put your team in a double bind. “These are the sprint goals, which I’ve presented to the team, and now get to work. No, don’t waste time discussing if these goals make sense at this point, or whether the goals are indeed reachable. We need to reach them, or the project won’t be done in time.”
If a thing cannot be done with the given resources, it cannot be done. Wishful thinking won’t help, and neither will additional pressure, at least not in the long run. What will help, is listening to your team. After all, it consists of highly qualified individuals you chose for the job because you thought they could do it. So why not listen to them? And you can only listen, if you give the team the room to talk. Demos, plannings and retros are the space for exactly that. There is always something to learn from them. The Scrum framework even gives you guidelines for how much time you should allow for these events each sprint.
Look, the thing is: You don’t have to do agile, if you don’t want to, much less Scrum, which can be a bit of a challenge for people who have no experience with the method at all. It’s not a law, and there are other frameworks available. In fact, don’t do it if you’re not fully committed to it, or you will end up with zombie scrum. You know, because a zombie somewhat looks like a human, but inside it’s all dead and it stinks.
Anyway, how do you deal with it if you find yourself in a similar situation? Here’s what I tried:
– Educate: Explain the advantages of agile work. Also, make the limits transparent. Agile is all about discipline in the right places, so that the team can have the freedom it needs where it counts. Don’t let a team wander off into the wilderness. Demand progress, and demand the progress to be shown. Sprint reviews are important, and so are retros. It may sound like a huge waste of time in the beginning, but the benefits will become evident if and when the team forms a habit of constant inspection and adaptation.
– Also important is strict time boxing. There is a reason why scrum will only allow 15 minutes for a daily. The purpose of a daily is not to report to the manager, and also not to solve problems. It is to identify the problems and assign them to people who are able to solve them. This will indeed work better if the time is limited.
The same ist true for the length of a sprint and the time any story is in the works. If you cannot get your stories finished in time, you might actually be better off using Kanban and focus on a limited number of items of which you have a very clear idea how long they can stay in the works. Put first things first, and the first thing to focus on in a team that doesn’t want to do agile is to make sure things are actually getting done.
– If all of this is not enough, try to find allies. This is actually a good idea in any case, but it get crucial if the resistance is too strong for one person. Your allies don’t have to be in upper management – in fact I’d rather they weren’t, agile is nothing you can impose top down – but if your conflict is mainly with a manager, you can work around them sometimes. If it’s just one or two team members, they can sometimes be swept off their feet and carried along by the developing dynamics.
In my case, that also didn’t work. The situation got worse week after week. I never got criticised for any mistakes I made, but for the things I did well and right. I could have given up on my role as Scrum master and just written up requirements for the rest of the duration, but that wasn’t what I was taken on for in the first place. So when, after two months, I was given a way out, I took it. After all, “fail fast” is another one of the driving principles of the agile approach.
How would you deal with such a situation? Help me learn an let me know in the comments.
