Introducing or Fixing Agile? 5 Tips to Succeed
Preface: Applying agile and scrum is not trivial. Each team is different and you have to adopt and adapt. 5 concrete tips that you can start applying today.
Intro
Agile is a set of principles. These principles when put in practice can be manifested as Scrum, XP or Kanban, just to name the most iconic ones.
Scrum is not easy to apply, despite being widespread across software teams around the world. During my career, I have participated in various roles in scrum teams, and I have identified a few typical barriers teams are facing while adopting Scrum.
1. If You're New, Adopt the Team's Habits
At artkonekt, we frequently work as extensions of the client's teams where we have to adapt to existing systems, habits and constraints.
Another frequent scenario is that we are hired as experts in a specific area and we gradually have to train the Client's internal team members. In such cases, the goal is to establish good foundations and ensure any improvements we introduce will survive us.
The key takeaway is that if you're joining an existing team, you need to act in a way that your addition brings ease and not a burden. Such acts require a lot of flexibility and a combination of technical, organizational and psychological effort.
2. Build Leaders
Even a single person leaving or joining a team induces a change in the team's habits. Once a team's habits change, after some latency, it will provoke changes to the team's processes.
This has a very important consequence on you if you're attempting to apply or improve scrum for teams: you must build leaders because you want to make it work without you.
You don't want to witness a disaster when you come back from Holiday, do you? Leaders you build will internalize the key principles and continue improving and adapting them without you.
3. Give Trust, Build Trust
It's impossible to build leaders by telling them what to do. You need to listen, absorb and then understand their struggle. This is the very first step.
Without listening, you'll build walls. This happens insanely fast. Once the wall is up, you may never be able to cooperate with that team again.
I personally saw this happening, and yes, I was also guilty of building such walls.
One of the very natures of trust is that it must be mutual. Albeit sociopaths can successfully hijack this, trust is bi-directional for most of the "normal" people. Once it stops flowing from one direction, not much later it will stop at the other party as well.
Therefore, you start by trusting others. It's paramount. There's no "but", "if", "only", "unless".
YOU START by trusting others. It's not 100% that you'll get trust this way, but it's 100% that you won't get it the other way.
If you manage to build and maintain trust, it gives you a very strong safety net during bumpy periods.
4. Don't Fix Problems That Don't Exist
When you are entrusted to apply or improve Scrum, you are required to be a Leader. Leading activities, inherently affect multiple areas. Applying scrum is not only an organizational act, but it also has an inevitable side effect on the tech part, including codebase. Applying scrum will necessarily change the dynamics of communication both within the team and towards external stakeholders.
It's a great responsibility and therefore you have to be very careful and stay away from fixing problems that don't exist. It's a natural approach that if solution X worked for case A we'll attempt to apply it for case B. It may or may not work.
Rather than coming with solutions, start with identifying the problems. If you have a problem list, you can start drafting solutions for them. Your toolset will be helpful of course but be prepared, there are always challenges you haven't seen before.
Don't blindly apply ceremonies just because "that's the way".
Imagine a team that constantly writes very good JIRA tickets everyone of them understands, but they have a non-scrum way of how they achieve it. In this case, you shouldn't force them to introduce refinements and sprint plannings, just because that's the standard. Likely they have other, real problems and they're starving for the fix.
Prioritize the fixing of really painful issues over everything else.
5. Don't Complicate Things
Many teams think that they're very special. In fact, very few teams are actually particular. Be prepared, they will explain why they're doing things in their particular messed up way.
On the contrary, it's very tempting to think that now you can create the best and most advanced team on earth.
When you think you're a magician, that's actually a warning sign.
At this stage be very cautious and tell yourself:
- Don't customize trivially simple things.
- Don't introduce processes for every case you have.
- Don't invent abstract terms for every small detail.
- Don't create lengthy PDFs no one will read.
- Don't create dozens of Confluence pages.
- Don't schedule many meetings. Meetings are like spice: absolutely necessary but too many of them causes nausea.
- Don't invite many people to meetings. That's the sign of notable uncertainty.
Keep things simple:
- Not everything is important. Be able to distinguish the important things from the small itches.
- Only write things down, that people will want to read. Not every meeting has to have minutes.
- Differentiate recurring from occasional. Focus on recurring items first and put occasional ones aside (unless they're really important).
- Start with "MVP" style improvements.
If you try to solve everything, you'll quickly kill your own and your team's productivity and morale.
It'll drain you and people around you. You're complicating not only your own life, but you're also making other's life bitter.
This topic actually has an entire book dedicated to it: It Doesn't Have to Be Crazy at Work.
Wrap-up
Agile at its core is a set of principles that helps running product oriented technical teams. It sounds simple, but it is not. It can be done well and can be done in a way that people will hate.
As a simple guide, use these iterative steps:
- Create a good atmoshpere,
- Establish a good level of communication
- Listen to each other
- Agree on the principles
- Introduce small and simple changes
- Repeat
Did you have similar experience? Would love to hear them in the comments.