Shortcoming of Scrum

Hi Boss,

 

I am C.Line from Dev team. I was lucky to be hired by my company at the beginning of the recession. I am pleased to work with my old friends and team members again. Perhaps it doesn’t match the process to directly email you the issues mentioned in this email. But there is a Chinese proverb: if a person is going to die, his/her words are honest and friendly. So I am brave to express what I feel and think. At the same time, we have known each other for 7 years. You are a very nice, kind and smart person.

 

So far, many projects are managed with Scrum model. Its benefit is that any person can know the progress of features and what each developer has done and is doing. Its disadvantage is that all people mainly focus on features or tasks. Each developer is busing with his or her tasks, doesn’t take care about the whole structure. Especially, when we are going to improve the whole performance, if there isn’t person who controls the whole project evolution, fixing one issue may bring in new and more issues. (This is the disadvantage of Rob’s leave).  But when I discussed with other persons in other projects, they have the similar feeling that no one takes care about how to implement the features. Last month, when I visited Toronto office, we have the same feeling.

 

There are tech leads. But they are busing with their tasks too; and in fact, it seems tech lead has no enough right to request individual develop how to do. And if there are several tech leads, and they don’t agree with one another. Who is responsible to make the final decision from a long term? There result is that so far so good, finishing the task is the priority. The potential risk is that the source code is hard to extend or maintain. In the future, if there is a new feature or requirement coming up, some workarounds may be added. The more workarounds are added, the source code will become more complicated and difficult to read and maintain, and more time it will take to deliver our products to customers.

 

These days, some team members quit and some will be moved to other projects. When we take over their work, we find it is so complicated. Perhaps, some work must be re-done from scratch. The worst thing is that someone has pointed out the method or solution, which the team member who quit used is not good, several months or years ago. But there isn’t the person who takes responsibility to judge which solution is the better one from a high level and long term. So far so good! Therefore, if you are requested to take over the task done by the member, which you have pointed out the solution would make the code is hard to maintain, what will you feel? I think everyone doesn’t like doing some boring work or helping other persons fix stupid bugs. They want to do some challengeable work or the work with achievability.

                                                                                                 

Hence, I propose that we move some attention from the feature and task-oriented management to the framework design, extensibility and maintainability-oriented management.

 

All team members hope our products have good performance & high quality (you mentioned many times too), and are bought by more customers, and my company becomes better and better.

 

Thanks,

Cline