Iteration as mantra

it's Agile, but accidentally

Published at May 24, 2022±17 minute read3983 words

Disclaimer

First of all: this is not a technical story. It looks technical, reads technical, and even smells technical. I put some effort into making it more straightforward and hiding some context into a neat folding component.

Defining iteration

When I start a new project, I usually have it laid out in my mind from start to finish. I imagine the size of the book, the colors on the cover, the illustrations between chapters, and even the cool signing event I'm going to get drunk at.

Before I write the first line I'm already imagining the finished product. This text, for instance, is imagined to be a beautifully written summary of how project management crept into my personal life in a way I couldn't predict. It's also, in my mind, an instant hit, a viral of sorts, that will bring the golden age of blogs back and will break the server I host this website after so many people accessing it at the same time.

The world, though, is very different from our imagination.

Things don't happen in an orderly fashion, one fact after another, as predicted and expected. Life is chaos, things are weird, and the vida is loka. It's impossible to have a plan that works 100% how it's supposed without mitigating some risk.

So, when I started learning about Agile, I thought: this is it, working through a project and making changes while things happen.

The main idea behind Agile is iteration. Instead of planning a big project and working through a huge chunk of time, just to deliver it at the end to find out it's obsolete or that it doesn't work as intended, we work in little bursts of time and evaluate our work in small increments.

So, in the Waterfall way:

  • Plan in detail for 1 year
  • Working time
    • Work for 1 year
    • (Actually, work for 2 years because some unexpected stuff happened)
    • Deliver product finished after 2 years
    • Find out if the product is not what the customer needed
    • Bankruptcy

While in the Agile way:

  • Have a rough idea of what's needed
  • Define the minimum viable product (I'll come back to this soon)
  • Plan in detail for 2 weeks
  • Iteration
    • Work for 2 weeks
    • Deliver the planned work after 2 weeks (even if not everything was done)
  • Evaluate the result
    • Is it acceptable?
    • Does it deliver value?
    • is the long-term plan still relevant?
  • Plan in detail for 2 weeks
  • Iteration
    • Work for 2 weeks
    • Deliver the planned work after 2 weeks (even if not everything was done)
  • Repeat.

Defining value

It's really hard to understand what value means when studying Agile and the many frameworks and methods connected to it. I remember this section of The Scrum Guide from when I was studying to get certified:

Sprints are the heartbeat of Scrum, where ideas are turned into value.

They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

So, when doing Scrum, we should deliver value after some fixed time... but what the hell is value?

We normally understand it as something quantitative. The value of a one-dollar bill is... one dollar. The value of this new mobile phone is a thousand dollars, represented by a thousand one-dollar bills or ten one-hundred-dollar bills.

It's easy to understand value as money, but value can be (and normally is) something beyond currency. Value can be time, beauty, usability, usefulness, and other more abstract concepts. How to grasp the idea of one thousand beauties? Even time, in this case, is the abstract concept of time: relative, personal, intimate. What is too much time? And too little?

I define value in a very stupid way:

If the sum of things done makes things better, it's valuable.

There's no point in rewriting a good story into a way better one if you lose the deadline for publication. That's not valuable. Putting a new sound system into your car is less valuable than fixing that oil leak that's happening for weeks — one of them will leave your car dead on the road, the other won't.

Every iteration should deliver value: it can be new information for the user, a better way to use something that already existed, a more accessible and fast interface, and so on.

Defining Agile

It's really hard to work on projects that are meant to be Agile but aren't. They form Agile teams with Agile ideas but, for instance, have a fixed deadline on a project with very fixed requirements that should be finished a year from now.

At the end of the day, they are Waterfall projects with Agile makeup. They push unnecessary functionalities instead of responding to change over following a plan. They force people into overtime instead of respecting individuals and interactions over processes and tools. You get the idea.

So, I made it my responsibility to repeat at least once, every day, that we are Agile and will respect the Agile way. I usually do that with my favorite term of this universe: iteration.

No, we won't do something huge from one day to the other: we will iterate. We won't change everything and delete whatever has been done before: we will iterate. We won't care if things are not 100% finished, because nothing is ever 100% finished: we will iterate.

Every iteration should bring value, and value is abstract. It's our goal, as developers, designers, product owners, etc, to show what value is gained with each iteration. That's Agile, being eternally in movement, enjoying the journey more than forcing ourselves to achieve a goal, constantly changing and adapting.

And here's where I turn this article into a big self-help thing and you'll hate me for it.

Defining mantra

The moment I noticed I was Agile-ing my personal life was during a therapy session.

We were talking about my new life living abroad, in Germany, with no physical friends close and being very lonely. Living here has been great in many ways, and absolutely heart-crushing in others.

One of the things we have talked about a lot before my moving was how all this should be seen not as a struggle, but as an experiment. It's just something I'm passing through, learning the good things and understanding the bad ones. In the end, I'll know more than I did before.

I'm not staying forever in Munich, I'm experimenting with living abroad. I'm not blindly suffering from loneliness, I'm experimenting with what being enough for myself feels like. Every week I take a look at my life and understand where things are working and what needs some tweaks. I end up summarizing what I'm doing in my life that's making me happy and what's not.

Every week I weigh what value these experiments are producing and iterate. I repeat to myself, almost religiously, that experimenting is more important than concluding.

I made iteration a mantra.

I learned, accidentally, to avoid anxiety and depression by looking at my life not as something that will make me have success or fail, but as a forever ongoing project that iterates for as long as I live.

I learned to look at things I would be afraid of as possibilities to grow and understand the unknown. I learned that I don't need to change a toxic behavior completely from one day to the other, but to acknowledge the small changes and note down the tiny daily victories.

I learned to see every new endeavor as an MVP. I note down what's the minimum example of success in something new and celebrate them. Instead of defining the success of my German learning as being able to talk and listen fluently, I define it as simple ordering food at a restaurant. Simple, straightforward, minimal.

Value should be measured differently as well. It's better to think that a day in bed playing videogame was me delivering myself happiness value. A day resting is energy value. A day working hard is knowledge value. Nothing is wasted and everything counts toward this lengthy experiment that I'm living.

When I noticed, everything was following this pattern in my life, even the smallest of house chores. If I need to clean my entire flat, I split the full cleaning into small tasks and iterate on them. If I wasn't able to finish all today, okay, we can continue tomorrow. If I find out cleaning my sink takes more time than I expected, instead of beating myself by not finishing in time, I see it as a good lesson for the next full house cleaning: estimate more time than before.

Conclusion

This convoluted article mixing management terms with you can be better stuff is the prolix way of saying: I'm applying the Agile way of thinking in my personal life and it's being awesome. It's been done without my (conscious) knowledge.

I hope you can take something home from all of this, after all, I'm here to deliver value to you as well. I still don't have a comments section here but you can hit me up on Twitter and start a conversation about this.

After all, I'm learning new things every day and with this new knowledge, I change, evolve, and iterate.

Postscriptum

If you came this far: thank you a lot.

I know this wasn't my best text and that it was somewhat complex and may be confusing.

I'm coming back to writing after a long time without touching a keyboard. It's been a great experience and I'm slowly growing with it. This is the only way to get better: doing the work and learning from the mistakes.

Thanks for reading.

Even though this blog has no comments section, I'd love to hear your thoughts about this article.

Tag me on Twitter, Instagram or Telegram using @oicronofobico and let's get this conversation started

Contact me anytime

githubtelegramlinkedin