Month: July 2016

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?

Advertisements

Am I Agile?

If someone were to ask me if I’m agile, I’m not so sure I’d say yes. For one–I’ve seen a lot of negative connotation to the word and I can’t help but think to some, being agile in an organization is at the worst, a recipe for career suicide or at the least, impeding it. Perhaps I’m being cowardly, but I’m starting to think it might be best to sometimes just to keep my mouth shut and model what I believe. It will make a bigger impact on those who don’t believe.

So, what do I believe exactly? I think that while I may be an agilest at heart (influenced primarily by scrum and some by Kanban and Lean), much of my way of thinking comes from W. Edwards Deming’s teachings.

These are my core beliefs:

Focus– First lesson I learned from our scrum teacher. This has been reinforced by understanding Single Piece Flow from TPS and studies of Flow (psychology). Oddly, I’ve never seen Deming bring this up. Perhaps it wasn’t so much of a problem in his time.

Continuous Improvement– Agile got me started on this, but Deming has me thinking more and more about PDSA. These two go hand and hand quite nicely. This principle is probably at the core of pretty much everything I do.

Customer Delight– Important to Agile, but Deming has driven this home to me even more. Its not enough to have a satisfied customer. They must come back and wait in line and bring a friend with them. Even this may not be enough.

Teamwork– Extremely important to Agile, but again, Deming’s thought of treating others on the team or within the system like they are your customers really rings true to me. The thought that everyone is part of a single system in an organization fits well with Agile’s emphasis on breaking down silos.

Motivating Others– Deming’s emphasis on understanding psychology to motivate is a core belief of his. Joy and pride in work are corner stones of his. Jeff Sutherland says the same thing in his book. In other books I’ve read by both Deming and agilests, the importance of getting people to be intrinsically motivated over extrinsically is important for both productivity and quality of work (not to mention quality of life).

Appreciation of a System– Definitely a Deming tenant, though the tools I use to help me understand it are rooted in Kanban (I’m big into wall charts). Deming’s belief that 95% of any problem is because of the system and not the individual goes through my mind any time I encounter a problem on the job. Jeff Sutherland also introduced me to Fundamental Attribution Error, which is closely related.

Importance of Immediate Value– Something that is becoming more and more important to me. Definitely an Agile pillar. I’m starting to wonder if this is something Deming would oppose, though. I’m starting to find that what a person values could be the incorrect. If we just create on what our customer values, it could lead us to ruination. Deming might say building expectation is more important. I don’t know. I’m still thinking about this one.

Sustainable Pace– Spelled out specifically in the Agile manifesto principles. This saves me from burning out and I am constantly checking to see if I’ve found a good pace that I can keep indefinitely. I’ve never seen Deming say anything about a sustainable pace. Not sure what he would think, though I think this might fit into his concept of understanding a system.

Education/Knowledge/Training– Deming is big into this. Its not something that is specifically spelled out with Agile, though it certainly falls into kaizen and continuous improvement.

Change Agency– When you join the Scrum Alliance, they ask you to be an advocate for agile. I see it as a crucial role for any scrum master. I’ve heard some say that if you have good scrum masters, you don’t need coaches. Deming never said we needed to be a change agent, but he spent his whole life trying to convince others of doing things a better way. He didn’t stop trying to make a difference until the end of his life. He gave a seminar only a month before his death. That is inspiration to me.