Working in an agile Team

When I first joined my current company, as a software developer, I worked in a waterfall engineering process environment. I had a team lead which would give some job to do, and for the rest of the time, I could spend a number of days without interaction with other people. Working in those days was soul-sucking, draining my energy and motivation bit by bit. Things improved a little bit when I was moved to a larger team, and the situations were pretty much still the same, but with harder and complex problems to solve and this gave me a bit more motivation to work.

However, radical changes happen when our company moved to an agile approach in our engineering process. In the software development teams, the practice of the agile methodology was adjusted team by team. They were not the same or uniform. They followed the team dynamics and evolved as the team evolved.

Our team had tried a different variant of agile methods; Kanban, and from strict to flexible scrum. At the moment, we have two weeks long scrum sprint. Every sprint starts with a sprint planning, where work items are created. Story points are assigned to each work item using a voting system. One point is equivalent to one day. Previously, relative estimation was used, but we found it difficult to estimate properly and the relative estimation point could differ for each team members, make it harder for the team manager to allocate the team resource properly to the work within the two weeks sprint.

Every day, we have a daily standup. It is normally less than 10 minutes in total and each team members using the work item they worked on to report its progress and if there any issues. Any issues will be identified and relevant team members will discuss it later outside the daily standup. Issues can be resolved or sometimes it may need to changes the plan for the work item for the sprint.

Another sprint planning could take place mid-sprint to adjust the sprint board based on the progress and unexpected events that may occur during the first week of the sprint. Spike, or work item to investigate something such as potentially bug or enhancement, and elaboration are built into the sprint and can be just a work item themselves and this was in line with our Enterprise Agile process.

An the end of the sprint, we have a sprint retrospective, where each team members can give a demo of the sprint work, appraisal of the good work and the feedback for the thing to improve. The feedback can be both on the work and on the sprint process itself. At the end of the sprint retrospective, we vote 3 improvement feedbacks to be followed up and they will be included as works in the following sprint planning.

Throughout the year of adaptation, the current agile method form is quite stable and allows agility in our engineering process. In my mind, an agile approach is better than waterfall. The main principle is to adapt earlier rather than later, to change as the circumtances changes, and continuous feedback to improve things. So, whatever agile methods are used and whatever the stage of agile evolutions are, they should be just better than waterfall methods. I think the main principle can be applied to any kind of process for the better.

There is a multitude of benefits of adopting an agile approach to the team, as I noticed and experienced by self.

1. Interaction and morale among the team member improve. . Remember when I first time joined the company I could spend a couple of days or weeks on my own alone. That was suck if I can recall now! With an agile approach, you will need to interact with many people, and that is important to me as a human. That also makes my morale for working is higher.
2. Individual productivity increases. As the result or high morale, the productivity is improved.
3. Team productivity increases. As a result of better communication and interaction and increase of individual productivity, the overall team productivity multiples.
4. Communication skills improve. I experienced that my communication skills improve a lot since we adopting agile methods in our practice. This was a compound result of interactions with different people in different roles within the team. I interact more often with people of different roles, getting to know how the best way to interact with them and when I need to interact with them. Talking to junior development, developer, senior developer, architect, product owner, team manager and project manager each will require a different resolute. They are not the same in term of what they know and what is their priority and objective. Talking to a more junior developer, I need a bit more patient and explain a bit longer to encourage them to have the quality of code in mind instead of chasing deadline alone. I also take the opportunity to educate them about the concept and skill they need to know to grow. I spoke to the Product Owner when requirements are not clear, or there are conflicting requirements or to confirm particular requirements. He also acts as the final authority when we have a disagreement about the interpretation of the requirements among the team members. When I spoke to an architect or our expert dev in our team, I can speak freely about the quality and performance implication of the design decision. We bounce back a different kind of idea and assess the implications of each of them, I grow a lot from this kind of conversation, not only get the skills but more importantly the values and visions he has in mind. Speaking to the team manager always about the sprint and the planning, so anything that can affect the delivery of the work item, I spoke to the team manager. In our sprint model, a team manager is the scrum master.
5. Awareness working in a team structure. Working in a sprint, I become more aware of the team structure and how I fit into that structure and my role to play. I leverage the team structure to take some of my mental burdens. When I worked in a waterfall approach, I developed a product all alone, the pressure is all on me. Even though we have different roles to work together, I end up must carry the burden I should not have carried. Having that kind of pressure, it is hard to prioritize between meeting the deadline and ensuring the quality of code. Now having different roles working together in a team structure, the burden is shared, and working it is much more joyful. If some concerns belong to a particular job role, I just need to collaborate and passed to them eventually instead of shallowing all.
6. Less stressfull. Since now the responsibility is shared between team members, the works are less stressful.
7. No boring time. Every day, there is something to do, and because the story point estimation is normally moderate, you can really enjoy the work.
8. Equal vote for changes . In agile methods, each member has an equal vote for changes. Though it is not perfect, that is the idea. So, everybody have the possibility to make changes. Though junior developers may have less to say if he is very good at the process, he has the same opportunity to feedback during the retrospective.
9. Career progression insights. As we played quite nice as a team and everybody plays its roles. This indeed gives a lot of insights on what to be expected in each role and the level seniority as software developers. I particularly learn from the architect and learn the traits he posses and trying to imitate his values and visions. I am aware this may not for every team.