Agility and Project Management for everyday life

“When the variety or complexity of the environment exceeds
the capacity of the system (natural or artificial)
the environment will dominate
and ultimately destroy the system.”
– Statement of “Ashby’s Law”, W. Ross Ashby

What is the similarity between implementing a project and climbing a mountain?

I used this question to open one of the presentations I gave on project management. I was looking to get the audience’s attention and set up an open and more playful relationship before getting into the “heavy and serious topics“. Someone in the audience was going to ask “Which one?“, I was going to answer “I like both.” continuing with the question “But what’s the difference?” and the answer “Today we’re just going to talk about project implementation”. But you know what they say about home-made plans… someone raised their hand and said “Once you get to the end the road looks different than it did when you started.” An unexpected and excellent response.

On reflection, after the presentation, I was able to find even more similarities: there are always different ways to get to your destination, and some are more effective than others; you need to be well prepared to face the environment that will test you constantly and in unexpected ways (and guaranteed if you are active enough it will teach you lessons you won’t forget); and, perhaps the most important similarity for the purpose of this text, both mountain climbing and project implementation develop skills that are universally valuable and can help you greatly in other areas of daily life.

And, just as Everest is popular with mountaineers, there’s an attractive and challenging mountain for project managers to climb. It’s called Agile Project Management. So the following lines will focus around two main ideas:

• a) What “Agile” means – beyond the buzz-word
  b) How we can in practice cultivate more agile processes.

However, I must make one last important point. The world of projects is incredibly broad and diverse, and each project is a unique experience. In the face of this multitude of possibilities Agile is one of the methodologies that can help us implement projects. We often find the term associated with traditional (or Waterfall) project management methodologies.

Choosing one methodology or the other requires a thorough understanding of the industry in which the project is to be implemented, the complexity of the environment in that industry, whether or not we know the solution we want to implement, and the level of involvement we want to give to the stakeholders connected to the project: customers or other third parties.

Agile methodologies suit projects that by their nature are exposed to a high degree of uncertainty. If we are developing an innovative project whose final solution we can intuit but not estimate 100%, if in this process we need to build several iterations of the solution and if for these development stages we need to involve customers, then we will definitely favour Agile, not Waterfall. But it would be a mistake to try to work Agile on a project where we want to install PVC double glazed windows on a house. There we know the solution, we can estimate the project time very clearly, we know the processes, and if we end up with iterations it means we have done something wrong on the first fitting.

What I want to tell you is that, although this article will shed a very favourable light on Agile methodologies, we must not fall into the trap of thinking that these methodologies are the standard answer that we are heading towards in any case and for any project. What’s more, all companies, even the most innovative among them, will naturally tend over time to turn Agile projects into traditional Waterfall projects. This happens because of the discovery and learning process that takes place after every project we run, and by running similar projects, the solutions, processes and end results become increasingly clear to us. So the methodologies we also need are more likely to be ones that gravitate towards standardisation and predictability.

In reality, on a case-by-case basis, companies choose to use either more Waterfall-leaning or more Agile-leaning approaches, and more often than not we find unique blends between the two.

As technology evolves rapidly, the lifecycle of products and services decreases and customisation for the customer plays a very important role, the environment for project development and implementation is also changing.

Agile methodologies for approaching projects, originating in software development teams, have become very attractive to a wide range of companies, teams and projects. In today’s environment everyone, from startups to large companies, from NGOs to state institutions, wants to work Agile!

But my experience from interacting with various environments points me to a discrepancy between entities that want to work Agile and those that actually succeed in doing so. And that’s not because they don’t try, because they don’t use Agile methodologies, because they don’t organize their work in Sprints or have a Scrum Master. Most of the time they do all these things, and they don’t become Agile despite the efforts they make. Why does this happen? To answer that we need to understand that Agile is more than the sum of the methodologies used.

