BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Interview with Tobias Mayer about the People’s Scrum and AgileLib

Interview with Tobias Mayer about the People’s Scrum and AgileLib

The people’s Scrum by Tobias Mayer is a collection of essays based on material written by him between 2005 and 2012.

The essays describe agile ideas and practices, examples of the topics covered are self-organizing, team working, craftsmanship, technical debt, estimation, retrospectives, culture and Scrum adoption.

InfoQ interviewed Tobias about the importance of people, teams and self organization with Scrum and about AgileLib.net, a new initiative for sharing agile resources.

InfoQ: Your book is called "The People's Scrum". Why emphasizing on "People", what makes them so important?

Tobias: Not just any people. This could equally have been called The Worker's Scrum. The title came from an old blog post of mine that confronted the increasing tendency of organizations to push Scrum on teams from the top down. Scrum works best (arguably it only works at all) if embraced by those doing the work, and is adapted to context in a meaningful, thoughtful and healthy way. Pushing any kind of process on a group of workers will meet with one of two responses: resistance or compliance. Both are antithetical to the collaborative spirit we seek in Scrum.

So what makes the workers so important? I think your readers will answer that for themselves :)

InfoQ: What in your opinion is Scrum (and what isn't Scrum)?

Tobias: Scrum is a set of empirically proven work practices based on some core human values and principles that are known to create open, trusting, creative environments. Scrum is not a process. It is barely a framework. It is often implemented as such, and this frequently causes pain. We do the What, without knowing the Why.

Learning Scrum is a process of unlearning bad habits picked up on (e.g.) MBA programs and from previous experience, but perhaps even more damaging—and more persistent—picked up from school as early as elementary level, where collaboration is called cheating and creative thinking is seen as subversive.

Scrum is not so much a thing, as a lack of things. It is the spaces in between. When we look at a tree, we see leaves. Less noticed is the space between the leaves—empty air, leaking light that gives shape to the leaves, that provides depth and color. Scrum emphasizes a reflective mindset. This might be seen as space in our busy work days—space between the command and the compliance. It is the pause for thought, where we can connect with our intuition and slowly shed our learned habits. Scrum, done well, allows people to move at a sustained, even a leisurely pace, and get more meaningful work accomplished.

InfoQ: In your book you mentioned the importance of Scrum teams. What makes team working important, can you elaborate on that?

Tobias: In Leonard E. Read's humorous essay, "I, Pencil, the pencil states "...not a single person on the face of this earth knows how to make me." Matt Ridley references this essay in his "When Ideas Have Sex" Ted Talk. The point is that something so simple as a pencil (or for Matt Ridley, a mouse) is actually deeply complex and requires many minds and many skills to create it. It is rare, if not unheard of for a single person to have all the skills necessary to create these objects. Likewise with software products.

There are essentially two solutions to this problem. i) work breakdown, and ii) team work. Our original strategy, borrowed from the factories of the industrial revolution, of having managers divide the work and distribute it to the workers may be a successful strategy for making pencils, but has proven to be a dismal failure in the knowledge work industry. Pencils are mass produced. Software is not. It is always new. Knowledge workers need to talk with one another, they need to collaborate, and they need to make implementation decisions—quickly—without having to go through a chain of command. Team as a solution emerges quite naturally from this need. Working in isolation on someone else's detailed instructions is a 19th century invention. It is another habit we need to unlearn.

InfoQ: If both people and teams are important in Scrum, is one more important than the other? How can you balance them?

Tobias: Teams are made of people. Effective teams are made of engaged, passionate people. One can't be engaged and passionate if one is unhappy in any way. Therefore we each need to put our own welfare first before we can show up fully for our team. My team may change, but I'm always stuck with me, so I’d better find a way to enjoy that!

InfoQ: I see many organizations that have difficulties when they want their teams to become self-organized? Have you seen the same? What could be done to solve it?

Tobias: The error here is "become self-organized". Human systems are self-organized, whether we want them to be or not. What we need to do, as managers or leaders—or workers—is to create an environment where this can flourish in the most productive way. Developers and their customers need to experiment with goals and boundaries, figure out what works, adapt accordingly. The problem will never be solved if we think of self-organization as some new (often scary) thing that we have to control in some way. It’s oxymoronic.

InfoQ: How could an environment for self-organization look? Can you give some examples?

Tobias: I imagine planning sessions would look a little like Open Space sessions. In a product development environment product managers/customers would populate a board with requests, perhaps in a pre-prioritized order. The developers and designers would cluster around the board, ask questions, learn, offer insights, and them sign up for the pieces of work they are i) interested in and ii) have the skills to do, encouraging others with complimentary skill sets to join them, thus forming small, cross-functional teams together for the life of that story. Over time perhaps, more stable teams would emerge as people figure out who they like working with. Hard to get specific here as so much depends on context. Essentially the principle is: let the people doing the work figure out how to do the work. With that principle well understood, the rest is about establishing relationships, agreements/protocols, and continually finding ways to improve. We need to get away from experts, managers, leaders, etc. directing people on the “how”.

InfoQ: Some see agile as a way that people work together to deliver products to customers. For them the roles, rituals and artifacts are the main things in agile. Others focus on craftsmanship, engineering / technical practices, and personal discipline. Scrum is often associated with the first "process" view, while XP seems to fit more with the second "professional's" view. What's your view on agile, and how does Scrum support that?

