Scrum in project business

Scrum is for product development. Check. There is the Product Owner, the Product Backlog and the Product Increment. Check. There is no project in the Scrum framework. Check. But…
What does that mean for all the service providers that are in the project business? They develop whole software systems and single features for clients. Therefore they face a broad range if project sizes: months or years with complete teams as well as one to ten days for a single developer. Therefore one of challenges for these companies is the so called resource management: How to staff all the projects and how to ensure that everybody is working on paid tasks.
When applying Scrum to these contexts I recommend to ignore the Scrum framework for a while and think about the Scrum core. That is – in my humble opinion: a cross-functional team with end-to-end responsibility that applies inspect&adapt to the what and the how of their work.
Therefore I suggest to start with the team and not the project: form long term stable teams and reorganize work so that it matches the team concept. Every team has its Product Backlog with all the thing they plan to deliver. These may be features of a larger development project mixed with single feature requests. Assign a Product Owner and ScrumMaster to each team or even better let the teams self-select Product Owners and ScrumMasters.
E voila: Ready to start with Scrum for projects and a lot of new options will occur. The teams could take over additional responsibilities like writing the offers, managing customer relationships, hiring new team members etc. Be prepared to be surprised.

References

• Tobias Mayer discussed the cultural aspects of projects vs. teams: Team Culture, Project Culture.
• Karl Scotland suggested to favor teams over projects in Kanban, too: Linking Flow, Value and Capability.
• Jurgen Appelo says it is short-sighted to organize cross-functional teams around projects: „Teams“ (The Same Mistake All Over)