Intro to Agile#
For the uninitiated, Agile started as a methodology to deliver software, improving upon the flaws of the then popular waterfall model. The idea was simple - to speed up, you must adapt to change, incorporate it quickly, and deliver updates incrementally. For instance, before Agile, teams spent months finalizing the expected features, then developed them, then tested them, and just as they were about to deliver, they realized a client requirement had changed rendering much of their months of effort practically wasted. And anyone who has worked for any length of time in the tech/corporate world knows that if there's anything fickle in the world, that's client requirements. And Agile was a means to not resist change, but instead accept it, and tune our processes to fit the inevitable change, by delivering small updates in short chunks of time, while taking feedback and incorporating it in further iterations.
And as teams and companies realized that this was not at all a bad idea and helped them deliver more and therefore, improve their financials, they adapted the practice religiously, making tweaks to the process that could suit larger teams and projects. This led to several different forms of Agile making their way out in the open, each suited to a particular team or objective or process - Scrum, Kanban, SAFe, to name a few.
Today, Agile is adapted by almost all development teams around the globe.
But interestingly, you don't have to be a development team, or even a developer to utilize the power of Agile.
Agile for the individual#
Most of us are agile in some way - we spend 15 mins at the start of the day planning our tasks and time - that's like a daily standup in agile. We often don't go all in on an idea, but instead, take an incremental step by step approach to see if the outcome's worth the effort - another agile mindset. However, creating a formal structure including some of these instinctive habits, and adapting a few formal processes can make us more productive in doing tasks, personal projects, as well as general mundane tasks.
5 agile processes you can use in your daily life#
1. Daily standup
A daily standup typically includes answering the following three questions :
-
What did you accomplish yesterday?
-
What are your goals for today?
-
Any blockers?
In a team, each developer talks about her/his own content on the above three points. The same format can be taken up by you personally as well. You start by reflecting on everything you accomplished yesterday, which not only gives you motivation, but also pick up on where you could do better today. You then check out your goals for today - work, personal, social, all of it, and put it up on a todo list so that you can check them off. Finally, you think about any blockers you have - any work task that requires an input from a teammate, a social obligation that's gonna eat up a couple hours of your time? This is helpful for you to set your expectations for the day.
If you already have a standup for work, it's recommended that you do a quick personal standup before it, so that the blockers you find for yourself can be discussed in the team standup.
Are there tools you can use to help you in this? The simplest option would be a calendar to place your blockers, and a todo list to keep track of tasks. If you're feeling nerdy, Dailybot is a slack bot that you can use to customize questions sent to you over Slack that you can answer
2. Weekly/bi-weekly retrospectives
As the name suggests, you retrospect on the past week(s). What went well, what could be improved?
Sprints are usually 2 weeks long in development teams, and a retrospective happens at the end of each sprint to improve the next sprint.
How can you use it personally? You have a habit that you started. You need to take a reflection to see if it's working, and make tweaks to improve. For instance, when reflecting, you realize that you're more able to absorb the content of a book you want to read more in the morning, than at night, and you therefore update your calendar to block time in the morning instead of the night. Similarly, you take note of some activities that are stopping you from being at your productive peak - social media scrolling, Netflix, Zomato, and plan to reduce them in the next week.
The core tenet of agile is adapting to change, and retrospecting ensures that you're aware of what needs to be changed, and how.
Tools you can use for retrospectives can be as easy as looking across the past two weeks on your calendar/todo list to try and recall where things can be optimized. However, if you want to delve into detail and have the time and will power to, you can use time tracking tools like Kosmotime to track the time spent across various tasks, that'll allow you to determine if the outcome of a task was worth the amount of time you spent on it.
3. Velocity estimation and prioritization
Velocity refers to 'units of work' that can be allotted to a given task. A relatively simpler task has lower number of units, and a complex or a time consuming one will have higher. Each team has a fixed number of units per day they can manage to complete, and thus, this allows quantitative estimation of how many tasks they can do in a given sprint.
Prioritization is as the name suggests - needs no explanation.
The same can be applied in our daily tasks as well - in each retrospective/planning session, we assign points to each task we have to do, and decide how many we can fit in a day/week. For instance, while writing this blog post, I assigned 4 points to this task, which should take me a couple of hours, and this helped me blocking my calendar accordingly.
Similarly, task prioritization is critical, since we always have way more to do than we're capable of, and some things need to be done way more urgently than others. Thus, giving priorities to some tasks and accomplishing them sooner should be part of retrospectives, plannings and standups.
Todo lists like Todoist have a priority flag, which can be used to prioritize and then filter tasks on priority. While velocity is not a direct feature in many todo applications, it's as simple as a number you assign to a task, as long as you have a clear idea in mind/on paper, as to the relation between the unit of work and the time you should block for it.
This exercise might often seem like an overkill - you might think that it's much easier to just do a task right away, than go through this entire process of setting velocities, priorities and what not, and while that is indeed the case sometimes, not all tasks can be just 'done'. For instance, I had to plan this blog well beforehand and allot time for it, so that I could research on the content, finalize the points, leave enough time for proofreading and publishing. I could not just sit up one fine day and shoot through all of this in lesser time. It requires some thought on what tasks can be just 'done right away', and what need planning.
4. Frequent delivery
While it may sound like this doesn't apply for a lot of our daily tasks, well, it does really help on long term projects, to complete small chunks of work rather than hoping for a grand release. For instance, doing a Rangoli for Diwali - plan the design one day, the chalk outline another, the colors the third day, instead of waiting for a day you could do it all.
If you're working with other people/clients, this is even more important since you can get feedback before you've done a lot of work that could potentially go to 'waste', if the requirements or priorities change.
When I was writing a blog for a firm some months back, I decided to go through it all in one sitting, for which I took a week, and on the day of presentation, realized that I had gotten the topic all wrong.
Continuous feedback is another tenet critical to agile, and while your tasks might not usually have other people involved, your own feedback and expectations are important enough to ensure are at par, and thus, try to keep deliveries short and frequent.
Jira has versioning for delivery of software products - version 1.0.1, version 1.0.2 and so on. This can be customized for other tasks as well, including those that aren't clear enough to be defined via versions.
5. Using metrics for assessing output
One thing almost everyone can agree on - a task can almost never be 'good enough' for all stakeholders. You will always find ways to do it better. The client will always have further feature requests. And when working with personal tasks which are often not deadline bound from the start, it's tough to know when to stop and when to keep improving. A subjective 'does it look good' is a very ambiguous and unhelpful milestone to achieve, and does nothing to consider the effort put into the activity. Instead, there should be more objective metrics that can help us analyze how we performed and as Taylor Swift puts it, 'If the high was worth the pain'.
Agile has numerous metrics to track team performance, such as cycle time, lead time, burndown, throughput, business value, but almost none of these should be taken up blindly as a metric for your own tasks or projects, because focusing on a wrong metric can lead the project into an entirely non productive direction.
For instance, judging the growth of a blog by number of articles per month isn't a great idea, if you do not consider the quality of articles that go in there.
Instead, you should research and finalize a metric you'll aim to optimize as you go through a project, and customize it so that an improvement in the metric score actually translates into the project becoming better. In the above example, the number of minutes an average user stays on the blog gives a good idea of whether the blog is doing good from the 'quality' perspective.
The tools for this process will depend on the metric you aim to use - Google Analytics for traffic tracking, time tracking for amount of time spent, Jira/other project management tools for number of features delivered, and so on.
Thus, these were 5 agile processes that you could implement in your daily life and personal projects as well, to optimize your productivity. But before you do that, remember the very core tenet of agile - adapting to change. Priorities change, circumstances change, requirements change. And it's important that you realize this, expect the change and adapt to it