Boost Agility of your Agile
Hi! I’m Irteza. As you’re here, chances are you are an engineering manager or a team lead looking for ways to make more out of your team. In software development or any field actually, building an agile and productive team means half the success. I’m going to explain a few tricks to improve your team on the go. Now,
What is Agile?
You will find a lot of definitions online. Google says, “being able to move quickly and easily”. To me this seems like the most perfect and clear definition. Agility means flexibility and speed. For a team it means to work on such a flexible manner that you always can manipulate the workflow. Let me explain.
Say John, Mike and Alice are working together on a feature for a website which has a deadline. Alice is designing the UI, John and Mike are doing the code. Now Mike gets sick and has to take leave for a week. As a team manager what do you do? Postpone the release? Get someone else for a week? Or what if Alice gets sick? Will the developers halt their work without the design? I will explain a solution at the end of this article.
Let’s continue with the tricks,
Breaking your work
If you are working in a SCRUM workflow, you are breaking your requirements and tasks in Sprints (1–2 weeks period of work). In each sprint the tasks are divided amount each member depending on their work capacity (total hours in one sprint). These tasks should be well divided. While dividing you should assign a story point (number of hours needed to complete the task) for each issue. These story point should include the total time of completion. For example, for a front-end development task there should be the time for coding, feedbacks and some buffer time for communication. These story points should not be more than 8 hours (1 day). Meaning each single task a member has should be able to be completed in less than a day and the QA should be able to mark it for release. This way you have something ready at the end of each day and the workflow is always controlled.
Coding standard and review
It is a must to have a well-structured codebase to be able to have a flexible environment. Now, why does flexibility depends so much in code standard? Let’s go back to the issue with John and Mike. They both are developers working on the same feature and Mike is unavailable for a week. Let’s assume John and Mike follows different code structures. So when John starts working on some important task Mike was doing he will be puzzled. This is where enforcing an organized and structured code standard does the trick. For example, you can enforce a naming convention for classes and variables or maintain a coding style like Vue has one. You can enforce some principles too (example: SOLID principle) which can be very helpful. This way you don’t have any individual code styles and everyone understands and can work on each other’s code.
Peer Programming
The next step after ensuring code standard is to improve co-operation. Peer programming is when two or more people work on the same task at the same time. This is a great way to improve each other’s skills and team co-operation. Let’s say Mike woks on the front-end design and John does the back-end API. Now you have assigned them both on a design issue. Now John can have some ideas about HTML and CSS while Mike can rely on John to cover for if ever needed. Team bonding plays a very important role in a team’s success. Peer programming can be a strong tool to improve upon that.
Perfecting estimations
We talked about story points earlier. It is basically an estimation for the task. This estimation should come from the team members rather than the lead. The members should be able to understand the task, plan a way to do it and estimate the time they need at the first day of sprint. Say there is a production bug in the middle of the sprint and someone needs to work on it with highest priority. If we can have an accurate estimation (6 hours needed to fix the bug) from the developer assigned we can plan his rest of the sprint and maintain the workflow. There are a lot of ways we can achieve this. One way is to maintain a report of estimated points vs total hour log ratio after each sprint and enforce to improve it with time. This will also improve the analytical abilities of the members.
Retrospective
Retro is a team meeting in SCRUM that a lot of us skip. But for an agile team retro is a must. In this meeting the scrum team inspects how the last sprint went and how the next can be improved. Each member tells what went good and bad for them. The scrum master identifies the team issues they had in the last sprint and defines some initiatives to address those issues. Let’s say there was some issues with a requirement last sprint and the developers didn’t properly understand what needed to be done. The scrum master would take an initiative to do some improvements upon the next requirements (May be arrange TFA meetings). This would improve each sprints brick by brick. Each team have their different ideas for retro meetings. Here you can get some ideas on how to organize a retro for your team.
Documentation
In a team the most efficient co-operation tool is maintaining a proper documentation. This can range from release notes to code level documentation. Say, you start maintaining a Postman collection for all your APIs. Each time someone looks for an API you have them all listed together. You can maintain a short note for each feature which would include the requirements, the diagrams and the class names of the code written. Whenever someone needs to work on an update of that feature they can look at the previous notes and find the code without communicating the previous developer.
I’m sure after reading all these you have some ideas of your own and the issues with Mike, John and Alice you read earlier, you would be able to solve them on your own. I’ll leave that part in your hands. You will find a lot of solutions like these on the internet but the main challenge is maintaining them. One way to maintain good agile practices is to set OKRs and tracking the improvements. Building a team OKR and reviewing it occasionally would motivate the team to improve itself. These all will seem time consuming and overkill at first but trust me it will save a lot of time eventually. Thank you for reading this article.
