In my previous post, I talked about the greatness of Consultancy Scrum. One month later and I’m still happy with the decision to implement it and then adjust the methodologies to fit stable|kernel. The major adjustment mentioned previously was that we don’t do Scrum.
One of the reasons we don’t is that our small teams find the rigors of doing it according to the Scrum Guide time-consuming. A team of two or three developers, our designer and myself don’t need to spend four hours in planning meetings to determine the sprint goal and the sprint implementation. We typically determine the sprint goal in a quick mini-version of a planning meeting and save implementation details for time spent pair-programming, or during a conversation while playing darts.
The second large reason is that we usually work with a fixed deadline on a fixed set of requirements; our clients’ budgets and timelines are fixed before they partner with stable|kernel to deliver software. Perhaps the client wants to debut the software at a company event or industry show, or they need a specific functionality to achieve their immediate short-term goals. In order to deliver the work the client needs, we may work in a purely incremental fashion with shorter sprints and more rigid requirements. While not ideal, each sprint blends working to complete a new increment with applying feedback from the Product Owner on the previous sprint. Working in this method sometimes makes our increments smaller, but it assures the client receives suitable work in the time frame available.
The final reasons are that our tools, automation and collocation render some of the rituals unnecessary. These tools remind us daily what everyone worked on the day before and what the plan is for the current day. Viewing this information lets us identify and even anticipate possible blockers to remove to make the project a success. Overlapping time in the office allows the internal team to easily collaborate while Slack keeps the team in immediate contact with both internal and external members.
I am a supporter of Scrum in the right environment. I am a Certified Scrum Master and active in the local Scrum community. I read about companies doing “Faux Scrum” or “Scrum but…” and, through a certain lens, stable|kernel could be seen as doing the same. With pride though, I declare that stable|kernel uses “NOT SCRUM” while being committed to not declaring “Scrum Never”. When stable|kernel has the right project, right team and proper needs, we may use Scrum, but today it isn’t the correct tool to pull from my box.