A frog thrown into a pot of boiling water on the stove will sense the danger and jump out. If we put the frog in the pot while the water is still cold, and then light the fire under the pot, the frog will stay there and eventually die. What happens in this case depends on the frog’s neural system. The way information is transmitted from its skin to the central decision-making system, via synapses, works correctly when it senses sudden large temperature differences between the environment it is in before it is in the hot pot and when it enters the pot. It is, however, ineffective at detecting subtle, incremental changes in water temperature. In other words, the frog dies without even realising the danger.

“Nice story Vlad. We’ve learned to make frog soup, but what good does that do when we’re talking about Agile?” you may rightly think. Well it’s simple…for example the frog is Nokia in 2007, and the slow boiling water is the market that is starting to popularise smartphones. Another example from the opposite pole, when changes in the environment are rapid and noticed by all players striving to adapt is the Covid19 crisis. The danger was so obvious that every company in the world took steps to adapt and survive the economic context.

So what is Agile?

Agile is first and foremost a way of thinking and operating that needs to be educated and cultivated at the organisational level, from the highest level of decision making to the front line of interaction with the environment (market and customers). It is the understanding of “rapid adaptability” as a very valuable skill in the context of a rapidly changing world around us. Agile starts from the conscious effort to understand the business context of one’s own company in real time, both externally and internally, continues with the education of a sense that recognizes and communicates small changes effectively, and ends with the rational selection of methodologies needed to manage the whole context effectively. Clearly building such a system requires sustained strategic efforts on the part of a company that is already established in the market, and it always starts with education in this spirit.

The main reasons why teams, projects and companies don’t become agile, even though they want to are:

1. Implement methodologies without understanding the “why” behind them – I see other teams or companies working in SPRINTs. Perfect, we work in SPRINTs too without understanding if we really need it.
2. Decision and execution levels are not aligned – the manager thinks agile and builds agile processes, but the team doesn’t know how to implement them effectively because they are not educated to work that way, or the variant where teams are truly Agile, but the information they pass on to higher decision levels is not properly analyzed. In other words there is a split between the company’s ‘central nervous system’ and the ‘peripheral nervous system’. The two do not communicate effectively.

So we can conclude that agile tools and methodologies used just for the sake of being used will always be less effective than tools and methodologies used meaningfully in the hands of teams that are educated to constantly adapt to changing conditions.

One last thought here: agile teams are generally small teams in terms of numbers, but if you can build and maintain such a team within your business, you will have what can be worth more than entire departments.

Agile processes in practice

“Okay Vlad, smoky so far. But what can I concretely do to start working more agile?”
Suppose you arrive at work on Monday morning and the first effort you make, after the traditional small talk with colleagues and making your coffee cup, is to ask yourself “What do I have to do this week?”

A good first step is to make a “To Dos” list that may look like this:

We note that this “To Dos” list has a few points on it, but there’s a possibility that these lists can add up to a lot of points in busy weeks, especially if you’re someone who has responsibilities beyond yourself. Do you manage a team at work? Are you a parent with children? (Note that they are often almost equivalent.) In these cases you have extra tasks or at least responsibility for tasks that you are not directly supposed to do. It’s important to take the time to make this list complete, at least from the perspective of things as they are on Monday morning.

Now, we have the option to get straight to work and start wrestling with the To Do list item by item, or we can take a step back and ask ourselves if we can’t improve our perspective a bit. Perhaps the desire for efficiency and organization sneaks another question into our brains, “Where do I start?”. And it’s a very good one. How can we organize this multitude of tasks into a list of priorities?

To answer this question, the Eisenhower Matrix is a great help, which will organise our tasks into 4 categories: Important and Urgent, Important but Not Urgent, Urgent but Not Important and Not Urgent and Not Important. My additional suggestion is to also organize them by Categories (Personal/Professional) or maybe even by projects if we juggle more than one.

