Introduction
If you have every worked with Agile processes like SCRUM, you will see that there are lots of time for brainstorming/ stand-up meetings and pair working. Considering all the time that will be spent some will decide to ignore some of those rules and it may have dramatic effects on the quality of the solution/ total time that has been spent on the project.
General Idea
Back in the old days, there were people who analyze the needs, then some others had to design a system based on those analysis and at last there were some programmers who would implement the code. Generally speaking, the analyst was the only one who had to be the expert on the field of the project and based on his vision, the designers (some people with university degree in software engineering) would design a model and test it based on the analysis and the programmers just have to implement the model.
What happened in practice
* It was very hard to implement. Software teams were not mature enough to implement everything as the idea said so in practice, they spent a lot of time on design and analysis, but at the end the implemented result was far from what the customer needed. (because of the gray zone/ incomplete data/ low-depth analysis/ lack of software knowledge, etc)
*Around 60% of the time had been used for creating documents that no one would read or understand in the end. Add this time to maintenance time since the documents also have to be the updated.
*There was a big gap between analysis and implementation, so when they finished the implementation the customer might not need it anymore. (We consider it as a failure)
What About Agile
With agile we took out the over head of analysis and design. But it is not magic! nor miracle!
It simply says, choose some programmers who know basics of software design and can solve problems (we call them developers), give them authority to decide what shall they do and let them talk to the customer.
What If we remove the brainstorming session?
In Agile, Brain storming session is a meeting that your team decide about the time that they will need on each task. On SCRUM for instance, there is a session on the start of each sprint which can take up to 1 day. So many people will say: OH! the whole team for 1 day waste their time to decide about the time that they need?!!! I will ask one of them who has enough experience to do this instead, so I will win lots of time!
Well, then you will end up with a team that has no vision about the whole tasks, and therefore the code quality will decrease and you might end up with spending lots of time on merging/refactoring/maintenance instead.
Worst than that, if your expert don't describe what he had in his mind, the one that has to implement it might implement the task with another way, and he is not to blame since he have a limited vision and with that vision, his solution works fine.
What if we remove the pair working
Pair working is the process of 2 people working together on the same machine. Well, one is working and the other is sitting behind his hand to prevent mistakes.
Yup, you might say that it will double the time that you need to spend on each task, so why to work as pairs?
Well, it will prevent people from implementing a very complicated code that no one would understand, the maintenance cost will decrease since 2 people checked it line by line. And you have 2 people to handle the changes because both have the knowledge of the project.
* My experience: don't work as pairs when the task is simple, otherwise you will get board and you've wasted your time.
What if we remove the stand-up meeting
Stand-up meeting is for your team to understand what is going on while helping each other. Some would say that when we have a problem, we will ask each other, we are good friends, etc. but in practice I saw these scenarios:
*The one who is drawn in the problem: Software developers like google very much. They will try to find the answer to all problems there. While it is a good way to solving your problems, it is a wast of time if you spend 1 week to solve a problem that your teammate already knew,
*The one with lack of experience: It is really hard to ask a question for people who don't have
enough experience, because for them it is like admitting that they don't know. Also, other people are mostly busy in the day so they might be interrupted when the others ask too much questions. Therefore, it will be late when you see their code and understand what a mess they have made up.
*The one who is not Taciturn: In every team, there are some people who enjoy their inside world, more than the outside world and that is why they choose this job. If there is no stand-up, no body will understand what are they doing, their achievements and their mess up things.
*The one with complicated solutions: Software developers like to write codes that can be applied to a general issue and normally it is good, but not when they change a simple subject to a twisted and a lot harder problem that is hard to read. Of course, code review is one of the ways to prevent this problem, but it is simpler this way. Like when you see someone wants to spend 2-3 days to implement a simple service wrapper.
*The one with rondevu point:
Stand-up meetings is a rondevu point. It help the team to manage their time (developers don't like to wake up early in the morning so you might see someone who wants to start his day at 1 a.m :) )
It helps people to maintain their focus since no one will ask you a question when you are deeply in your task
Conclusion
Software development is not a concrete block that you cannot change. You need to understand pros and cons and the application on your team in order to get the best result. So if you want to do Agile, but you want to get rid of any of the above, make sure that you know the consequences.
No comments:
Post a Comment