Hi folks, I found it will be for me the best moment to talk about my experience as a developer about the agile methods. As you may know, it’s been years now that this is the most used method in software development companies and there is no doubt about the fact that this is one of the best ways of organising a team.
But as said by the agile method itself, there is no good way of using this method. The agile method is before all a set of tools that can be used or not used based on the needs as each team work differently. As a developer, I’ve seen a lot of implementation of the agile method, probably a different one for each project I participated. In many cases, the implementation of the methodology evolved along with the project.
In this article, I will talk about the core points of the agile methodology and give my opinion base on my personal experience.
1. Scrum Master
The Scrum Master is the core point of the agile methodology. His role is really diverse but mainly consists of defining the entire project organisation and having it applied. As the agile methodology is supposed to match the project’s needs, the first role of the Scrum Master is to understand how the project team used to work and how to make a new agile organisation that can take the best of the old organisation while taking advantage of what the agile methodology has to offer. Beyond defining team organization, his daily roles are to animate Scrum meetings, to ensure everything is going well in the team and to be the relay between the project team and the direction. Also, an important part of his duties is to work with the project Product Owner in order to match the objectives of the product with the team’s organisation.
Concerning my experience, the Scrum Master has to be a natural leader. More than anyone else in the team, he has a global point of view of the weaknesses and the strengths of the team. This knowledge of the state of the situation makes him in the best position to make crucial decisions for the team. He is also in the best position to protect the project team from unrealistic demands from the marketing or direction team.
In some of my previous jobs, the Scrum Master was also the same person as the Product Owner. In my opinion, even if it’s completely quite possible to carry out a project in this kind of configuration, I find that the Product Owner who is also the Scrum Master unhealthy because the two roles are two sides of the same coin. They both want the project to succeed but no from the same point of view. The Product Owner role is to define what needs to be done in order to complete the project, his role is to be the source of truth for the entire project. On the other hand, the role of the Scrum master is to make this objective possible on a daily basis through micro management.
2. The Product Owner
The product Owner (PO) is the second most important person in a team project. His role is to define the overall roadmap of the project in conjunction with the management and to plan the various tasks to come. He is also responsible for the work completed. All of that means that he is the unique source of truth of the project and that he always has the last words. Day by day, his job is to plan the next sprint and fill them in with the user stories he has written and costed during the backlog refinements. His job is also to validate the sprint and all the work that has been done in order to verify that the work matches the acceptance criteria that he has defined.
In my experiences, the product owner is the mandatory part of any functional team. There is always the need of having someone that knows what are the objectives and can make a feedback to the team if the project is going well or not. But one of the key things of a Product Owner is that his role requires that he have a product vision. By product vision, I mean a critical look on what the product has to become realistically in relation to the constraints and realities that the product will have to go through. Unfortunately, in some companies, the product owner is only a “performer” with the simple task of executing what the management or the marketing is asking. In these cases, the PO is only responsible for making sure that the project will meet the expectations of his superiors.
3. The sprint planning
The sprint planning is one of the core ceremonies of the agile methodology. During this meeting that can be done with the full team or not, the PO announces the objectives of the next coming sprint. But first, he reminds what went well and bad during the last sprint in order to draw conclusions. He then explains what are the tasks planned for the coming sprint and what is the relevance of theses tasks in relation to the announced objectives. Then each member can speak up and react to the work ahead and finally give confidence score on the sprint to come.
I’ve been in many projects where the sprint planning ceremony was not even existing. The tasks that were not completed the previous sprint where automatically reported to the next sprint without even a discussion. The term of sprints was only used to divide the overall project into time segments each separated by a customer demonstration. In my opinion, it always has been beneficial to have a real state of the situation from the Product Owner about the overall achieved work. It helps everyone to understand the current team dynamic, the issues and the overall velocity. Also, the sprint planning is the best moment to explain the importance of some tasks, the objectives of the sprint and to react about everything announced.
4. The daily meeting
The daily meetings (sometimes weekly meetings) are meetings that are planned everyday or every week at a specific hour (usually in the morning). During this meeting which can be done with the whole team or part of the team, each member describes his objectives for the day to come and reports the problems he is facing and which may slow him down. The particularity of this meeting is that each member has a very limited time to express himself in order to have a meeting that is short and efficient. If a subject is supposed to take a longer time, I suggest bringing the topic up at the end of the meeting with only the required members in order to free up the time of unconcerned members.
5. The backlog refinement
The backlog refinement is a very important ceremony of the agile methodology. The purpose of this ceremony is to discuss and estimate future tasks that are planned for future sprints. This meeting is usually only with the members of a specific part of the project team. The meeting begins with an introduction to each task by the product owner explaining what features are requested or what changes are needed. Then for each task, a discussion can take place with the concerned people if certain points aren’t clear or if the team identifies a blocking point in the accomplishment of the task. Then if the tasks are clear to everyone and ready to work, the team is asked to estimate the tasks in terms of complexity, generally using the Fibonacci sequence. Theses scores are then used by the Scrum Master and the Product Owner to estimate the velocity of each member and more generally the project team.
In my experience, the backlog refinement is absolutely mandatory as everyone involved in the meeting can discuss each task and identify problematic points in advance that may lead to unachievable tasks later. But I’ve been in project teams where tasks where simply not estimated or estimated by one person. Both situations inevitably lead to a lack of predictability because the one who performs the task is not the one who estimate it, which can lead to a delay in the schedule of deliveries.
6. The sprint review
The sprint review is an agile ceremony that occurs at the end of each sprint. The purpose of this meeting is to make a global review of the achieved work during the sprint. Usually, each person or each group of people is asked to demonstrate the work they have done throughout the sprint with the possibility of discussion or questions with the other people present in the meeting. The people present in the meeting are usually the entire project team with the Scrum Master and the Product Owner with the potential presence of the marketing and the management team. After the demonstrations, the product owner and the scrum master giving an overall feedback on what went well or badly during the sprint and draw conclusions in order to improve the team dynamic and the success of the future sprints.
As this is a very formal meeting, I wouldn’t have anything very personal to say. Simply, this meeting is usually the best opportunity to present the work accomplished by the whole team and to show the project’s state of the situation to all the people outside the project or above in the hierarchy that have a stake in the project.
7. The Retro
The retrospective is also a core agile ceremony that happen at the end of each sprint barely at the same time as the sprint review. The purpose of this meeting is to give each member of the team time to express themselves in a less formal way than other meetings. The meeting structure is unique as it is very often gamified in very different ways. There is today a lot of online web tools that simplify this kind of meeting structure while allowing everyone time to express themselves. One type of structure of this kind of meeting is to give each one post-it notes that they have to stick on a board where different categories are drawn, theses categories can be things like “Things that went well during the sprint”, “Points that slow us down” or “Things that want well during the sprint”. The main goal here is to make a focus on the big success and big problems of the last sprint in order to make decisions and make the next sprint even better.
My experience of this meeting is really mixed. I found it super interesting on the paper but turns out to be not very useful in reality. I think it’s really useful for a team to have a real time to express themselves on what they think about the situations and how we can all improve to work even better as a team. But I found to main problems with the retrospective meeting. The first one I found is that nothing is really learned from the problems that have been brought by the team members. Usually, some actions are put in place but are rarely materialized for different reasons. The second problem I’ve found is that the retrospective is a meeting that is not taken seriously. Too often I’ve found myself in a meeting where everyone is having fun and talking about everything except the project. The best way to illustrate this is what is called an “ice breaker” which is a fun game that takes place at the start of the meeting with the aim of relaxing everyone. I found it to be a huge waste of time with very little benefit.
8. Why not using a clean method sucks
Despite all the qualities I found in the agile methodology, there is still some companies that refuse to use organisations methods such as the agile methodology. Before briefly discussing what are the real advantages of using an organisation methodology like Agile, let’s first discuss the disadvantages or why it can be difficult to implement such methods:
1. It requires a dedicated person for the role of Scrum Master
Unless the Product Owner and the Scrum Master are a single person, you will need to hire a dedicated person to take on the role of Scrum Master. It means one more person to pay and manage. While the benefits of having a dedicated person to manage your project organisation are enormous, this is something to consider.
2. In many cases, this completely requires rethinking how the team works until then
This issue occurs if you are integrating Agile into an already existing project with a different organization or if the team has never used methodologies like Agile before. In either case, bringing a new way of organizing to a team that is not used to it can be tough in the first weeks. In the particular case of an already existing project using another type of organization, this will require redefining a lot of things, mainly the way the team interacted and worked until then. This will take a lot of time and energy. In addition, some members may be very reluctant to change their organizational methodology which can complicate exchanges between members and more generally the team productivity.
3. Agile inevitably leads to a lot of meetings
As stated earlier in this article, organizational methodologies like Agile do not force you to strictly follow the official workflow. Instead, it encourages each team to take what is right for them and to build a cohesive organization that can lead to success. However, Agile methodology involves a lot of team synchronisation points, which can be worrisome at first glance but each ceremony is really useful to make the team work more efficiently while effectively reducing uncertainties.
4. The best organization method with the worst product vision will not change anything
Despite the fact that having a clean and cohesive team organisation can bring a lot of good things to your team, it would be totally ineffective with poor product vision. One of the essential aspects of methodology like Agile is to divide your project into smaller blocks representing independent functionnalities which can then be estimated in order to know what to do, in which order thus giving maximum predictability. However, without a clear product vision, it’s impossible to anticipate, plan et estimate effectively the work to come which negates a lot of things that methodologies like Agile bring.
For all these reasons (and there are certainly others), some companies feel that they are not in a position to reap the benefits of these types of organizations and decide to achieve their goals on their own, often with a homemade organization. Unfortunately the companies I’ve worked with where no organizational methodology has been used have always had a very poor product vision and poor good practices overall. In this kind of organization, Developers are often just a link in the chain who are there to integrate a huge list of specifications one after the other in any specific order, usually depending of the models available. The team synchronisation and releases process are often chaotic due to unplanned work pushed at any moment.
Sadly, a clean organization could have brought to them:
- A very efficient way of synchronising the different people with the project team
- Each meeting has a clear purpose in order to not waste time
- A precise way of tracking the work done and the work to come
- An accurate measure of the team velocity of achievement
- A clear vision of the overall project and the objectives to achieve
- Clear deadlines with achievable goals
- Scalable model that work on teams of all sizes
- A very fine predictability
- Efficient to avoid delays et budget overruns
That’s all for my experience feedback on the Agile methodology. I tried to be as objective as possible even though I can’t hide that I’m a big fan of agile methodologies. During the early days of my young developer career, I’ve worked in so many poorly managed project that when I discovered Agile, I was totally convinced and still continue to be impressed with the ability of it when it’s well set up.
I hope this article gives you an interesting point of view !
Happy Coding.
JG