DEV Community

Farmin Farzin
Farmin Farzin

Posted on • Updated on • Originally published at farmin.dev

Leading An Agile Team

"Agile Sucks" Era

Almost a decade ago, I was a developer in a team of 3, my manager, me and a designer/dev! My manager decided to apply some Agile concepts in a team of 3. We had stand-up every day, planning every two weeks and a lot of tickets on the Trello mostly for me!

Obviously, at that time I wasn't really interested in Agile since I really didn't know what that was and I actually thought the whole thing just slow us down which was true. Although I didn't know how I can give feedback about it to my manager, cause I thought I am not smart enough to understand the whole point of it.

Then I moved to other companies and in almost all of them, they had A version of Agile with different meetings and different tools to use. Interestingly, none of them were great, everyone was just following some rules. There was no mindset, no thinking behind those actions and a huge misalignment between different parties.

Alt Text

Fast forward this year: I'm leading an agile team and still, I'm not sure why we call ourselves Agile really. But then our company hired a new manager and I started reporting to him.
The first day he told me he is a big fan of Agile and he is very experienced in building agile teams and will support us to make some changes around it. I was like, well I know, everyone is saying that these days so... alright...
So he started sending us to some courses around Agile mindset. I wasn't really optimistic at first, but after having that course I started liking it and understanding it.
Then he slowly started gathering some metrics from the teams and started revising some of our processes and monitoring our interactions with the product team.

After only 5 months, we purposed our Jira to gather useful data, we slowly changed the way people were moving a story between states and started building the mindset instead of making some guidelines or best practices.

But Why Mindset?

I believe this is the most important part of Agile, you need to have the mindset, you can have no ticketing system, no meetings, no scrum master or product owner but just having that mindset helping you in decision making and improvement in your way of working every day.

I don't want to talk about beliefs, values and principles here but those are the things that make your mindset in general.

Business Value

For me, everything changed as soon as I started to focus on only "business value". The way that I approach different issues or requirements is different now cause first I look for that value and I try to measure that. A lot of time I pushed back on product because of this and even they were happy after with the results.
It is all about what your users gain, if you are solving a most difficult issue but your users can't get anything out of it or not much, then you're doing it wrong.

Right now, in the grooming meeting before thinking about how we can tackle new things to build or new features to add or even fixing what we have built, I just evaluate the value that we deliver to our users. If it is really what we need now and move the needle somewhere then alright, I'm on board. If it's just nice to have or the product wants to make something loveable only, I push back as hard as I can.

Experimentation

One of the most important elements for success, if you are in the early stages of your product, is experimentation. You or product have a lot of hypotheses but do you have enough resources to build all of those things? do you have time to wait and see if the new feature works for everyone? I'd say no and if this is yes, either you're super lucky or you're in dark.

Never build a big feature if you're not sure about the impact. You can easily understand its value by running an experiment with some small part of it on a portion of the users. Of course, you need to have a proper set of tools for experimentation and it is worth putting some effort to build those before doing any feature work.
This is how "feedback loop" works and how you can build a simple, ugly but great product for your users.

Team Metrics

As a team lead or Engineer manager, knowing how your team performs would be one of the best things to know, right? but let's call it system performance and not team performance, it's not about people, it is about the system. I believe people are doing the right thing if the system has been designed in the right way.

So, I didn't know that and didn't have any useful data to look even. We had some stats on our ticketing system but it was really hard to make any conclusion or even act based on those since they were incomplete and corrupted.

So the new manager started gathering some meaningful data and explained to everyone why we need those and what we should do for making sure we are providing the right data.

The most important part of this process was to make everyone sure that this data and the results won't be used in any performance review and it is not about people. There would be no name in the report and it'll be only about the team.
This is not even for comparing teams, the only purpose of gathering this data is finding bottlenecks and improve the flow of the system and that's it.

There is a great book called Accelerate, it explains what are the important metrics to focus on, and how to improve those. All of those are based on the researches that have been done on the different organizations and find out what are the important things to make a performant team.

Conclusion

I really like to write more about what we did to improve our delivery and how we are more agile today because I'd have appreciated it if someone was telling me sooner.

I think still there is a lot of room to improve but having the right mindset put me in the right direction.

Latest comments (0)