How to be Agile without being Agile

What is Agile?

Agile can be described as an iterative product development cycle that translates into faster delivery of value to the customer. It is preferred when the exact scope of the project is not known from the beginning, and the direction it will take is based on market feedback. The agile approach relies on specific time-periods, during which tasks set at the beginning of such a time-period are carried out.

The creators of the agile approach in software development offered the world their manifesto of shifting attention from processes and tools to people and interactions, from detailed documentation to working software, from contract negotiation to customer collaboration, and from executing a set plan to responding to changes. They have also created 12 principles of agile software development, which I recommend you become familiar with.

Agile as a mainstream product development approach has been used in many methodologies (or practices, frameworks) - a few of the most common ones on the market today are Scrum, Kanban, Lean, XP, Nexus, Disciplined Agile, for example. Each has added its own framework, created events and tools to accommodate the creators' defined, ever-evolving needs. In the remainder of this article, I will expand on some of the events/tools that have been proposed under the above frameworks.

Agile way of thinking

However, project reality is often not as ideal as agile developers dreamed. Clients have a specific budget, scope of work and time for implementation. Often they don't understand why to be more agile, they think it generates additional costs, they have been working for decades in the old model and don't feel the need to change. You can educate them, persuade them, encourage them, but you can also use the tools I suggest regardless of whether the project being conducted will be based on classic or agile methods. The effectiveness of each tool will vary, and I recommend trying them out in your teams on a pilot basis and deciding whether you want to stick with them. The following are just examples that have worked well in my experience.

Project planning

If a project is to be executed successfully, it has to be planned whether we do it the classic way or the agile way. In the classical way, that is, stage by stage, e.g. we first conduct a business analysis, then design a solution, program, test and hand it over to the customer for use. An example of an agile approach is the following scheme: we conduct a business analysis, design a solution, conduct tests with users, program the first functionalities, test them, hand them over to the customer, program more functionalities, and so on. Contrary to what you might think, the project should not consume more resources by dividing it into smaller parts, and this way, on the one hand, the client will be able to use the solution earlier, which can translate into potential profits, as well as the quality should be higher due to greater focus on the part. 

A technique I recommend using when planning a project (it will also be valuable when planning tasks, as discussed in point 2) is MoSCoW, or determining the importance of individual tasks for a given stage of the project. For example - when creating an MVP (minimum viable product), only some functionality will be necessary. For the next stage of the project, it is likely that functionalities that for some reason did not fit or were not so important to be in the "must" category will go higher in the hierarchy. Dividing tasks in this way, both from the perspective of the entire project, weekly planning, but also in daily work, will allow you to focus on the most important ones first.

The different letters from MoSCoW stand for:

M - must (must be done)
S - should (should be done)
C - could (can be done)
W - won't (won't be done)

2. Task planning (weekly)

We have the project planned - at least some part of it, now we can move on to divide our scope into smaller parts. Depending on how comfortable we're comfortable working, the characteristics of the project, what part of the project we're working on, the Scrum Guide says to divide it into Sprints, which are modeled to last 4 weeks. In my project life, weekly and 2-week intervals, during which a specific package of tasks was carried out, worked well for me. Again, using the MoSCoW method, we divide a specific scope into the most important ones that need to be done, and the less important ones. How many tasks go into our scope will depend, among other things, on their complexity, and the number of team members (or the amount of time they will have during a given period to complete tasks). It's a good idea to plan tasks at the beginning of the week, so that you can move on to complete them with a fresh head.

3. Daily

To make sure the project doesn't get too long, it's a good idea to monitor its progress on a daily basis. For this, stand up or daily meetings (according to the aforementioned Scrum Guide - Daily Scrum) are great, during which the tasks carried out the previous day are discussed - whether they were completed, what difficulties there were, what tasks are to be completed today, and whether there are any potentially problematic elements, issues that need to be clarified / explained, so as not to block the work of the team. Daily meetings should be as specific as possible and give each person on the team the opportunity to speak.

4. Kanban board

A kanban board (kanban board) is a tool that visually depicts the production process and places ongoing tasks in the right place. It is a valuable tool because, on the one hand, it supports people who are visual learners and need to see how much work remains, and, on the other hand, it allows to reduce the number of tasks in progress (the so-called work in progress), which has a positive impact on focus and not overloading a team member with tasks. Those who use the so-called multitasking know that it does not support work in focus and does not at all mean that by completing several tasks at once, you will complete them faster than if you complete them one by one.

5. Retro

The last event within the selected set is a retrospective meeting (according to the Scrum Guide - Scrum Retrospective). During such a meeting, the issues that affected a particular slice of the project should be discussed - what went well, what went worse, and very important - what we can improve for the future (this element is derived from the kaizen philosophy of continuous improvement of our work). From my experience, I recommend holding such meetings once a week / two, depending on what time frame we take for our "Sprint". It's also a good way to implement one improvement at a time, i.e. if the problem is task estimation and the team ultimately fails to implement the scope it has set because it spends more time on individual tasks, then let's take the work on estimation as the element to be improved and focus on improving only that in the near term. For each task we will work on as a team, it is important to choose the person responsible for this improvement, because if there is no person responsible for the task, the task will most likely not be completed.

The list presented here are just a few valuable techniques that can be applied to project work and make it more agile, regardless of how it is implemented officially.