To be successful with Scrum in the long term you need more than the basic framework. This is intentional. Scrum provides the structure as a starting point, but it’s designed to work well when applied with other effective patterns.
Like the Design Patterns movement of the late ’90s, a pattern can be used by itself or with others. E.g. the Command Pattern and the Memento Pattern can be combined to build an effective undo/redo system. Scrum is only one pattern for one team. It gives you the bare minimum framework that could possibly work, however in many contexts you will need to incorporate other tools/patterns to build more effective systems.
Beyond Scrum you should consider:
– Effective Agile Engineering Practices – such as Unit Testing, Continuous Integration, Test Driven Development, Acceptance Test Driven Development (or BDD), Pair Programming. Without practices like these, the health of your codebase will degrade over time.
– Kanban – (a tool to understand and improve flow) to help understand the flow of work at both the team and organization level. Without a good understanding of flow of work through the organization, we might make a change that is a local improvement but harms the whole. (Part 1: Visualize Your Work | Part 2: Limit WIP, Measure and Improve)
– Portfolio Management – the art of making big picture decisions about which major chunks of work the business would like focused on next. Organizations need portfolio management to ensure that major priorities are understood by the team’s Product Owners and worked on in priority order. (Part 1: Portfolio Management | Part 2: Idle Teams)
– Organizational Improvement – many issues that Scrum helps to find can’t be solved by the team or their ScrumMaster. Instead, organizations need to establish an ongoing improvement team dedicated to resolving these problems. (Part 1: Taking Organizational Improvement Seriously | Part 2: Case Study)
– Intra Team Coordination – How will you coordinate the work among teams? Scrum of Scrums is the most well known pattern and yet is rarely the best choice.
– Team Organization – How will you organize your teams? As Component Teams? As Feature Teams? Using the Spotify model of Squads, Tribes and Guilds?
There are no best practices.
Scrum itself could prescribe all of this, but that would be missing an important Agile point: there are no best practices. A practice that works well in one organization (or context) may not work well in yours. This is especially true when it comes to working effectively at a large scale where repeatable patterns are only just starting to emerge. Even where consistent patterns are starting to emerge (i.e. Large Scale Scrum, Enterprise Scrum, …), it is often unclear which one will apply in a specific context.
Finally, remember that Scrum isn’t intended to fit your current organization and its existing structure. It is intended to force us to consider what is working and what needs improvement.
Scrum is just the starting point.
In the next few months, I will explore patterns that can be effective when attempting Scrum at a larger scale (more than three teams). What topics would you like me to explore?