We certainly have a greater level of clarity now and know where to start. However there will be another challenge: how can we monitor progress and maintain clarity on tasks that are not just points to complete? If we look at the list above, things like “Develop a new feature for the web application” are most likely to be more complex and span a longer period of time than the current week. And that’s not the last challenge we’ll face. What do we do with the new things that come up along the way? What about delays? With the things other people have to do so we can accomplish ours?

These are things you will invariably come up against, even if you don’t work in Project Management. Because they’re part of the chaos that surrounds us every day, and being agile means being able to face the chaos confident that you’ll be ahead every time.

What has helped me a lot, and what I can recommend because it is a very simple tool to understand and use, which also has the advantages of giving you a great deal of clarity and helping you face the challenges described above is called Kanban Boards.

În esentă, tablourile Kanban au două elemente:
-Liste
-Card-uri

The lists are the columns of the dashboard, and they represent the stages of a process that a task goes through from the “we have this to do” stage to the “we have finished doing this” stage. The simplest process to describe is the 3-step process: To Do, In progress, Done.

The picture below exemplifies this organisation. For this article I used the Trello tool as a demonstration, as it is a very simple tool that can also be found in the free online version, but there are a multitude of tools you can use here, the important thing is that they are useful.

Of course, depending on the project and the number of people involved, the process that tasks go through can be more complex, so the number of lists and their organisation should reflect this.
For example:

The lists are the columns of the dashboard, and they represent the stages of a process that a task goes through from the “we have this to do” stage to the “we have finished doing this” stage. The simplest process to describe is the 3-step process: To Do, In progress, Done.

The picture below exemplifies this organisation. For this article I used the Trello tool as a demonstration, as it is a very simple tool that can also be found in the free online version, but there are a multitude of tools you can use here, the important thing is that they are useful.

Now, what I’m starting to do is to “embellish” the card with information. For example, I remember that I decided after filtering through the Eisenhower Matrix a task priority. This can be found on the cards through a colour coding system. Personally, I use Prio 0, Prio 1, Prio 2, to highlight the first 3 categories of tasks in the Eisenhower Matrix. Those neither urgent nor important should be eliminated.
Probably after colour coding things will look like this:

Now, for efficiency I can move the higher priority ones to the top of the list over the others. I get:

Now, what I can do is work on the card to fill it with the right information. On the card I can:

Put a description
Assign a deadline
Attach relevant documents
Organise checklists
Add other team members who are important/responsible for the task.
Post comments requesting or conveying important information about the task.

I should use these functionalities to make my life as easy and clear as possible for the work I have to do next. This is what an unfolded card looks like that I started to putting information on:

Now that I’ve made my To Dos list, prioritized the tasks, organized the list process through the Kanban Boards methodology, uploaded the cards and detailed them with all the relevant information, I can say I have a good planning for the week ahead. It’s still Monday morning and I’m wondering if the time investment I’ve made in this process is worth it? You won’t get the answer on the spot, but at all times:

Something new comes up and you can effectively feed it into the system, prioritise and delegate if necessary
The chaos around you takes over and you wonder how you can regain that control, and it’s just a few clicks away
You feel like you have forgotten something to do or checked and can quickly and efficiently identify what
You can quickly confirm the status of a task both yours and others in your team and beyond.
The feeling of personal achievement you get at that moment in the week when all the cards that were in “To Do” on Monday finally end up in “Done”

With a final thought I leave you: if you are attracted by what I have described in the above lines, find it interesting and want to apply it, do so. But do it in an assertive and disciplined way. Take a trial week where on Monday morning you do the process I’ve described above, and then at the beginning of each working day of the week you take 5 minutes to open your Kanban Board to ask yourself “What needs to be done today?“, and at the end of the day “What was done today that needs to be updated?“. If you’re happy after the first week try one more, and then maybe slowly-easily-build up to a month of days working like this.

Over time you will find that you feel the process more fluid, clearer, things settle harmoniously into your working days, the results are more tangible, when chaos arises you are more prepared to deal with it, and in the end you will be able to conclude for yourself: “I’ve become a bit more agile!”.