I was reading an article called “Why Scrum Fails” by Jason Godesky. The link is here: Why Scrum Fails | Better Programming. It is pretty a list of much all the pitfalls Scrum contains. The author lists many points for why Scrum is not a good wat to achieve Agility. He criticized the increments saying that they do not focus on customers and giving working software. He then criticizes self-managing teams by saying that managers can interfere. They could see their positions threatened, since there are no managers in scrum teams, and try to squeeze themselves into teams. Managers may try to take management task from the developer’s shoulders as a good gesture but in actuality they take away the team’s autonomy. No one is willing to just give up their role in the company. The author also mentions a “monkey’s paw” situation where companies that want to have a quick and painless way to improve output get it and later stunt the company growth. This is mainly because companies refuse to use Scrum to transform the company but instead delegate it to a developer only thing.

This made me think of what I learned previously about Scrum. I thought it was a structured and reasonable process. First there is the Sprint where ideas turn to value. Then Sprint Planning to plan for the work that will be done. Then the Daily Scrum which acts as a progress report. After that the Scrum Review which inspects outcomes and determines future adaptations. Finally, Review Retrospective which plans for the future. All of this seems reasonable. Although, after reading the article I can start to understand the criticisms. There is no role for the managers. But to counteract this I want to add that the managers could just become Scrum Masters. Maybe the role could be divided into two and have middle managers be involved. Also, there is no focus on working software but that could be added to the Definition of Done. Easy fix. To be honest it is strange to be introduced to something as a positive and helpful and then to immediate learn that it has so many faults.

To conclude, Scrum is not perfect which makes sense since it is man made. Also, a lot of the problems in Scrum is just how the companies enact it. For example, one critism was that Scum is mostly limited to developers and not companywide. Still there are still flaws. Nevertheless, I still think it is relevant to companies and would like to use it in the future. Overall, Scrum is not scum.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

I was reading about the top four symptoms of bad code, and it reminded me of the classwork I did earlier today. At that time my group and I were learning about the Waterfall Methodology and the Agile Methodology.

But first, the article’s link is this: Top 4 Symptoms of Bad Code – Excella. To summarize, it lists rigidity, fragility, immobility and viscosity as symptoms of bad code. Rigidity makes code difficult to change and causes non rigid problems to stay unfixed. Fragility is when software breaks when it is changed. To simplify, it causes the common issue of when one bug is fixed and multiple spawn in its place. Immobility is when software can’t be reused which leads to code having to be duplicated. Viscosity is when the developer is hesitant to change their code. This can result in wasted time and energy.

Back to what I was saying earlier, this article made me think about how the symptoms of bad code would affect the development process under Waterfall Methodology and the Agile Methodology. Under the Waterfall Methodology, rigidity and fragility would delay the verification and maintenance process. Rigidity makes code hard to edit which would make the steps where a person would have to edit code especially difficult. Fragility would cause time to be wasted or worse, it could delay the whole project. Immobility would delay the implementation process since time that could have been spent somewhere else is being used to duplicate a piece of code. Viscosity has the potential to affect the deployment stage since it could allow a program with bugs to be sent to the customer. Think about how some video games tend to be published with bugs. If only one or a few developers suffer from viscosity, then it would only delay the verification and maintenance process.

Since the Agile Methodology is more fast paced any delay would be more significant. Rigidity, fragility, immobility and viscosity would all call delays or a rushed project that may not meet up to the customer’s expectation. Viscosity would allow problems to fall through the cracks. Immobility would waste precious time. Fragility would take away attention from coding and push it toward constant bug fixing. Rigidity would extend the time it takes to fix bugs.

Overall, I believe this article achieved two things: teaching me something and allowed me to make a connection to what I learned earlier. I liked that it was short, to the point, and easy to understand. I will use this information to recognize when I fall into this pitfalls and course correct in school and my future career.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.