Here at cPanel, we use the Scrum framework to ensure an organized flow for each project. Recently, Chris, a Technical Product Specialist, asked Chad McCanna, our Scrum Master rockstar, to share some insight about why this works so well for cPanel.
“Chad, in your words, what is a Scrum Master?”
A Scrum Master is classified as a servant leader. They’re basically in charge of facilitating the development process and owning the Scrum framework. They act as a barrier between the product owner, stakeholders, and the team itself. They need to be the conduit through which all information passes, or at least be present during all conversations so that there’s no violation. For example, if you have someone’s manager acting as a product owner, there can be some influence there. The Scrum Master is there to kind of diffuse that, to allow the team to focus on their commitments; so yeah, they wear a lot of hats. In a nutshell, the Scrum Master owns the process and ensures that everyone else is able to do their jobs to the best of their ability.
“When you say “do their jobs to the best of their ability”, and then you state that you’re a facilitator of the development process, can you elaborate?”
Sure. If there’s an impediment, resolution is a big part of what the Scrum Master does. That’s necessary so that the team members can stay focused on their specific disciplines. Most teams have members from Documentation, Quality Assurance, Backend developers, and Frontend devs. So, for example, last week we had a situation where one of our QA members was unable to connect to the build server, so I had to go pound the pavement to find out who runs our VMWare Manager. I got the issue resolved, and they were able to move onto something else during the hour and a half that it took me to deal with that.
I basically jump on the grenade so that the team can stay focused on what they’re doing.
“The Scrum process is fairly new to cPanel itself, being implemented a little over a year ago. So how has the Scrum process bettered cPanel as a whole over its previous Waterfall adaptation?”
What you get with Waterfall is a lack of transparency, and a bottleneck. You might have five projects that developers just throw over the fence that land in QA all at once, and there’s just no way they can deal with that. By having a different QA representative on each team, they become smaller, focused, and fully functional development units. Scrum is an iterative process, so every two weeks there’s a deliverable; it makes it very easy to course correct if something’s not going correctly. In the worst case scenario, we have wasted two weeks. In the past, there was very little oversight into the process. Six months could go by and there’s something completely unusable because there were far fewer checks and balances. Scrum emphasizes quality over speed, but by organizing through Scrum we’ve actually increased our speed quite a bit. We’re now doing three releases a year by not focusing on targeting individual projects for specific releases, but rather focusing on making sure their development is complete. Previously, we had one release each year or so… and sometimes as long as every 18 months. Now, if something isn’t done in time for the upcoming release, it’s simply held for the next release. There’s just a four month lag with this release time table. By adhering to this release schedule, our customers are aware of that – they can expect & plan for another roll out in four months, and it just makes it much easier for everyone. There are no surprises, and it prevents the QA process from being short circuited, which was a big concern as well.
“Do you find that the change from the previous development process was difficult, or was it an easy move?”
Scrum is painfully bereft with acronyms – we call subject matter experts “SMEs”. For example, the Backend team member is your Perl SME, and you want that person to be an authority for that segment of development. However, you don’t want them to feel as though they’re pigeon-holed into just that. Over time, if you get people comfortable sticking their toes into another discipline, then the team doesn’t grind to a halt if someone’s out for a week. It may slow down, but that way you can let others pick up some of the slack.
“What’s the name of your current Scrum Team?”
I’m currently the Scrum Master for Team Cobra, which is working on a number of projects concurrently. They’re a ridiculously high-performing team that embodies the phrase “controlled chaos”. One of our projects is SSL improvements, to bring in SNI and ultimately Wildcard support, along with some infrastructural improvements to the way we store SSL constructs. We’re also working on a UI-driven API Shell that will make third party developers’ lives much easier, and a Restricted Restoration system that allows you to specify whether you trust an account backup for unrestricted restoration, or would like it to be put through a sanitization process to get rid of potential exploits.
“Roughly what are the sizes of cPanel Scrum teams, and who do they consist of?”
Traditionally each team will have a Perl Developer, UI Developer, Documentation member (who oversees all the copy for the online documentation, website copy, and man pages), and then of course Quality Assurance. They write the functional testing that’s done throughout the development process, as well as included into the test suite for automated testing of the product.
The number of people included from each discipline ultimately depends on the needs of the project. For example, the RPM project was very backend heavy, with an almost nonexistent UI component. We had three Backend devs, one Doc, and a single QA. The SSL project is very rooted in improving the end user experience. We currently have two UI devs on that team, one of whom, Felipe Gasper, is currently filling in for both Backend and Frontend. He’s well versed in Perl, and able to pull double duty to help out our Backend devs.
“So the Scrum Teams often do demos of what they’re working on, which is fantastic because it allows all members of the company to join and find out what’s coming. How does this incorporate into Scrum within cPanel?”
Most teams run an internal pre-demo, specifically for the Product Owners to sign off at the end of each sprint on which individual pieces of functionality meet their acceptance criteria. That’s the final check before something is considered complete. When it gets to that point it will have passed by QA, and it will have gone by two pairs of developer eyes for code review. Each department has their own standards which the SMEs are tasked with upholding on their respective teams.
The outward-facing demo occurs at the end of each sprint, and allows the team to show off the sprint’s work in a comprehensive way, providing an opportunity for input from outsiders. During the course of each sprint, the product owner is interfacing with these stakeholders, gathering information on what they want to see. These stakeholders are both internal and external – for example: the Forums and Feature Request System. That is an ongoing conversation, that’s then formalized during the demo.
“Final question: How do you enjoy being a Scrum Master?”
For my personal workflow, working on a lot of things at once is actually enjoyable. It is its own sort of problem solving. I could be helping someone with a technical issue, and then having to deal with some communication barrier if someone’s working remotely. It’s a lot of stuff to juggle all in one day, which is compounded when you’re dealing with multiple teams, or in my case prepping teams for new Scrum Masters. It’s also great overseeing the Scrum process and sort of being an authority on that for any team members that may have questions or issues that might come up.
Also, I love seeing what cPanel is working on. It’s a company that’s always trying to be on the cutting edge of what our customers want, and what the industry as a whole needs. To see that in active development, to see, and in many cases facilitate, the foundation being laid for a large segment of the Internet, is incredibly interesting and a lot of fun.