Scrum is not prescriptive. It is adaptable.
Scrum has simple rules — perhaps too simple for some. The basic guidelines are provided at ScrumAlliance.org in an article called Scrum Is an Innovative Approach to Getting Work Done.
Beyond the basics, Scrum can get very complex, very fast. (Actually, the same is true of any process. For example, walking up a flight of stairs is simple, right? Now what if you are on crutches, it’s a spiral staircase, and you have to move a 50-pound television up with you? Not so simple now, is it?)
Staying true to the simple Scrum guidelines becomes more and more difficult as software systems become increasingly complex and the teams needed to build them get larger. Here is a shortlist of ideas that might help even if they break some of the basic principles of Scrum.
- Start with Sprint zero to build up the product backlog; prepare the development environment; and get the team prepared for the project.
- End the release cycle with Sprint n+1 to wrap-up loose ends and package the final release build.
- Keep the UX design team one sprint ahead of development team. This gives the UX team a head start in prototyping the UI and soliciting user feedback.
- Keep the system integration test team one sprint behind the development team. This provides the test team with more time to thoroughly test the software and perhaps more importantly, time to fully automate the tests.
- Introduce a few Lean concepts to limit work in progress and minimize the number and type of artifacts generated (e.g. limit the number of items “almost done” and the volume of metrics generated).
- Leverage elements of Kanban to manage work queues and maintain a steady supply of work waiting to be done (e.g. keep a list of tasks that can be done as time allows but are not critical to the project).
- If your work environment and culture demand extensive documentation and related artifacts, have someone outside the team (a chicken) prepare and deliver those documents. Don’t bog down the team with these activities.
The important point is that the simplicity of Scrum lends itself to adaptation. Don’t be purist and don’t reject Scrum because it is missing some element that your situation demands. Use your imagination. Please share your ideas.
Sorry, but all the things you mentioned are “fixes” for not doing Scrum properly. Remember Scrum uncovers areas that need improvement…improving those areas by changing your implementation of Scrum limits the value that could have been realized for the moment and for the future. Then after that your not really doing Scrum 🙁 …..better to fix the real problem..your practices, environment ,tools, etc.
You’re right, Kim. The core issue is that some cultures are simply not prepared for doing Scrum properly. Sometimes you have to compromise to get things done and that may mean adapting Scrum to the culture.