Why My Former Company Couldn’t Succeed at Scrum

Companies struggle to adopt scrum. Its rare to hear of a company that seems to be progressing. I recently worked for a company who was agile. On paper . . .

Here were some of our biggest blocks for adoption:

Work really hard and you will succeed. The same hard-working entrepreneur mentality the owners had cultivated in their basement in the 1990s was a core value of this company. Finding a sustainable pace was a foreign idea to them. Managers were expected to work hard and sacrifice. Exhaustion was common. I remember asking the vice president how he was doing. As he rubbed his eyes, he said, “Same as always. Too much to do and not enough time to do it.” I’m sure he couldn’t imagine being successful any other way.

No value in training. If you were lucky, you got a two day CSM course. Most never had any scrum or agile training, though, or they had training long ago and needed a refresher. Some were handed the Scrum Guide and expected to read it on their own. A coach was completely out of the picture. The reason—no time or money. Once, I offered to give my team short trainings on agile concepts once a sprint. Ten minutes later, my supervisor called me and told me “No.” If management found out the team was doing anything but developing, I would be held responsible. Its not as though this company didn’t value learning, though. Their expectation was that you took it upon yourself to learn. I can see why someone with an entrepreneur mindset would think this (after all, no one taught them!). But golly, we were always so darn busy–when would we have time to learn?? On our own time, I can hear them say. ‘When do we have our own time?’ You have to make it they would say. ‘Gee. Thanks for the advice.’

A sense of its never going to get better. Retrospectives could be rough. I was on three different teams while at this company. Each team told me, “It doesn’t matter what we say in these retros, nothing is going to change around here.” Many wanted to discontinue retros completely.

Technical debt is ok. I worked on a project whose code was written by a blind guy. It was awful. We fixed one feature only to have another break. The developers wanted to rewrite, but the executives wouldn’t allow it because the product was under tight deadlines for delivery. Instead, band aids were applied over and over again. ‘Someday,’ the executives said, ‘we will rewrite it.’ At least one developer, unable to bare not being able to take pride or creativity in his work, got tired of waiting and left the company. Last I heard, this team was still applying band aids.

Fear. The company had gone into bankruptcy twice in its early years. I can’t help but think this was in the back of the minds of the owners. Because there was fear, change was risky. Especially if you had found success doing it a certain way. I forgot how many times I was told, “If we don’t do it this way, we are going to lose our contract!”

Finger pointing. Like most traditional companies, fundamental attribution error runs rampant. QA, in general, was regularly blamed for things that went wrong. They were told they didn’t work hard and were complainers. Many members were defensive. They often took sick days. On the more difficult teams, turnover was common. To protect her department, the QA director created rules that applied only to QA, such as allowing them to work from home several days a week. This rule created resentment in the other departments and only strengthened the stereotype of wimpy QA people.

Smorgasbord Scrum. The company seemed to pick what they liked from scrum and discarded what they didn’t. I can count on one hand how many times I saw a team burn down. Management never paid attention to velocity. All that seemed to matter was that the team had performed more points than the previous sprint. I saw one scrum master get angry when his team didn’t do as much as the sprint before.

Scrum roles not embraced. The product owner had the ultimate power. What the product owner wanted, the product owner got. This included throwing out the scrum rule book. I was literally told by my product owner, “Its my way or the highway.” Scrum masters were treated like assistants to the product owners. Many in the company had no idea what the scrum master was supposed to do. Heck, we weren’t even allowed to call ourselves scrum masters.

Agile was not respected. My boss’s boss couldn’t mention agile words or concepts around executives. I was told they would laugh at her or give her condescending looks when she did. The vice president of development hated agile. He thought it was ruining the company and taking away from development time. Imagine that! The vice president of development!

Partner companies did not embrace scrum. I was on a team where the partner company did half of the development work. Though they participated in scrum ceremonies, their management remained traditional. Worse, their manager would impose herself on our team to make things go the way she believed things should be going and management allowed her to do it!

Sprints were not protected. It was ok to interrupt a sprint. It was ok to add more items to a sprint and not remove anything. It was ok to start a sprint without a full sprint worth of work. It was ok to overload a sprint. It was ok to increase the length of a sprint. It was ok to shorten or lengthen the sprint.

Value of the Hero. I remember one team I was on had the rug pulled out from under us on my second day on the job. The development manager literally told us, “Management is looking for heroic efforts to get this resolved.” This company valued really smart people who knew the product, would take charge, and would stop at nothing to get success. Unfortunately, this created a command and control culture, stifled cooperation and trust, lowered morale and as a result killed productivity and innovation. As a result, nothing got better and management was left to wonder why.

Executives just didn’t get it. The idea to adopt agile came from middle management. I’m not sure why the executives agreed to allow it. Perhaps to throw middle management a bone? Because the idea of scrum sounded good? They paid for CSM classes, licenses for Rally, they even agreed to some process changes such as two weeks sprints. When did they expect to get anything out of their investment? In retrospect, this issue was probably our biggest hurdle in adopting scrum.

What obstacles has your company faced adopting agile? Has it been successful?



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s