It says nothing about the way you should define requirements, build a solution or manage quality or defects. All it says is pick a time period and deliver to that cycle while applying a systematic approach to intra team communication.
I know scrum works as a “get things done” approach because I have used it as a framework to help at least 2 non IT businesses achieve a set of goals.
Let me give a bastardized description of scrum that is complete, accurate and in a language that the skeptical project manager will appreciate.
- Start with a goal. Break down the goal into incremental steps.
- Discuss the steps with the team who needs to deliver the solution.
- Set standard time boxes. Do your best to deliver something practical and useful each time boxed iteration.
- The team needs to take instruction from the customer at the beginning of each iteration and report on what got ‘done’ at the end of each iteration.
- The team must set aside a portion of time at the beginning of each iteration to plan their work.
- The team needs to set aside a regular and brief portion of each day to communicate progress and problems to one another.
- The team needs to commit to continuous improvement and should set aside a portion of time each iteration to reflect on what went well, not well and where they can improve.
- The planning, review and reflection sessions, and the daily team update all need to be set at regular times to help the team achieve a sense of rhythm.
That is scrum, complete and in pragmatic terms and there is nothing software centric about that process.
And that is why most software scrum teams have also adopted quality management processes, especially XP to help get things done, and done right.