“...they in IT are
completely incompetent and ignorant. We told them, this project is extremely
important, and they screwed it up. It is all because they experiment with some
Scrum they said. Instead of doing their job, they just play around. No wander,
management finally stepped into and made some people finally redundant. Just
too late. Scrum in guilty.....” is just a brief fragment of conversation, I have
heard so many times.
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.
About author: Michal Vallo helps companies deploy agile techniques and improve performance. He is agile trainer, coach and manager at Aguarra and founding member of Agilia community.
Žádné komentáře:
Okomentovat