Its Not About Scrum

This piece the one of many in a series aimed at helping teams and companies rethink and improve their processes, reorienting it toward a product / customer centered approach. Look for more posts in the future that contain pragmatic ways to move from a primary focus on process to a more essential focus on products and customers.

It’s Not About Scrum, It Never Has Been …

For years, I have been hearing how well people and teams think they are “doing Scrum”. Last week, someone new to Scrum was telling me what I did not understand about a process I learned about in 2002 from Ken Schwaber. In both cases, the people are excited by the idea of something they can connect with or attach to. In 2018, it is high time to ask if it is responsible to be helping people bond around process and practices over bonding around product and results.

In full disclosure, I’ve never been a big fan of Scrum, but my disinterest is not about Scrum. I find any movement where the dogma transcends the value to be uninteresting. From art to politics to philosophy, and now software, movements often seem to start strong, fostered by rebels wanting to improve on the status quo only to become the champions of the very stagnation they once fought to change.

A few years ago, I gave a talk where I looked back to learn forward. Drawing on my experiences, I said he 1990’s were the decade of project, the 2000s were the decade of process, and the 2010s are the decade of product.

The Time Where Projects Ruled

In the 1990s, the triangle of time, scope and budget was the guide for many a project manager. Getting a project done, “on time, on budget, and within scope” was deemed successful. Today that seems odd if not naive or even dumb. It’s like saying the goal of a soccer team is to finish the game on time, or to say that the primary goal of surgery is to get done on time. Would you want to be the one to tell the patient that all the surgery could not be done due to timeboxing, and not to worry as the other work will have in a series of future surgical sprints?

The first time I heard Ken Schwaber talk about Scrum, it was presented as a framework that you will need to modify for your company. At the same conference, XP 2002, Mary and Tom Poppendieck talked about Lean as a tool kit. I was a diligent XPer who had written a paper about scaling XP by creating a “company customer” who could help customer needs that span individual XP teams.

XP 2002 was a few hundred rebels at a hotel in Alghero (Italy), all with ideas, experiences, and a thirst for moving away from project land and into something new. That something new was a collection of various processes that fostered collaboration, increased rates of learning, fostered visualized learning, and more. XP also had a set of practices and values around producing code that was collectively owned and well organized through test driven and refactoring.

A New Era of Process Starts (Again)

One year earlier, many people from the XP conference inked the Agile Manifesto. They were trying to sum up and synthesize their rebellious ideas. Like the XP conferences, there were pockets of people around the world starting to move from project to process. Some were makers, some were seekers, and some were methodologists, the latter being in the camp of disinterest to me. They gave wings to what became the decade of process.

These new methods were lightweight. Like the rules for soccer, the first few books on the various methodologies were short and light. Scrum, XP, and Lean text were in the 150 – 200 page zone. They were not like the 450 page book on Lean that I would be told I had to read some ten years later, the irony of which is unmistakable.

For those who took the ideas as guides and not doctrine, the practices were tools used for higher purposes: building systems that could adapt, helping people collaborate, and being customer centric. Like a soccer team, the rules were guides but the goal was to have fun, improve your skills, and win, especially if you’re on a professional team. For the people who preferred doctrine over value, or dogma over learning, prescriptive mantras like “Scrum but …” led them further down the path of getting better at doing Scrum over helping customers, users, and consumers of their product.

So if things were all marvy, and these new processes were lightweight and simple, why am I still meeting people who are talking to me about “how to do Scrum”? Sure, many people I meet today do not have the history listed here, but they are not telling me about how well they “do internet” even though they did not create the internet. It, like process or the rules of soccer, is just a tool that is a means to an end not an end unto itself.

Like the RUP movement that Agile replaced, some people are stuck in the way they know and may not move out of the decade of process. Others are just new, and need mentors to teach them that, once again, process is not the entire meal, it’s just a small part.

In the Time of Product

Increasing confidence in the ability to iteratively deliver, learn, and adapt came from the pragmatic use of the new ideas from the 2000s. Teams, and collections of teams, integrated code sooner, released more often, and learned that getting work done could be complicated but need not be complex.

Teams able to release more often were also able to see the fruits of their work sooner. While some focused on units of work completed, others focused on the results of their efforts. The latter group, where I often found myself, tended to focus more on people over process, a neat idea that was lost by people who fell into the “Scrum but …” crowd. I also found that I was drawing a new triangle (for the triangle oriented folk): products, people, and process or technology, teams, and customers.

< insert new triangle image >

While it was a great feeling to see things getting done, doing the wrong thing was not so wonderful. More of the wrong thing completed by more and more teams was not more of a good thing, no matter how fast they could deploy, how well their code was structured, or how many automated tests were run for each build.

The new question was not “How much can we get done?” but “How wrong were we?” In the decade of project, and sometime in the decade of process, progress was success because it was less common and less visible. Once progress became more known, and more consistent, product became the new challenge.

For the people ready to move forward, the importance of learnings from the 2000s are meaningful but secondary, or parallel to the importance of learning about customer, product, and market impact. If you establish a sustainable eco-system where people collaboratively get work done, you now have more bandwidth to focus on doing right by the people you impact. This might be in the form of customers using your products and services or people investing in your passion and skills.

Onto the Land of Continuous Product Learning

To end on a concrete note, a few years ago, I asked a few smaller teams to try something new, something that required new ways of thinking and working that would feel different. Building on test driven, a practice that can help produce more adaptive code, and acceptance test driven, a practice that helps people collaborate around what the expected user experience should and should not be, these teams adopted impact driven.

The same way the other test driven practices challenged people to have measurable outcomes before starting their work, this simple practice asks people to have measures of impact before starting their work. For a programmer, this might be in the form of an analytics measure added before starting to code, challenging the programmer to embrace the expected impact (outcome) when the code is deployed. For a designer, this challenge is around the impact of their design that prevents making it cooler (for the designer) instead of making something that is better (for the customers).

This simple practice is easy to teach and easy to learn. But simple things are not always easy to do. Like the rules of soccer, impact driven as a guide challenges people to stay inside a guide that is results oriented. Harkening back to the roots of all the agile stuff, the people who inspired me were never overly focused on the rules, once they explained the rules to me. The rules, the process, was the easy part. The product, and meeting or learning about the customer needs is the harder, or better put, the more ambiguous part.

Look for more ramblings about continuous product learning, the evolution of product agility and more in the near future.