Should I provide my boss and team with documentation about the Scrum process?

Question

I have been chosen to be responsible for rolling out Scrum in my small 5 man software development team. I am also a developer at the same time.

I have experience being in a non-agile team and having it rolled out and I know Scrum favours interaction over process and documentation.

My boss has just emailed me and said he wants me to fully document the whole Scrum process for him and the team - this is something that doesn't sound needed or useful.

The team understands the basic process why do they need powerpoint presentations etc.

Answer 1

Full disclosure: I am no Scrum expert, nor do I use Scrum in my daily activities.

I get what you are saying, though. What may be beneficial to your team is creating a presentation that goes through real examples, and real pitfalls associated with the process. You could make this much more engaging than a drab design document or checklist. If you are really getting pushed for more 'official' writing, see if your boss would foot the bill for some assigned reading of a popular Scrum book.

However, I would say that if Scrum had no need for documentation, there wouldn't be books on it on Amazon ;P

Answer 2

The Scrum Guide is the official documentation of the Scrum framework. It is a non-technical document that addresses roles, goals, events, artifacts, and more. It is also a fairly brief read at about 13 pages of content.

If your boss wants to learn the basics of Scrum, there is no need to reinvent the wheel. I would recommend providing him a copy of the Scrum Guide, along with:

• When the review, retrospective, planning, and daily scrum meetings will be held
• Which employees will be product owner, scrum master, or on the development team
• Where the scrum artifacts will be stored or how the scrum artifacts will fit into an existing configuration management plan

It depends on your organization's level of documenting policies. A lot of our documentation of management policies simply cite the Scrum Guide for reference.

Answer 3

I would think it the same way as a requirement. When planning, everyone understands it, when implementing, all sorts of things can happen if you don't have a nice user story written.

Taken from one of the core practices of Kanban:

Make Policies Explicit: Until the mechanism of a process is made explicit it is often hard or impossible to hold a discussion about improving it. Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional, anecdotal and subjective. With an explicit understanding it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions.

So, when dealing with processes and requirements, I think it's better to have it nicely written down somewhere, and never assume that what you think is what everyone else thinks. And remember that no team come up immediately as a Scrum (or agile) team, it's needed some time until everyone interacts well with the process and start making documentations and other things obsolete, you can't just drop all docs next morning, even more if it's something new to your team.

Answer 4

Defining the Correct Roles

I have been chosen to be responsible for rolling out Scrum in my small 5 man software development team. I am also a developer at the same time.

This is an inherent conflict of interest. The Scrum Master role is a core role that is deliberately distinct from being a member of the Team. In my personal experience, agile projects that do not make this distinction often flounder.

Clarifying Goals and Objectives

My boss has just emailed me and said he wants me to fully document the whole Scrum process for him and the team - this is something that doesn't sound needed or useful.

In the spirit of Scrum, you need to clarify the objective. My personal interpretation is that you are being asked to provide the team with some training on the Scrum process and its associated roles. However, you will only discover the true objective of the task by opening a dialog with your boss.

It may be useful (and certainly very agile!) to create a user story for this particular task. For example:

As a functional manager,
I would like a developer to provide some initial Scrum training to the Team
so that we have a starting point for adapting the methodology to our environment.

A user story like this will make the manager's goal clear to the team, and provide some scope to the information that should be conveyed in the training. It may also help explain why the manager feels the training is needed in the first place.

Most important of all, the user story will start a conversation about what Scrum means to both the manager and the team. A two-way dialog is an essential part of Scrum; without that dialog, the team will miss out on the core value proposition of the Scrum process.