Scrum
“Scrum is just this tiny set of rules that identifies problems. Your job as a team is to solve those problems, drawing solutions from any and all disciplines that can assist you.” – Ron Jeffries
Scrum fails for 3 typical reasons:
- There is an expectation it tells you how to build better products or software. There isn’t (and never has been) any guidance on software or product development techniques in Scrum. It doesn’t even tell you how to really interact with customers or shape requirements.
- It shows you all of your problems and dysfunctions. If there are problems in your organization between business people and technology people, Scrum will highlight it. If goals are not clear or direction is not well understood, Scrum will show you. If your engineering standards or product quality isn’t good, Scrum will bring it to light. The frequency of planning, feedback from customers and business partners, and the need for flexibility helps everyone better understand the issues you need to address.
- It doesn’t fit into all contexts in a business. It was originally designed for new product development in a small software product company. It was a great mechanism to connect the users, senior stakeholders and developers in small environments. It was never designed for thousands of people all working on the same thing. It wasn’t designed for operations. It wasn’t designed for HR change initiatives or marketing. It doesn’t mean it can’t be adapted, augmented and refined for all of these things; it just means some creativity is required to make it fit into different contexts.
Scrum is great. It’s a beautiful framework that allows you to learn quickly, improve quickly and deliver quickly. But, it doesn’t solve everything without work, effort and adaptation of the values, principles and techniques.
Consider
Do you have realistic expectations and are you using the right tool for the right job?