SCRUM Is Guilty!

---

In spite of increasing popularity of agile methods in the world, I can see rising also significant reluctance and diversions from agile techniques, and especially Scrum, in many organizations. The attempts to implement Scrum and Agile have failed, projects were not completed and bitter memory remains afterwards. Scrum was terminated, its worshippers executed, bad mood remains, bad reputation is omnipresent and dirty stories circulate the market. “Victoria! At least, we have returned to our old and safe way!”, celebrate nay sayers.

Situation is serious, because there is quite a lot of negative stories, which put negative impression on all agile activities and Scrum in particular, which significantly slows down its adoption and implementation.

What is happening?

In last two years, I was observing several Scrum implementations from smaller or greater distance – all of them have failed. My curiosity drove me to have closer look, and this is what I observed, among many other things. I reflect my observation in this series of three articles. I want to kick-off discussion, where you either share your observations or discuss opinions what can be done about it. In first I address intentions and goals, in second I focus on knowledge, and finally I want to mention external support , trainings and consultancy.

Buzzword motivation

“We are frustrated IT projects hardly miss deadline and we cannot trust IT staff anymore. But we heard there is Scrum, a new methodology, that is becoming popular and which delivers. We must have it!” And then, camouflaged under the flag of good intentions, one process is silently being replaced by another “better” one. This type of approach inevitably leads to failure.

I was invited into one company to see, why their Scrum implementation does not deliver. The project with tight deadline was significantly delayed and seemed to be visible, that people dont know what to do about it. Several months into the project Scrum have had bad reputation already and it was considered being bad word. When I came to organization, I learned that motivation for using Scrum was one manager likes it. I was unable to track reasoning for using this technique.

When Scrum was invented, it aimed at product development, not project management. It could be used in projects within limits, however such deployment need careful consideration. In my book, it is always important to understand the goal, and only then an appropriate tool and strategy should be selected to fit our objectives. Implementing Scrum or any other methodology should not be a goal. With implementing Agile, we try to implement agility into the organization. Here is where Scrum serves us as a supporting tool. Instead of how to meet the deadline and budget, we are focusing on how to create highest value for customer through intensive collaboration. This is different objective, and it is definitely not a short term one.

So wrongly set expectations and objective followed by inappropriate tool leads to disappointment. It is not failure of Scrum, it is failure of people managing its implementation.

Project archetypes in configuration

In one failed Scrum project, I found that team members – maybe hundred people – had had no training (“we dont have budget”) on Scrum, there was not any single person with knowledge of Scrum on site, no implementation plans were in place, no strategy, and project was “managed” by group of project managers, in some cases rebranded to Scrum Masters. There was no customer involved, and for team members was unclear, who the customer is. They just got some specification from some analysts somewhere.

I am be sure, every project methodology requires project have to be prepared in advance – objectives, target group, technology, strategy, risk, …. For all agile techniques, same thing applies. Agile techniques are not designed to rescue chaos within organization, they rather support disciplined approach for hyper productive teams.

There is one significant aspect to be said. Scrum is not a process. It is framework. Similarly to all agile techniques, it can be operational long term only if installed on the set of values and principles. In all of the projects I observed, these foundations were missing. Ideal environment is having internal development team. Team, that we have created with long term intention in mind, and which fit our company culture based around agile values.

All projects I have observed have had common denominator. The teams were just temporary, assembled under unknown criteria. From very beginning people were recruited from various bodyshop agencies and in large numbers thrown onto the project expecting they will complete it somehow. Then they go, period. All under supervision of “project managers” and with clear end state of the action – dismissing everything after delivery by certain deadline. Agility is about creating highest value for customer. What will be motivation for people, who are hired just to build up something, but are completely eliminated from using the solution? What will be motivation for people, who are separated from customers and users of the application, but pushed to meet deadline and budget under traditional project management approach? What will be motivation for people, when customer refuses talking to them and practically do not care about progress of building solution?

And finally, why do managers expect people will deliver within deadline and budget under new methodology, if developers never worked together, never used such methods before and have lack of experience? Classical pitfall of project is throwing more and more resources on the project in hope it will help. There are numerous studies showing it delays project even further. In spite of this knowledge, managers continue using old practiced of project centric organizations while external business environment has changed.

Wrong Terminology

With the buzzword motivation goes hand in hand terminology. When implementing a tool, terminology should be understood and used in the same way by all stakeholders to secure transparency. Scrum is a defined framework, it has its roles, artifacts and activities precisely defined for purpose and each has its name. Removing something from the framework creates new framework, it is not Scrum anymore.

In my observation I saw crippled process being implemented. It was not Scrum, it was something confusingly different. However, in all cases it was called Scrum. It naturally resulted in negative perception of word Scrum. And negative emotions cause damage to the technique, which is otherwise good in the hands of skillful masters.

 

To be continued.