Agile is always under construction!
Very often companies implement Agile methodologies and then leave them be or, even worse, let them mutate unpredictably. Most engineers see Agile, especially Scrum, as an evil process that does not let them code in peace.
Processes should stay alive and adapt. At Tide we are constantly searching for improvement, so below you will find some ideas on how to construct Agile so it works for you and not against you 😊.
1. Understand the BIG Picture
Make sure all engineering teams understand the Big picture. What are we focused on, what do we want to achieve as a company? How will we achieve it?
You do not want them to attend a presentation or a training, or to know where to find a documented roadmap, you want them to understand. This means a few things:
· They have enough domain knowledge to understand the business goals
· They have been presented with data on why we have these goals and how the goals will be achieved
· They provide feedback on both the goals and the ways of achieving them
Why do we want that? Why do we want people who build something to understand it?
· They will be more motivated
· They will come with a lot of ideas
· They will avoid mistakes
· They will know when and what to ask
2. What problems are our processes trying to solve?
We implement new processes all the time, but do we have an explicit understanding of why and what problem we are trying to solve? Make sure you start with this question in mind. Check the question once again when the process is created. Do we resolve a small problem with a complex new process? Does the medicine do more harm than the illness? Communicate the reason with all respective parties. Teams need reasoning in order to follow a process.
3. Feedback or Listen to understand
Most companies ask their employees for feedback and that is it. We have done our work here. It does not work like that. You need to understand the feedback- ask additional questions, ask for examples. Once understood the feedback needs a resolution:
· If denied ,why?
· If accepted ,why?
· What action plan is created?
Do not leave feedback in some document in the dust. It is only valuable when heard. Feedback gives you a lot more than answers to questions you have asked. You can measure team engagement by feedback quality, you can identify if something is not well understood across the company. It helps you react to the situation you are in.
4. Always have the customer in mind
Constantly ask the question “how is the software being used by customers?” Often teams focus on “how it looks or how it is built” and forget about how it is used. Make it easy and straightforward.
You can try to motivate your team members to become end users. This works well when your product is an online game, or another online product, and it is easy to engage employees to use it. The team will generate a lot of new ideas and will provide fair feedback if they can experience the product.
5. Bring the management to the battlefield
How often do you go to managers explaining a problem and they don’t understand what you’re talking about? This can make people feel discouraged and even angry. Keep in mind that managers are not at your level of detail, they may try to understand but they lack your context. If the problem is big and needs immediate attention, engage management, show them the problem in action. For example, invite them to a meeting where they will see it. Collect solid data that shows how the problem affects employees’ happiness, productivity, and the company’s revenue. Help management understand the problem.
6. Is the focus a mythical creature?
In an Agile environment we all know that focus is important: we split stories, we have MVP etc.
· Do our teams have a focus during the day, the month, the quarter?
· Do they know which task they need to focus on?
These questions are very simple, but critical. At each moment team members need to know the final goal and need to have the end in mind.
Managers, Product Owners, Agile Coaches need to be on the same page with. regards to what that focus is. Problems arise when they do not. Why does that happen?
· Lack of synchronisation
· Poor communication
· Disagreement etc.
The only solution is to bring them all together and directly ask about the focus, it needs to be said and all need to agree on it.
7. Build less IMPACT MORE
In the tech industry we always wish to build more. More features, more functionalities and we want to build them fast. We are eager to release as often as possible as many things as possible. We want to flood our users with new possibilities to use our product.
This is a misconception. We do not want to build like crazy, it is expensive. What we really want is to impact more. We want results, happy users. We want to solve real problems, so customers use our product. Companies need focus! And it’s not only our teams who need it, our product needs it too.
8. Proud to be good at multitasking? — DON’T be!
You can still find job ads where the candidates’ required qualities include multitasking. Do not fall for it. Multitasking is evil, it ruins your productivity, you do not have focus, you feel exhausted at the end and the results are not as good as expected. It is just how the human brain works. Do not let employees multitask as this will result in poor quality, a lack of commitment and burnt-out people. Let them focus and show do their best work.
9. Are you suffocating in tools and processes?
If you were to explain your Agile process and the tools you use, how long would it take? — A day, a month?
Make it simple, make it easy. LESS IS MORE.
In time, people tend to extend processes, make them more detailed, but also make them more complex. Always ask “Do we really need this? What are the benefits and what are the downsides?” Measure and compare them.
Everything you use on a daily basis needs to be simple. Start simple! Then inspect and adapt to make sure you stay simple. Complex workflows, tons of projects and boards make a lot of noise. They are a distraction.
Have only one source of truth. Try not to document everything that happens, it is just not possible and will leave you stuck in writing and not developing.
10. Don’t rush into new processes
When you need to implement a new process take your time to make it simple. It takes more time and even more understanding to do something in the simplest way possible. A process needs to be easy to follow, if it’s too complicated it will fail. Take your time to create a plan with clear steps. Ask a focus group for an opinion. Assign a responsible person for implementation and plan capacity. Often people create and implement processes in a hurry and in between other tasks. They need time and planning.
A process needs to be objective and should not serve the interest of a particular individual. It should not be created to address personal needs. All participants must be aligned with the pros and cons. Processes should serve a purpose and make our lives easier in the long run.
11. There is no need for everyone to suffer
Often when you introduce a new process, it is not perfect at the beginning, you need time to inspect and adapt. It is a good idea to start the implementation small. Choose one team and try with it. Choose wisely, there are always teams more open to change and more mature than others. Collect the feedback and adapt the process. The process won’t be perfect but the most problematic areas will be raised.
12. Be data driven
Always use data when a decision needs to be made, or people need to be convinced or motivated. Work with facts and numbers not only words and assumptions. Use a variety of data sets that can be easily explained and visualised.
13. Let it die
No matter whether it is a process, а tool or a meeting if it is not practical and useful, kill it immediately. Remove the noise and leave just the signal. You only need things that bring more value than they take time to be done.
14. Let the engineers code
Very often developers are stuck in an avalanche of meetings and they do not have time to code. This is not the idea of Agile.
Try to evaluate all your meetings and all the participants in them:
· Are all meetings needed?
· Are all participants needed?
· Can all of them contribute?
· Are all participants prepared?
· What do you want to achieve?
· Can this meeting be an email?
· Is there a detailed agenda?
· What should the result be?
Be aware, people may arrange meetings so others do the work for them. It is normal to ask for ideas and opinions, but it is definitely not OK to trick engineers to do your job. These meetings should be terminated on time.
As a summary, Agile should help you improve and scale, not keep you stuck in meetings and suffocated by tools. LESS is more 😊
Thanks for reading. If you are interested in being an Agile Constructor in a FinTech company check our positions at https://www.tide.co/careers/ .
