Sarah Gray
Caktus began the process of adopting Scrum mid-November 2015 with two days of onsite Scrum training and fully transitioned to a Scrum environment in January 2016. From our original epiphany of “Yes! We want Scrum!” to the beginning of our first sprint, it took us six weeks to design and execute a process and transition plan. This is how we did it:
Step 1: Form a committee
Caktus is a fairly flat organization and we prefer to involve as many people as possible in decisions that affect the whole team. We formed a committee that included our founders, senior developers, and project managers to think through this change. In order for us to proceed with any of the following steps, all committee members had to be in agreement. When we encountered disagreement, we continued communicating in order to identify and resolve points of contention.
Step 2: Identify an approach
Originally we planned to adopt Scrum on a per-project basis. After all, most of the literature on Scrum is geared towards projects. Once we started planning this approach, however, we realized the overhead and duplication of effort required to adopt Scrum on even four concurrent projects (e.g. requiring team members to attend four discrete sets of sprint activities) was not feasible or realistic. Since Caktus works on more than four projects at a time, we needed another approach.
It was then that our CEO Tobias McNulty flipped the original concept, asking “What if instead of focusing our Scrum process around projects, we focused around teams?” After some initial head-scratching, some frantic searches in our Scrum books, and questions to our Scrum trainers, our committee agreed that the Scrum team approach was worth looking into.
Step 3: Identify cross-functional teams with feasible project assignments
Our approach to Scrum generated a lot of questions, including:
- How many teams can we have?
- Who is on which team?
- What projects would be assigned to which teams?
We broke out into several small groups and brainstormed team ideas, then met back together and presented our options to each other. There was a lot of discussion and moving around of sticky notes. We ended up leaving all the options on one of our whiteboards for several days. During this time, you’d frequently find Caktus team members gazing at the whiteboard or pensively moving sticky notes into new configurations. Eventually, we settled on a team/project configuration that required the least amount of transitions for all stakeholders (developers, clients, project managers), retained the most institutional knowledge, and demonstrated cross-functional skillsets.
Step 4: Role-to-title breakdown
Scrum specifies three roles: Development team member, Scrum Master, and Product Owner. Most organizations, including Caktus, specify job titles instead: Backend developer, UI developer, Project Manager, etc. Once we had our teams, we had to map our team members to Scrum roles.
At first, this seemed fairly straightforward. Clearly Development team member = any developers, Scrum Master = Project Manager, and Product Owner = Product Manager. Yet the more we delved into Scrum, the more it became obvious that roles ≠ titles. We stopped focusing on titles and instead focused on responsibilities, skill sets, and attributes. Once we did so, it became obvious that our Project Managers were better suited to be Product Owners.
This realization allowed us to make smarter long-term decisions when assigning members to our teams.
Step 5: Create a transition plan
The change from a client-services, multi-project organization to a client-services, multi-project organization divided into Scrum teams was not insignificant. In order to transition to our Scrum teams, we needed to orient developers to new projects, switch out some client contacts, and physically rearrange our office so that we were seated roughly with our teams. We created a plan to make the necessary changes over time so that we were prepared to start our first sprints in January 2016.
We identified which developers would need to be onboarded onto which projects, and the key points of knowledge transfer that needed to happen in order for teams to successfully support projects. We started these transitions when it made sense to do so per project per team, e.g., after the call with the client in which the client was introduced to the new developer(s), and before the holder of the institutional knowledge went on holiday vacation.
Step 6: Obtain buy-in from the team
We wanted the whole of Caktus to be on board with the change prior to January. Once we had a plan, we hosted a Q&A lunch with the team in which we introduced the new Scrum teams, sprint activity schedules, and project assignments. We answered the questions we could and wrote down the ones we couldn’t for further consideration.
After this initial launch, we had several other team announcements as the process became more defined, as well as kick-off meetings with each team in which everyone had an opportunity to choose team names, provide feedback on schedules, and share any concerns with their new Scrum team. Team name direction was “A type of cactus”, and we landed on Team Robust Hedgehog, Team Discocactus, and Team Scarlet Crown. Concerns were addressed by the teams first, and if necessary, escalated to the Product Owners for further discussion and resolution.
On January 4, 2016, Caktus started its first Scrum sprints. After three months, our teams are reliably and successfully completing sprints, and working together to support our varied clients.
What we’ve learned by adopting Scrum is that Scrum is not a silver bullet. What Scrum doesn’t cover is a much larger list than what it does. The Caktus team has earnestly identified, confronted, and worked together to resolve issues and questions exposed by our adoption of Scrum, including (but not limited to):
- How best to communicate our Scrum process to our clients, so they can understand how it affects their projects?
- How does the Product Strategist title fit into Scrum?
- How can we transition from scheduling projects in hours to relative sizing by sprint in story points, while still estimating incoming projects in hours?
- How do sales efforts get appointed to teams, scheduled into sprints, and still get completed in a satisfactory manner?
- What parts of Scrum are useful for other, non-development efforts at Caktus (retrospectives, daily check-ins, backlogs, etc)?
- Is it possible for someone to perform the Scrum Master on one team and Product Owner roles on a different team?
Scrum provides the framework that highlights these issues but intentionally does not offer solutions to all the problems. (In fact, in the Certified ScrumMaster exam, “This is outside the scope of Scrum” is the correct answer to some of the more difficult questions.) Adopting Scrum provides teams with the opportunity to solve these problems together and design a customized process that works for them.
Scrum isn’t for every organization or every situation, but it’s working for Caktus. We look forward to seeing how it continues to evolve to help us grow sharper web apps.