Tobias: "Agile" is essentially a 2-page manifesto for how to effectively build software. I'm not sure what it means beyond that. The terms agile, scrum, kanban, lean are little more than convenient handles to grasp onto when we move to a new way of working. Overriding all of these terms is something much bigger. Bob Marshall calls it right-shifting, others talk about embracing chaos theory. Essentially it is a paradigm shift from control to release, from (corporate) imprisonment to freedom, from fear to faith. The way the world does business is changing. Agile is a small part of that change—albeit an important one.

InfoQ: Several of your essays talk about understanding what Scrum is and what it isn't. What can people do to build a good understanding of Scrum?

Tobias: A good understanding of Scrum is not what is needed. I'd argue that such an understanding has done more harm than good. The world is flooded with Scrum experts, with many simply wearing the word as a mask over the same tired, old project manager face. To get good at Scrum, understand the principles of purpose, focus, release and alignment, and then throw away the roles and process—and especially throw away all the tracking tools.

InfoQ: What's wrong with tracking tools?

Tobias: In essence, nothing at all. If you want to track your work, having a suitable tool is helpful. My wife and I use a small sticky-note kanban board to track our family chores and personal projects. It is indeed helpful. Trouble is, most tracking tools are designed for management to track the work of other people. Tracking at that level is usually a hindrance to quality and productivity. I’ve observed teams using many electronic tracking tools. Unless the tool is chosen by the developers for their own purpose it usually becomes useless overhead. It introduces unnecessary pain.

InfoQ: Many organizations that are adopting Scrum are coming from a project culture. They are used to managing project with assignments, budgets and project teams and look ways to make fit projects with agile. Do you have any suggestions for them?

Tobias: You can't hammer a round peg into a square hole. Agile/Scrum/Lean, these are all very natural ways of working. If you are struggling to change it is probably because the system you are working in is very unnatural, and likely has a huge amount of waste built into it—which you may have become blind to. So question everything you do, and ask why at every opportunity. Don't jerry-rig Agile. Tear down the old foundations and start again.

In January 2014 AgileLib.net has been released: a library of agile-related resources that is being built by agile practitioners for agile practitioners. It contains references to books, blogs, articles, white papers, videos, slide shows, free tools, groups, community forums, and other resources that a change agent may find useful for a deeper understanding of Agile, and for his or her own personal development as an agile practitioner and coach.

InfoQ: There are already several websites and fora where people can share agile articles and links. Why was AgileLib started, what do you expect it to add?

Tobias: People frequently share articles and links on LinkedIn, Twitter, etc. This is great, but has two problems. They quickly disappear, with no simple way of getting them back, and they are usually the recommendation of a single person. Many consulting companies, etc. offer book lists, but there is nothing to tell you whether you should read this book over that book. You'd need to go to Amazon, GoodReads, or elsewhere to learn this. AgileLib collects endorsements by many agilists, and holds the information in a single, searchable database. On the About page it states: Agile excellence requires continuous learning and exploration. Many resources exist to support this journey—but an equal number may hinder it. How do you find what is truly useful? The answer is to ask another agilist. I'll add: or ten, or twenty other agilists.

InfoQ: The activity log on the AgileLib website shows everything that contributors do, like adding a new link, endorsing content or following people. Why this openness? Which effect does it have on the contributors?

Tobias: AgileLib is intended to build open community, and share information. There are options for making following and bookmarking private, but if you are recommending something what value is there in keeping this secret? The purpose here is to share our knowledge—and our passion.

InfoQ: Can you share some of the great links that contributors have added on AgileLib with the InfoQ readers?

Tobias: I'll offer a few items from my bookmarks list.—the first three of which I was unaware of before they appeared in the library, the fourth I was happy to be reminded of. These items are all endorsed by people I know and trust. I have still to read them, so not actually recommending:

InfoQ: Do you have any future plans for AgileLib?

Tobias: Simply to grow the library and the membership. And to find others to help me. I'd also like to get more feedback from the users, to find out what would make the site a better experience for them.

InfoQ: We’ve discussed two very separate projects in this interview. Is there a connection between ‘The People’s Scrum’ and ‘AgileLib’?

Tobias: The key reason I was attracted to Scrum, back in 2003, had little to do with process, or promises of 10x productivity. I was attracted to the egalitarian nature of this way of working—the promise of community. My experience had taught me that development teams needed a more collaborative approach to be successful. They needed to become communities of equals, bands of citizens, rather than manager-led groups. The leader-and-followers pattern was then (and largely still is) the typical social structure in the corporate world. Scrum offered an opportunity to socialize a different way of thinking—a different way of being.

In the wider Scrum world I found a small group of passionate explorers who shared similar thoughts about people and ways of working, and offered new ideas to challenge my assumptions. I found a community of excellence. As I’ve developed my own skills over the past ten years it has always been the building/nurturing of community that has driven me. AgileLib is thus another manifestation of that spirit. I hope it becomes a place to share, to discover and to learn; a place to visit from time to time to sharpen your Agile thinking and enhance your tool kit; a place to appreciate the members of your community, wherever they may be in the world.

About the Book Author 

Tobias Mayer has a background in software development, publishing, theatre arts, and community service work. For the past nine years he has worked as a change agent, trainer and facilitator, providing coaching and consulting services to teams and organizations wishing to make a transition to more agile, trustful and team-centered ways of working.

Rate this Article

Adoption
Style

BT