Software Engineering + SCRUM

So here’s my blog/reflection for Week 2 of CS3216’s Lectures~

General Impressions

Well first up, here we are again back to learning about “Software Engineering Principles” in school again. I feel like the reason that most of us did not remember learning about AGILE in CS2103 (even though they taught it) was the fact that we just do not need to apply it in school, and thus becomes just another “fluff” model that disappears from our memories. Thus to learn about Software Engineering processes again, while good in theory would tend not to stick in people’s heads generally because they are unable to see the need nor importance for it. The difference then comes in whether you’ve actually experienced or practised these Software Engineering principles during an internship, and you only get to see the importance after going through it. As someone who went through SCRUM for 3 months during my internship, I got to experience and jump straight into the deep-end without having much of a prior understanding of what SCRUM was (cause I like other 2103 students just threw that knowledge away). To be back at learning software engineering principles again after going through it, I feel like it is something you can never learn in class but something you must experience in practise to ever understand or remember.

Key Ideas

Software Engineering is not just about programming, but rather in my opinion is to create a system that is sustainable and be able to craft out a product that is easy to maintain as well as enhance. This includes, as the lecture mentions, processes, programming and people.  Processes to set the right processes in place so you don’t end up with a Big Bang situation for example. Programming to create code that is extensible rather than monolithic structures that cannot be changed. People to have the right mix of people to be willing to commit to sustainability.

Other things, tl;dr. Waterfall bad, AGILE good. Well it’s not a blanket rule I guess, and I will elaborate more on it later on. But generally most of the lesson was on how to create sustainable systems, decomposing the system into sub-components creating components that are high cohesion and low coupling and the correct way to structure your tasks in order to get work done such as prioritisation. Also testing, testing, testing and documentation (the things every CS student typically hates in a project).

We also went through how SCRUM really works. (Which is about the same as what I had the fortune to practise during my internship)

Agree/Not Agree

Waterfall Bad, AGILE Good – Agree mostly for large complex projects. Disagree for small projects. Small projects can have the tendency to over-engineer if you implement AGILE on it, while it’s definitely a case to case basis (duh).

SCRUM (generally) – I think that SCRUM is a great procedure to make software development for flexible and adaptable, however I think that it is also important for people not to adhere to SCRUM religiously. By this I mean that SCRUM really works when you are flexible and it provides you a useful way to keep your team in touch while also easily prioritising tasks. However, I’ve also heard of cases whereby a SCRUM Master follows SCRUM so religiously that he does not allow any task to be added to a Sprint once a Sprint has started. While this definitely prevents extra work for the team, there are downsides in that the task he blocked was a severe bug in the application and he insisted on leaving that for the next Sprint even though the bug was crippling productivity. (Sounds ridiculous and without common sense, but it actually really happens)

SCRUM Time Estimations – Well, we all know that Time Estimations never go well. Even if we defensively say that we may take 1 day to do a feature that we may typically do in 2 hours. When we encounter certain bugs, it can take us days to solve something we thought was pretty straightforward. And when you encounter these bugs, you start to think that exceeding the time estimation is fine as it is a special case. Then slowly you start to let exceeding the time estimation to become the norm, and eventually you give up doing time estimations all together.

EPICs + Tickets + Sprints – The combination of Epics and tickets under Epics (in the JIRA system) with the use of a Sprint system can really increase the efficiency of a team. As it makes the tasks ahead that a team needs to do really clear, and thus it allows people a better gauge of how efficient they need to be with their work and how much time they need to rush.

SCRUM Processes – While SCRUM is great and all, there comes with it quite abit of downsides (that wasn’t talked about today). While I practised SCRUM we had biweekly sprints, whereby at the end we would do a Sprint Review and a Retro. These things typically took up an entire day, and 1 day out of 10 is almost 10% of the productivity gone due to meetings.

Questions I Have

I don’t really have any particular question directed to today’s materials, partially cause we’ve seen it all before and it is mostly just a factual retelling. However one thing that I am curious about is whether there are any new up and coming Software Engineering Processes/Principles? That may potentially overthrow or be a better alternative to SCRUM/AGILE?

Yeap that’s it!
– Jeremy