The Way What I think Agile is
Agile is a word which been talking about in the software industry for many years, and for the last 5 years I have been involved in this idea which means to help us to be more productive.
But what I want to describe in this article is only my personal thoughts on what Agile means to me and I have nothing to do with the standard definition of Agile in case you feel like been cheated after you read it.
My Definition Of Agile
For myself Agile is a set of customized tools which help us to improve communication between individuals inside a team which have the same goal to achieve. And also the tools are well organized and keep improving until the end of the goal.
As you can see communication is what I think the problem Agile wants to solve, By improving communication inside a team could improve productivity. And productivity is not only time but also quality. There is also another important thing that is everybody in the team are enjoying the way how they work together.
Is Agile A Process ?
No! For me Agile is never any kind of process, it's a kind of theory of finding the most suitable way to help a team. And I think when comes to how to improve a team on developing software people always believe there is a certain way to follow and then problem solved. But I think the truth is opposite, the more people think it this way the more we are trapped by the process. Process is only one of the many methods to help carry out Agile but it seems people will choose it whenever they can because it's the easiest one to pick up and it seems work fine. But I want to say every team is different that's why I mentioned customize in my definition of agile, and retrospective is the way to do customize. The way how people work together can vary from a lot aspects like team size, industry area, team member personalities, international culture, delivery frequencies, timezone and etc. As I know there are no single process which can cover all those I mentioned here, Process is never Agile.
What We Are Talking About When We Talk About Agile ?
Whenever I heard someone mention about Agile there are some words will always appeared in those conversation: SCRUM, SPRINT, JIRA and etc. Yes, they are all awesome tools related to Agile, but the thing is nobody talked about the lessons they learned about how to use those tools. I know a of guys have daily SCRUM meeting, weekly SPRINT and all those estimation and retrospective game. But different people and team have different way to do the same thing, we know the name of those tools but it doesn't mean we could use it properly.
I have experienced a meeting started with 4 person but it ended with more than 10 person in it, everybody in the end were tired because it's need time to get the other 6 into this meeting during the meeting, and also when I looked at those confused faces when we talked about the topic of the meeting I know they know nothing about it. And people call it planning meeting. I think I'm a reasonable person, because I always believe everything comes with a reason. For this specific occasion I think there are something wrong: The goal is not clear, unrelated person, unprepared for the topic, not enough context.
Above case is a bad case but it did happened, and I believe it is happening even now in somewhere where people are tired of work and want to have a little chat with his co-workers. But at least this is a concrete case when I talked about how we failed in planning meeting and people can give help.
What's In My Mind To Find The Best Way To Do Agile ?
From my point of view the following things are the key aspects I need to think about when I think about how to apply Agile to a team. And again it may not work for you.
A goal is what we could say when the project is considered as finished. It has to go with necessary details about what it is, when it should be released, who is gonna use it. When all the information are ready, make sure you mentioned it a tons of times inside the team to let the team knows what they are working on. And be honest when caught by surprise by some questions asked by the team member, work it out later with them together.
I have problem when I ask a question people give me a general answer which it seems it can work in every way but in fact it leads to no where. I recently understand why this happens (It happens to myself too), In my occasion I just afraid to be wrong sometimes, but after many times of trying I come to know that this is not necessary, a conversation without a point will cause more hurt it will always leave the other wondering. Inspiration is about to resolve puzzles not cause puzzle. Talk something specific and leave the judgement later, everybody learn from mistakes it's also the same for the team.
As for myself transparency is very important, I don't like the feeling something is hidden with intention (privacy is out of this case, I'm not interested in gossips :) ) It gives people a feeling they are separated from the group, keep the team member posted will make later conversation more easily and the feeling of equality will resolve unnecessary misunderstand inside the team. Share information no matter good or bad, people are stronger and better than you think they are.
Estimation is a topic which people are loving to talk, because people have talked with me about it many years there still isn't an answer which can make most people feel right about it.
For myself I want to make it easier for me. I'm not a positive person, I always think things can be very wrong, so I always ensure don't to be too optimistic about estimation, but I always assure there are enough to do in backlogs. And priorities is considered very important in estimation, because the decision of do or not to do is based on priorities. Make sure you have a clear priorities, it will make the decision easier make the estimation less painful.
I personally consider retrospective is the most important thing in Agile philosophy. It reflects the idea of things could be improved step by step. Retrospective is not a one time deal, keep tracking what we did for the improvements, and really think about whether things improved with hard evidence.
Another thing is sometimes we put to much attention on things we are not doing so good now, we forget to mention things we are doing good, retrospective is not all above fix the wrongs it also about to continue doing the goods.
Take a little bit risk, all good things comes with risk. For example if you want to unify a component which be used everywhere, the risk is high because it touches a lot of code and if something is wrong you are the one to blame. So in this case I encourage myself to be brave to make things right in a reasonable pace.
From my understanding risk always comes with unknown to something which we are not familiar with, so try to do investigation and know it before you take the risk, no matter what the outcome is we could learn from it, even we only success once it will be a game changer. Imagine the time spent on one person to create something to help improve the efficiency of the whole team, it's worth to do.
A stable team is super good, but it's hard in reality. People will come and go, but the team still have the same problem to face, how good the knowledge is shared to new employees, to other team member which is not familiar with it means much to the team. The process of knowledge is transfered from one person to another is also a chance to explain things thoroughly, verify the idea behind and it also an opportunity to involve new brains to help optimize design and everything.
Don't be shy to give kudos to your co-workers, there are always tons of things you could learn from them, let them know when you feel like they saved your day. Agile for myself is also something about you are happy about it, when you feel about it express it.