Cycles, sprints, iterations... these are all buzzwords that the software process community has been using for years. Most of these words were design to help us "fail fast and fail often" so that we can learn more about how our users feel about the stuff we've coded. But have these words really helped us? Sadly, for many software developers, these words are empty. We'll attempt to reinvigorate of these buzzwords (like "sprints" or Agile cycles) by analyzing one of the oldest words in human history: "samsara." Samsara also refers to cycles (but in this case the repetition of life, death, and rebirth). This word from the Sanskrit language has a beautiful sound and rich history in philosophy, spirituality, and even math! Some scholars believe that the number zero visually represents Samsara. So, let's compare this interesting word's meaning; and in the process, hopefully we can reclaim why we ever cared about Agile "cycles." I've heard some people unfairly refer to Samsara as "the endless wheel of suffering." While it has a certain zing to it, that's too simplistic of an understanding of the word. However, it's possible that this image of repetitive suffering hits home for those readers who are waiting for the promised future where your team or your organization learns from its experiences. Don't get discouraged! The purpose of CubicleBuddha.com is to help you learn to end that cycle. I created this blog to help you (and myself) find a way to learn, grow, and be happy at work. In fact, Zen Buddhist philosopher, Alan Watts, explained how human beings are uniquely capable of learning how to get off of the wheel by not being stuck in a past cycle or a future cycle (1):

"And so you go round and round and round, ever chasing the illusion that there is something outside yourself, outside your here and now, to be obtained that will make things better. [...] Only in the middle position, the position of man, which is you could say, the equal position - the position of sufficient equanimity, to begin to think about getting off this rat race. Only from there you see, can you become a Buddha. So the position of a Buddha may be represented either not on the wheel at all, or as right in the middle of it [...] So you see therefore, a Buddha is one who awakens form the illusion of Samsara. That is, from the thought that there is something to get out of life, that tomorrow will bring it to you, that in the course of time it will be alright.

So we see that the goal is to go inward to find a way off of the wheel. For software engineers "the wheel" refers to the "sprints" (i.e. the two week increments of time) that some misguided managers have carved up so they can track what we've accomplished. Or at least sometimes it feels like the process is being thrown on us. But if you took anything from the philosophical quote above from Alan Watts, recognize that you are not a hamster on a wheel. You are not chained to a desk. You can reclaim the Agile processes for yourself. In the same way that we're reanalyzing the word Samsara, you can take the time to reanalyze the manifesto that created the term "Agile" in the first place. While you're reading the Agile manifesto, pay careful attention to this quote:

Individuals and interactions over processes and tools

See! The great thinker who came up with these Agile buzzwords wanted you to ignore the terms and the process as you search for what works best for you and your unique team. While your managers might want you to move from one "sprint" to the next, challenge yourself to look inward like a Zen Buddhist to find the answers to why your job isn't as compelling as it once was:

• Do your Scrum sprints feel like suffering and your team makes the same mistakes every 2 weeks?
• Do you feel like you're not learning enough about how the users are using your software
• Are we actually releasing the code to users and getting feedback from them?

If you're not doing those things, then you might not be in a small cycle at all. You might be on a wheel that is so large that it appears as if the wheel isn't moving at all. If you're not learning, if you're not introspecting from the time you spent working, or if you're just mindlessly following the process... that's when the cycle actually is causing suffering. So how do we get off the wheel?

1. The Buddhist way: You can (bare with me) acknowledge that you don't want to participate in the wheel and therefore try to breathe, relax, and slow down time via meditation.
2. Or... since you have a job in Corporate America... you can make the wheel smaller and smaller. Make the wheel so small that you learn every day. Shorten the feedback loop. This is what it means to "fail fast and fail often" so that you can learn from your mistakes and quickly integrate your learnings.

So let's talk about those practical ways of making the wheel smaller. And if we're successful, maybe we can morph Samsara from its colloquial meaning of "the endless wheel of suffering" into its original meaning of "wandering" (2). Here are some practical ways to wander as you develop software without being aimless:

1. Do weekly demos for your stakeholders. Record their feedback and take the time to figure out which parts you should implement.  The more frequently you demo your software, the more often you get to learn from your users and your stakeholders.
2. Take the time to add metrics-gathering tools (like New Relic or Google Analytics) so that you can automatically learn about your users' behaviors. This makes the feedback loop much shorter than product demos ever could.
3. Hold team retrospectives so you can learn from their process mistakes. Who knows? Maybe your team can become so good at failing and learning together that they might be able to also improve their interpersonal skills. It's not just the software that should be improving. Retrospective meetings are probably my favorite ceremony that the Agile/Scrum community came up with because it truly represents continuous learning and introspection. If your team is meeting periodically and taking the time to share what they learned during their last trip around the circle, then you have a true opportunity to prevent suffering on your team. I can't tell you how many times a teammate reluctantly brought up an issue during a retrospective only to discover that the rest of the team was also quietly feeling that way.
4. Create smaller cycles: If you're someone like me who struggles with "analysis paralysis," then you might need even smaller cycles. There are lots of ways to eliminate that particular suffering:
   • Allow your code to break at least once every 15 minutes. A future article will discuss the joys of learning to break your own code, but briefly imagine the joy of:
     1. Loading up your project
     2. Seeing the failure immediately
     3. Quickly fixing it
     4. Taking a breath
   • Consider using Test Driven Development (TDD) techniques like Red-Green Refactoring to bring you more peace. There are many technical articles on Test Driven Development, but in brief TDD provides you with a framework to determine what your users expect today and to validate that upfront before you even write the real code. It's a way of simplifying your thought process and focusing on what is necessary in the moment. For many of us, it's a way of coding mindfully-- but if it doesn't work for you then stop it. The goal is to find techniques that help you stay calm, help the user, and treat your peers with respect.
5. Visualizing a micro-success: On your drive to work, visualize the one thing that you plan to accomplish in the first hour of your day. Selecting a small accomplishment is even better. Picking easily accomplishable items (like drinking a glass of water or opening up your team's "to do" list board) and reaching completion will get you into the practice of getting things done at a steady pace.
6. Many more techniques that we'll be sharing in future articles.

If you do these things you will find that you are learning and growing value for yourself and for your users. If you're doing good work then you are helping your users and your community-at-large. You might find that you're helping your peers simply by demonstrating techniques for self-care and showing the value of small, iterative, learning opportunities. As we'll discuss in many exciting blog articles to come, you have the power to make an impact on your team by simply breaking the cycle of suffering. If you can create a culture of forgiveness and learning then you can make an environment where work is enjoyable every day. That doesn't sound like suffering to me! :) So reclaim Samsara, and use it every day (maybe every moment) as an opportunity to learn, grow, and be happy.