With Scrum so far, I have learned two things.
First up, Scrum is meant for Development Teams, not multipurpose IT Teams. Second, Scrum does not fix any problems, it only reveals them. It takes a separate effort to fix those problems. If Scrum is applied without a dedication to fix those problems, things get worse and not better. If Scrum is applied to a team that does more than just software development, their deadlines will suffer on account of their non-software writing tasks, and they will begrudge the non-software writing tasks.
If the team is doing more than pure development, then compromises have to be made. Since time allocation with an IT Team or Maintenance Team can be unpredictable (it’s hard to predict when someone needs assistance, or when something will break), it means that the entire idea of setting due dates doesn’t work very well. The very point of Scrum is to have a deadline every Sprint (in our case, every month). This means that we now have the stress of missing a deadline every month.
By our very nature, we are a multipurpose IT Team. We develop, maintain, and assist. Sometimes our duties include helping someone install a keyboard or setup a projector. Sometimes we help with Excel formulas. And sometimes we build applications. We can’t have laser like focus on a development goal when we have random things interrupt us every day. Those interruptions become a point of anxiety and stress. I typically enjoy helping users solve their problems, but when helping a user gets in the way of what is my “primary task” of trying to meet a Sprint deadline, I begin to begrudge the user, and their problem.
Spreading the interruptions around the team seems like it would work to help reduce the stress and anxiety, but it seems to be doing the exact opposite. Now when someone walks down the aisle needing help, we all cringe thinking “please don’t ask me, please don’t ask me…” which causes us stress, even if we aren’t the person that gets asked to help. We also feel sorry for whichever dev is picked, because we know their stress is even higher, and that they will feel failure when they don’t finish the tasks they promised to do that same morning. Previously, these are the situations in which I would be happy to help, but now I am stressed that I will get picked and stressed for my teammates. And when I do get picked, it stresses me more, because I know I won’t finish the tasks that I picked that morning in the Scrum standup. By helping someone else with their problem, I fail to get done what I said I would do that morning. Sometimes if the task I picked doesn’t get done, then it will block someone else, which is even more stressful.
For a team to be a Development Team, they need to be shielded from interruptions. That means someone, or something, needs to stand in the way of interruptions. When someone walks down the aisle looking for help, someone or something should be there to say “No, you can’t have So-And-So, they are dedicated to a particular task today and can’t be interrupted unless someone is on fire”. At the moment, we don’t have that.
We have attempted to put physical objects up that are meant to perform that task. Our Build Board has our availability status, if someone isn’t marked as green, they aren’t available for interruption. But mostly people view this as a novelty. Because I always have a task, I am always marked as Busy, which is perhaps true, but perhaps also not helpful. We have a touch screen monitor which will eventually have burndown charts, impediments, and who is working on what task. Theoretically anyone should be able to look at that monitor, and figure out who is the most available for interruption. However the laptop that powers it has been quite flakey, and we haven’t gotten the time to get all of the charts and info setup, so most of the time the monitor remains black. I’m guessing it will not help prevent interruptions any more than the availability status on our Build Board.
What we need is a person, not an object. We need a person to block interruptions from affecting the Development Team. The Boss could theoretically block quite a few interruptions. He can say “no” to people asking for help, and he can himself help with some tasks. But truth be told, the boss is rather busy with tons of meetings, contracts, and other tasks, and helping someone with their excel formula is just as detrimental to his tasks as it is to the Development Team. Also many times the interruptions are something that requires a programmer, someone who has the ability to get into code and hunt bugs.
One of our teammates has suggested the idea of taking turns being the Blocker. The idea is that one developer is taken off of the development team for a week, and their duty is to deal with whatever comes up. They will help install keyboards, help with excel formulas, fix emergencies in prod, setup new users, and everything else that our team is expected to do that isn’t tied to our primary project. If something comes up that they aren’t capable of (perhaps it’s a bug in code they don’t understand), then they need to evaluate if it can wait for the next week, or if it is truly urgent and someone on the development team should be interrupted. But the Blocker should do everything within their power to prevent the team from being interrupted!
The problem with that though, is that it makes it sound like it’s an unpleasant duty. Everyone has to “take a turn in the barrel”. When in truth some of us love hunting bugs on dev, helping random users fix their problems, and the plethora of other weird things that pop up. I admit I would get seriously bored if all I was doing was being a code monkey for 40 hours a week. The variety is what makes this job fun. The idea of taking that week to help folks sounds fun! But I know for some people it isn’t fun.
Thinking on this made me think back to our past three projects. All three were great successes. Two of them were done with the development team being contractors, that we strove to not interrupt, and I had the duty of being a facilitator. If they ran into an impediment, I helped clear it. If they had questions, I helped them find the answers. I reviewed their code and made sure they were heading in the right direction. The other project I was the only developer on. I did it in my “free time” while helping on the other projects. My project turned out great, but deadlines were hopeless since I was helping so much on the other projects. Pretty much the ONLY stressor on my project was the fact that I wasn’t meeting deadlines. The code was fine, the project was fun, but the deadlines we picked were impractical given the other responsibilities I had. I enjoyed those other responsibilities greatly, until they started affecting my deadline, which caused me stress.
I enjoy being that blocker, except when being that blocker gets in the way of my deadlines (sometimes those deadlines are external, sometimes they are self-imposed).
So now coming back to our current project. We don’t have someone to block interruptions, and we don’t have someone to facilitate clearing problems. Instead it is spread around to all of us, and wearing all of us thin. Our deadline is hopeless. And our stress levels are insanely high. The tasks we promise to do aren’t getting done, we keep getting interruptions, and we are taking shortcuts constantly. The project we set out to “do right” is failing.
To make things worse, we have several other projects spinning up that are being done by contractors. Because those contractors are being paid for very specific tasks, someone has to be there to fix any weird things that pop up. Such as helping them get their VM online, helping them get connected to TFS, facilitating meetings between them and other development teams in the agency, and quite frankly each of those projects needs a blocker too. So we will have even more interruptions to our team if we have to take turns fixing their issues and being their blocker, which will affect our deadlines even more. If we aren’t careful, our development team will be supporting contractors, instead of contractors supporting our development team.
The idea of the blocker is a rather Cowboy Coder concept. They bounce between projects, taking pot shots at bugs, dabbling in all the code, and in their free time they are perhaps helping out on an actual project. But I feel that they are basically an adapter between a Scrum Development Team, and the expectations of what our team should do for who we support. They would allow the development team to mature and solidify, and help educate others about how the “new process” works. There is talk of a new scrum team being a “Scrum Bubble”, and they would be that barrier around the bubble, allowing it to grow. As the concept of Scrum is adopted throughout, the team will no longer be expected to perform Cowboy Coder tasks, and the role is no longer needed.
I think I would be interested in fulfilling that role, for a few different reasons. The biggest reason is that I am not enjoying our attempts at Scrum. I find our attempts to be extremely stressful, and I don’t think the underlying problems are getting fixed. I have distaste for deadlines anyways, and Scrum is a new deadline every month. I understand that Scrum can make a development team more efficient; however I’m finding it to be significantly less fun. I don’t require focus to flourish, I require variety. I am a Cowboy Coder by birth, and seeing a place where doing what I enjoy could help others sounds great. I think I could help solve problems, which I enjoy, and I think I could reduce the distractions to the development team, in the same way I did for two of our previous recent projects.