Do it your way (to become truly agile)
By Indrek Voksep, Product Team Lead at Scoro
In today’s world, it’s almost unthinkable to be building a software solution without using an agile framework to do it. Not long ago, agile was the buzzword on everyone’s lips. Now it has become almost a standard - you create software, you use agile development.
However, when a team decides to start using an agile framework (be it Scrum, Kanban, Extreme Programming – you name it), they tend to believe that each and every rule and aspect of these frameworks is the unquestionable truth. You wouldn’t assemble an extra wide IKEA closet without a manual – so how would you dare to implement an agile framework without implementing every rule in the guidebook? And that’s when you actually stop being agile.
Swiss Army Knives
Any of these frameworks could and should actually be seen as a multi-tool or a Swiss Army knife: a compact set of tools to help you perform different tasks more easily and adapt to different situations. But just like with an army knife, there are tools included that you hardly use. Some rules are like sewing awls on a medium-sized multi-tool. It’s there, but no one ever has an actual need to use it. This is why it is crucial to map out your current processes (presuming you have some) and to identify the weak spots, Make sure the model you are going to implement will help you and your team to overcome the problems you’ve defined.
Don’t go with the hype – invest some time and think things through.
Once you are ready to change your processes and start making preparations for the switch, make sure you don’t forget about your development team. Let their voices be heard in the discussions. Listen to their ideas and make them feel included. It will massively boost their morale and motivation and set you off for a good start.
It will also help to prepare the team for the near future, because in agile development it’s all about teamwork and communication. It’s also important for them to understand that going forward, the quality of their output will also affect the quality of the team's output. Also, it doesn’t hurt to remind them about the joint responsibility from time to time – even if you have been doing agile development for years.
Congratulations! You are now agile
Or are you? You have now used agile development for quite some time. The new world order has settled in, everything seems to be running smoothly, everyone is happy and motivated. You must be set for life, right? Well, hate to break it to you, but you’re dead wrong.
Being agile means you always have to be on your toes. Always monitor, always analyse, always adapt and always improve.
I’m going to take Scrum as an example, because that is what we use to develop our own product. In Scrum, an estimation meeting is one of the standards. The whole development team comes together, the product team introduces the user stories or tasks (depending on which format is used) and each and every member of the development team gives their estimation how complicated a certain piece of development is. The estimation can be given in story points, hours, days, etc. Again, depends on the format that is being used.
But what if I told you that you don’t need the whole team there? What if I told you that you only need a few members to be in those meetings and that you can create small rotations of team members between different meetings. And as a result, depending on the size of the development team, you can save hundreds of hours of valuable development time per year. Sounds great, doesn’t it? There are a lot of similar points of optimisation – you just have to identify them, try them out and adapt accordingly.
But what about lost information?
I know that it sounds like a recipe for disaster, but this is where the product team can jump in and put some extra effort in to keep it from happening. You should always focus on getting your development team totally in sync. Make it your goal that the team would be fully aligned. It shouldn’t matter if it’s a junior developer, who has been with the team for 6 months, or if it’s a senior engineer with over 10 years of experience under their belt. Their understanding of what needs to be done and their estimations how complicated it might be to achieve it, have to be the same.
For example, when someone from the product team is preparing those user stories or tasks for estimation, make sure they take some time to really dig deep and think of everything that might be affected by this new development. Include analysts, if needed. Ask input from the development team, if needed. It will save you a lot of time in the long run. The quality of preparation of these tickets (or tasks, or however you decide to call them) has to reach a level where it doesn’t matter if the developer who is going to work on it, was in the room when it was estimated, or on a 3-week holiday in Bahamas. It has to be fully understood by every developer, without any doubt, what exactly is required and what is the best and fastest way to do it.
In my opinion, “living the agile way” has to feel more like white water rafting on a treacherous river, rather than quiet paddling on a still pond. Agility means fast reaction, ability to adapt and making necessary changes when needed. If the river throws a sharp rock or a scary vortex at you, then you need all hands on deck to react and help steer clear from the danger. To do so successfully, the team dynamics have to be excellent – achieving this will take some time and hard work. But if you are not willing to bend the rules a bit and try to blatantly force a framework on your team (just because you read somewhere that it will double the output of your team), then you won’t even realize, before it’s too late. Your raft has hit a huge rock and 3 team members went missing in the water couple of curves back.
In conclusion, don’t get stuck in the rule books. Build the processes how you (and your team) see fit to become truly agile and always try to include the team when making decisions that will affect their everyday work.