Effective scrum requires its participants to play certain roles and Bloomy’s scrum process is closely based on industry-standard scrum practices. A Bloomy scrum team consists of two to four Bloomy developers and one member of the customer’s team. The customer’s team member acts as the product owner, while the Bloomy team includes at least one scrum master and one developer. Both Bloomy and customer stakeholders provide support throughout the process but do not play a direct role in the scrum.
The customer’s product owner drives the vision for each sprint. This individual decides which user stories form the scrum backlog and has complete control over prioritizing that backlog. The product owner acts as the sole point of contact between the Bloomy team and the customer and has a deep understanding of the problem domain on which the sprint is focused. For a successful scrum, the product owner must be just as invested in the project’s success as the development team, and just as committed to the scrum process as the scrum master—he completely buys in.
The scrum master ensures that the active participants respect the scrum process. This member of the Bloomy team works with the product owner and development team to ensure sprint success. He removes any impediments identified during the daily scrum meeting and, if a sprint falls short, the scrum master must correct course. At Bloomy we do not typically have enough scrum projects running at once to justify a dedicated scrum master. In our scrum process, the project lead engineer fills the scrum master role while also serving as a member of the development team. A comparison can be made between the scrum master and the coach of a team where, at Bloomy, the scrum master is more of a player-coach--like the great Fred Clifford Clarke.
Successful scrum requires cohesiveness and dedication within the development team. We keep the members of the development team constant between sprints for different projects, allowing the team to build history across multiple sprints and enabling them to more accurately estimate effort for future sprints. The longer the team stays together, the more accurate their estimates become. We also keep development team members fully focused on the sprint at hand. Given the nature of our consulting business, allocating a team of people to a single project for two uninterrupted weeks can be difficult, but we address this challenge by running two scrum projects in parallel and alternating two week sprints between the projects whenever possible. It is important to note that there are occasional exceptions to these rules; it may be beneficial to have a vision or embedded expert join the team for one two week sprint and then step away. This practice lets us leverage internal expertise as needed for consistent scrum success.