Scrum

Lightweight Management Process

Scrum is a lightweight management process. It was adapted for software development from "The New New Product Development Game", which described The Toyota Production System.

Scrum is typically associated with software development, but some companies have taken it further and claim that Scrum works everywhere.

The reason that Scrum can work beyond software development is because Scrum is a lightweight management process. Scrum itself does not embody agile values, principles, and technical engineering practices.

That needs to be emphasized: Scrum is not agile. Scrum is lightweight.

Because Scrum is a lightweight management process, it can be very complimentary to agile software development.

The Scrum Guide (it's free!) by Schwaber and Sutherland fulfills the management aspects for a project, but delegates the agile engineering practices to the development team.

Scrum as a lightweight management process consists of roles, events, and artifacts.

Roles are: scrum master, product owner, and the development team.

Events are: planning product backlog, dev team planning sprint backlog, daily scrum stand-up, sprint review, sprint retrospective.

Artifacts are: product backlog, sprint backlog, increment of the business value added to the product at the end of the sprint, and sprint burn-down chart.

Not Scrum

Sometimes Scrum goes awry. Where do things go awry?

Scrum becomes "not Scrum" when the Scrum process isn't followed. SHOCKING!

In my experience, these are the critical parts that are not followed, which makes Scrum not work:

fancy, expensive Scrum tools - Kelly Waters (see link below) explains why you want basic and effective tools for Scrum, rather than frilly Scrum software that is efficient but harmful to individuals and interactions
no full-time scrum master - without a scrum master to manage the process, the process will be adrift
scrum master is not considered a management position - scrum master does not manage people, the scrum master manages process ... and that is a management position
lack of training for the product owner, the scrum master, and/or the development team - the new process may be simple, but it ain't easy; sure-est way to kill Scrum is to tell everyone "do Scrum" but not train them
no single individual as the designated product owner - too many bosses making product decisions results in paralysis
development team is not empowered to make technical decisions - if the development team cannot decide which version control system to use, which programming language to use, which agile engineering practices for the team to embrace, where the curly braces go, tabs or spaces, yada yada yada
facilities are not set up such that they facilitate team dynamic - the development team needs to be focused on the project, and facilities is the EASIEST thing to set up when adopting Scrum, yet some companies neglect this simple but vital step for the team to have a war room, to have cubes or offices that have a shared common space. (Teams that are not co-located will face additional challenges, but not impossible.)
corporate antibodies undermine Scrum as a management process - here's where the scrum master and management support can grapple with other departments who are disrupted by the change in management process to Scrum. And without a full-time scrum master to wrestle with these issues, the corporate antibodies will force the project to fallback to previous management process practices.
development team gravity, organ rejection, backsliding into the comfort zone of old ways
project management office (PMO) at odds with Scrum as a lightweight management process - the scrum master, once again, should act as a liaison with PMO. But if there is no full-time scrum master, or if the scrum master is not yet experienced and is learning the ropes, making an adversary of PMO is bad, and PMO should be an ally.
lack of corporate commitment - if the company is not committed to supporting, embracing, and transitioning to Scrum, then it is doomed; corporate antibodies will flay it alive
Scrum is flexible! - some people hear the message that Scrum is flexible, and you can do whatever you want. So what they do is torpedo the Scrum management process from the onset. The flexibility in Scrum does not give license to not do Scrum under the pretext of doing Scrum. The flexibility is in it being a lightweight management process, and that the development team is empowered to make technical decisions and employ agile engineering practices.

Who is PMO, anyway?

For larger corporations, PMO acts as the monitor for all projects in the company on behalf of the executives.

For a smaller company, that responsibility may be on the shoulders of a single executive. The CEO, the president, or a VP.

Their ultimate responsibility is to decide which projects are funded, how well those projects are doing (green light, yellow light, red light), if a project is in trouble, and if a project should have additional staff, destaffed, or cancelled.

They inform the executives, who then make the hard decisions.

So having PMO on board with a project is critical for the success of the project, regardless if Scrum or some other management process is being used.