Retrospective

"It's a marathon, not a sprint." This is what Chris from HubEurope used to tell me whenever I pressure myself to deliver on feature requests while supporting our clients. And I took a lot of comfort in knowing that my boss understood that, even when we're committed to making our product better, we can't deliver everything all at once. So, from then on, I had been used to working at a decent pace.

When I transferred to Willis Towers Watson, I was introduced to the Agile Methodology. It's basically a means of working on projects where large tasks are divided into smaller, more manageable chunks with their own limited scope; committed into a "sprint", or a time frame that usually lasts for two weeks; and integrated into the larger context of the project once reviewed and tested. The methodology is supposed to make for faster deliveries, as compared to the other methodology called "Waterfall", whilst not sacrificing quality.

Agile covers a lot more topics when it comes to project management but let's limit this post to that. Having said that, let's talk about "sprints" some more.

So, sprints usually last for two weeks; starting from planning and leading to a retrospective. Managing sprints is usually aided by tools like Jira or Trello. Those are board- or table-like tools that contain columns like To Do, In Analysis, In Development, In QA or Under User Acceptance Testing, For Deployment to Production, Done; which represent the various stages that each task goes through. And during planning, a development team consisting of a product owner, scrum master, developers, and QAs will sit down together and determine: 1) what the team can deliver in the coming two weeks, 2) who among the developers will be assigned to each task, 3) how each task is going to be tested, and 4) how it will take for each task move through all the stages defined in the team's management tool.

It's a good process. It's usually efficient. And although Agile allows for a great degree of flexibility in many things, including task scheduling; it's nice to have a solid idea of the time you need to spend actually working for the next two weeks as knowing that allows you to pace yourself as you would if you were running a marathon.

Agile makes total sense, right? If your career were a marathon, it's great to be able to pace yourself so that you don't run into physical and mental health issues related to stress and burn out. Agile isn't strictly just for project management. If applied correctly, it can also help with personal time management that, in turn, leads to a better life/work balance.

But I guess there are cultures that aren't really compatible with Agile. Particularly, cultures that place a premium on hours worked instead of tasks completed, which I think, is still commonplace. In those cultures, if you complete four committed tasks in three days, the tendency is more tasks are assigned to you so that you're not idle the for the rest of the two week sprint.

In the context of a career being a marathon, that is not a good thing; because you're always running at a fast pace when, in many cases, you need to just jog, walk, or completely stop to catch your breath.

That's one of the things that I'm grateful for in my experience at WTW. During our daily meetings, there's no shame in saying, "I'm mostly free today (or until next Wednesday)" or "I'll be on stand-by as I await the QA results for task ABC-1234". And there's no pressure to take on more unplanned tasks just so you can put something in your time log. There was always a "Non-Production" item in the log selection— time that you can spend taking courses in PluralSight or just stepping out of your zone to look at the sky.