Three things I like about Agile SCRUM

The Agile SCRUM software development framework aims to improve IT project success. Since it’s inception around the world, it has gained much support from IT practitioners.

I’ve had experience in performing a business analysis role inside an Agile SCRUM project. Here are the three main aspects I like about the framework. They are not the only things I like but the ones I appreciate the most.

Enforced communication and feedback loops

The Agile framework requires daily stand up meetings where each member of the team discusses the main achievements of the day before, what work they will focus for that day and if there are any impediments to their work. This allows for everyone to know what the team is working on and what issues exist. I found this to be really important as oftentimes, a problem which is identified by one person could also impact the work of other team members.

I also find that sharing what everyone is working on is a subtle way to keep everyone honest. In the workplace, it’s not hard to establish whether everyone is pulling their own weight and in Scrum, this becomes more obvious.

The ability to identify problems early and re-adjust

Agile SCRUM divides the work of the entire project into bite sized chunks called Sprints. These sprint cycles generally range from two weeks to four weeks however, different lengths of time can also be used. If the design of the software solution has any flaws or if the client change their minds, then this can be managed with limited impact. Sometimes an entire sprint cycle of work will be wasted but this cost is much less than changing requirements under a traditional model.

The simplicity of requirements definition through User Stories

User stories are a simple and practical format with which to convey the context and rationale for functional requirements.

The general layout of a user story is something like: As a user, I want to … so that I can …
I find that this relates the requirement in an easy to understand format while giving a rationale as to why it’s important. Each user story also has accompanying acceptance criteria. The use of the acceptance criteria further helps the creation of test cases.

There are many other aspects of Scrum that also assist in improving project success which I haven’t mentioned in this post. From a business analysis standpoint, I believe Scrum has several advantages related to communication, change and conveying meaning among the delivery team.

Why business analysis?

When I was growing up I had a few ideas of what I wanted to become in the future but none of them were about business analysis. In the early nineties, not everyone had a computer. I remember our family first got a computer in 1996.

From what I can remember, these are a few of things I wanted to be when older:
An ironman triathlete
A writer
A politician (prime minister of Australia to be completely truthful)

As a teenager, I had to revisit what I would become as it was becoming more urgent. By then, I at least knew I had to attend University to get ahead – I thank my parents for instilling this thought into my head. The things I realised by year nine (ninth grade) was that I liked solving problems and I could figure out how to use a computer relatively quickly. Little did I know that this would be influential in my decision to become a business analyst later on. Back then, I didn’t know what business analysis was but I was confident that the IT industry would provide a career that would utilise my interest in computers and pay well – the late 90s was a great time for IT professionals. Continue reading