The Sauce Journey – Shu Ha Ri

August 25th, 2016 by Joe Alfaro

If you’re attempting to implement an Agile/Scrum development process where none has existed before, you will surely an encounter a moment of frustration on the part of your developers. “Why do we have to do these standups?” “I don’t understand why we need to assign story points, can’t we just get to the projects?” “Where is my technical specification?” Like Ralph Macchio in The Karate Kid, your developers may wonder why you have them doing the engineering equivalent of “wax on, wax off,” when what they really want to do is get into the fight. What Ralph Macchio eventually understands is that the performance of rote, rigid external exercises is a first step on the road to internal mastery, a process well known in the world of martial arts as Shu Ha Ri.

In its broader definitions, Shu Ha Ri describes a process of learning: in the Shu stage, the learner follows directions literally and adheres rigidly to whatever rules the teacher has set. In the Ha stage, the learner begins to see how the rules and directions can be adapted for specific situations, and exercises some judgement in how they should be applied. In the Ri stage, the learner has developed her own techniques, and now innovates freely as the situation demands. (more…)

The Sauce Journey – “Forming, Storming, Norming, Performing”

July 21st, 2016 by Joe Alfaro

A few years ago, while working elsewhere, I came upon a scene of two engineers literally screaming at each other over the top of their cubicle walls about some aspect of a project. “Oh good,” I thought, “they’ve reached the storming stage, things can only get better from here.”

As I talked about in my previous post, forming Scrum teams leads to emergent behavior on the part of individuals as they adjust to the new regime. The same is true of small teams; once formed, the way in which individuals interact with each other tends to undergo a sequence of changes as well. The behavioral scientist Bruce Tuckman labeled these stages as Forming-Storming-Norming-Performing. As unpleasant as the transitions from stage to stage might be, all teams must progress through them in order to reach the point where they are truly self-managing.

In the forming stage, teams cohere in relation to external influences, like goals and tasks, but tend to remain focused on themselves as individuals. This is reinforced in the way that we typically constitute technical teams, where each person is recruited for their individual technical strengths. Forming is typically a stage that is driven by intellectual and analytical considerations, since it focuses on defining the project, identifying tasks, and assigning team members who can fulfill them. (more…)

The Sauce Journey – Emergent Leaders

June 21st, 2016 by Joe Alfaro

In my last blog post I wrote about the way in which moving to SCRUM teams fosters communication, transparency, and trust, both internally among team members, and externally with customers. Achieving open communication like this is one of the main goals of Agile, but just as important is the development of leadership within the SCRUM teams.

Ideally, every SCRUM team is self-managing in regards to their own work. The Product Owner determines what will get done, the tactical decisions about how it gets done should be left up to the team. There is a simple philosophy behind this: those whose work focuses on a specialized area of the product know better how to improve it, and how much work will be involved, than anyone from outside of that group. The product owner within the team is there to advocate for the customer, and to decide when a minimally viable product is ready for release, but they don’t tell the team what to do or how to do it. (more…)

The Sauce Journey – Courage, Transparency, Trust

May 25th, 2016 by Joe Alfaro

In my last blog post, I described the first step on our journey from Engineering to DevOps, which was the formation of project-focused SCRUM teams. SCRUM brings many opportunities for improving the development process, but it’s wise to keep in mind the old saying “SCRUM doesn’t fix problems, it points them out.” This means that the very first thing to emerge from SCRUM is transparency, because it requires us to examine how our teams and processes actually function on a day-to-day basis, and through ceremonies like stand ups and retrospectives, we are asked to clarify our goals and purposes to our colleagues, our customers, and ourselves.

The essence of SCRUM ceremonies is communication, and communication leads to transparency. In standups, making a statement about what you plan to do that day, and what is blocking you, provides a simple way to bring transparency about your work to your team. But it also forces you to be introspective, to be clear to yourself about what you are doing, what the blockers and issues are, and what it is that you can accomplish. More than anything else, stand ups are opportunities for reflective communication that surfaces problems at the same that it seeks to resolve them and move the entire team closer to their goal. The same can be said of retrospectives, but here the emphasis shifts from internal to external communication. From the internal perspective, retrospectives are useful for documenting issues and how they were met, and then using that information for iterative improvement. But they are much more important for communicating to customers that we understand where our challenges are, and that we have ways to deal with them. (more…)

The Sauce Journey – From Star to Scrum

April 22nd, 2016 by Joe Alfaro

When I first started at Sauce, one group within the Engineering organization was called *Dev, referred to in conversation as “StarDev.” *Dev was so named because they were the wildcard development group – some of their work touched on this part of the infrastructure, or this part of the product, or this part of the Web interface, and so on. As a result of this interdisciplinary approach, much of the product and operational development fell under their purview, but it was difficult to tell exactly what it was they were responsible for. What was even more difficult was that when it came time to undertake actual projects, there was no clear delineation of what role *Dev needed to play in their development.

When you see the emergence of a group like *Dev, it’s a clear sign that your engineering organization has reached an evolutionary stage common to startups. That’s the stage where you go from a handful of people sitting in a room together hacking out code, to trying to formalize responsibility for parts of the product while also engaging other stakeholders within the company, like Product Management. The tendency in these moments is to think in terms of silos – this group is responsible for operations, this one for the front-end interface, this one for backend infrastructure, this one for testing, and so on. The problem with this approach is that it almost always results in organizational mutations like *Dev. because the nature of today’s software and technologies doesn’t recognize such neat distributions of responsibility. This is especially true of PaaS, IaaS, and other cloud-based offerings, that are themselves hybrid service/product offerings. I saw this phenomena occur when I took the reins at Lynda.com. Although the team had grown to more than 30 engineers, they could only work on one project at a time. The whole team “swarmed” on a given feature, since nobody owned any one piece of the service. The first change that I made was to organize the team into smaller scrum teams that each owned a feature from end to end. This simple reorganization unblocked the log jam that had been created by the swarm mentality, and allowed teams to work on multiple projects at once. (more…)

From Engineering to DevOps – The Sauce Journey

March 22nd, 2016 by Joe Alfaro

From Engineering to DevOps

DevOpsEvolution

I presented this cartoon to our development staff during a recent planning meeting because I think it’s a nice illustration of the progressive change in software engineering process over the past twenty years. While the cartoon portrays the change as evolutionary, it has also been revolutionary. Continuous development and continuous operations enable developers to deliver rapid iterations on their products in response to customer needs–meaning what previously took months to deliver can now be done in a matter of days or hours.

When I joined Sauce Labs a few months ago as the Vice President of Engineering. I knew I wasn’t signing on for your typical, run-of-the-mill engineering management job. Sauce Labs is a young company, working with a new technology, that is experiencing tremendous growth. With its roots in open source, and a strong ethos formed around supporting individual developers, Sauce Labs is evolving into an enterprise software company. In order to scale to meet the demands of large enterprise customers, the Engineering discipline at Sauce Labs would also need to evolve. So, I wasn’t just accepting a job, but accepting responsibility for leading the Sauce Labs Engineering team through this critical journey which can be challenging but also very rewarding. I’ve done this before at companies like Citrix Online, Lynda.com, and GoDaddy, so I went into this with eyes wide open for the journey ahead. (more…)