Scrum in a validated environment

One thing has become crystal clear the last couple of days:
Using Scrum in a validated (Pharmaceutical) environment requires a somewhat different approach.

In a validated environment a number of documents, that are normally not required in Scrum, have to be delivered. These documents, Functional specifications, Risk Impact analysis, … are artifacts from the classical approaches. The solution we came up with is to have a task in each single sprint that states updating these documents. This way, after every Sprint, the documents will be updated, and thus the documents will be finished after the last sprint, ready for acceptance by the Business.

However, this is not the biggest challenge in a validated environment. The people working with these projects are used to doing everything by the rule. Using Scrum, we bend the rules a little bit. For example, we don’t have the Functional Specifications signed off by the business prior to the development phase. This makes some people very nervous. Every day I realize more that this project will be more about coaching the team towards Scrum, than focusing on my task as Scrum Master.

We have started writing User Stories, this makes the analysts feel uncomfortable. They want to have everything defined up front, but that is not what User Stories do. They will have to wait until the first Sprint Planning meeting to get the details. This first meeting will be on the 1st of October …

Scrum, getting started…

These are my first days as Scrum Master.
The mission is clear, introduce Scrum in the Project and, at the same time, guide the Project Management Team to start using Scrum.

The first days on site it became clear that this is not going to be Scrum from the book!

A Scrum project starts with defining the Product Backlog, which comes from the User Stories, defined by the business. This concept is well known over here. It’s the way they do it that makes it special.

Writing the User Stories will be done as a Scrum project, a Scrum project within a Scrum project so to speak. Maybe not even a bad idea to start out with, but …
What about priorities? You cannot label a User Story as less important; they all have to be written before they can be prioritized.

The area’s for which the User Stories have to be written are defined, and it is also defined which area’s get priority. This way, three priorities can be defined
1. The stories that have to be ready before end September;
2. The stories that have to be ready mid October
3. The stories due after mid October.These represent 20% of the functionality, and are less important.
Thus we will start with the first priority User Stories; these have to be done by end next week, that is a short Sprint …