Every worker has at least one horror story about projects: endless work journeys, stakeholders' anger, infinite bug reports, hard feelings in email messages, late delivery, cost going over budget, etc... Could Scrum help you rescue a project under those circumstances?
The short answer is yes
. And I will show you (based on my experience) some basic steps for accomplishing that. However, let me first give you some advice:
Remember to be sensitive about the focus of your communication.
Stakeholders, project leaders, and the project team are not interested in cute, jargony terms. Probably you will find them stressed, angry, and tired. Listen to their concerns, write them all down (somebody said "Impediment Backlog"?), and show them how Scrum will help them resolve those particular issues. Only after that, take some of the following steps.
Work on definition of done.
"Come on! Everybody knows when an item is finished." Wrong.
Someone could understand "done" as a running code in her computer, other as an app published on testing servers, others as something that the client liked in a meeting. Without a team-leaders-stakeholders' unified definition of done, real progress can't be reliably measured
and delivery dates can't be well estimated, resulting in a generalized lack of trust inside the project team.
Build a product backlog.
I'm a big fan of user stories. However, I wouldn't encourage anybody to instantly discard their previous working items
(use cases, feature requests, or anything similar). Take all those items and convert them into PBIs (product backlog items), help the person playing the "client" role (a future product owner) to prioritize them, and, finally, make it public to everyone interested in the project.
You could communicate to the team the advantages of using user stories instead of other working items. If the team agrees, start writing user stories.
Help people transition to their new roles.
There's no universal recipe about new role transition, but some "traditional" roles evolve naturally into Scrum roles when the framework is embraced:
Client's representative -- In every team there is a sort of client's ambassador, independent of the project leader, often a member of the marketing or sales team. Coach him or her to become the product owner.
Project leader -- The most natural evolution of a project leader is into ScrumMaster, but there are two special cases:
Some organizations use technical leaders as project leaders. In that case, consider how feasible it is for this person to become the ScrumMaster, or whether he or she should instead be incorporated into the team as a technical expert.
In some organizations, project leadership is taken by account managers. That role is closer to that of the product owner. Perhaps a transition to PO will feel more natural and you should choose another team member as the SM.
This is important: Don't forget to empower
the new roles, coach
people, and make the whole team take ownership of the results
Run a sample sprint.
The best way to teach Scrum concepts and help people improve their skills is to get them into the practice. Also, a well-formed sprint will help you gain trust from the stakeholders and relax the project environment. Run a sample sprint with real work items and use it as a learning exercise and team-building experience. I suggest a two-week sprint to energize the transition and show results to stakeholders in a short time. However, you could choose any sprint length that works for the team.
The previous steps just set the stage for the transition into a project driven by Scrum, but you must keep it alive by using such standard Scrum practices as: