Category Archives: Observations

Three things I like about Agile SCRUM

Posted on by

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.

Conclusion
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.

Challenges of Business Analysis

Posted on by

Working in the business analysis field requires certain skills and adherence to some methods or frameworks to organise the work. What isn’t apparent until you’ve worked on several projects are the challenges involved in the BA field. This article will describe just some of those challenges that BAs should be weary of when delivering BA services.

Education of stakeholders and superiors of planning work required

Whilst not realistic, some stakeholders sometimes think that because you are hired as a business analyst, that they can expect to see some BA artefacts as soon as one week after the commencement of your assignment. Whilst BA artefacts can be done inside one week, such as a communications plan, a stakeholder chart and a BA activities plan, we shouldn’t be ready to deliver parts of a business requirements specification this early. One way to manage expectations that may not be realistic is to inform your stakeholders of the process that you will follow. If you can show a high level view of how your analysis is done then this will help others readjust any unrealistic expectations that may have been made. Even a simple process of: elicitation; analysis; management; will help inform others of your method and expected time frames.

Creating productive workplace relations

To be an effective business analyst, you need to work well with other people regardless of their personality or profession. In the workplace, it is easy to start stereotyping other functional teams, however the BA doesn’t have the luxury of sitting back and making anthropological assessments. The business analyst must be willing to work productively with all groups that are involved. This doesn’t mean that you must befriend all your work colleagues. It’s important to establish relationships built on trust and respect. Eliciting information is a two way street. One can ask all the questions but the other party must be willing to cooperate and provide the information. Trust is an issue because in order to analyse a business, the stakeholders must trust you enough to give you accurate information. 

Delivering bad news

No one wants to deliver bad news so it’s understandable that the first few times, you might hesitate to pass on the news immediately. If the issue is something that you can’t solve on your own then you should notify project stakeholders as early as possible. In fact, even if you have resolved the issue on your own, you should still notify the relevant stakeholders of the interruption. At the very least, you can show your superiors and peers that you can be depended on to proactively address issues.

Keeping everyone informed (as appropriate)

Similar to the point above about communicating bad news, it’s also crucial to keep all relevant stakeholders informed about any news or progress. As a business analyst, you are the central point of information. It’s very easy to forget that there will be stakeholder groups that will be kept in the dark unless you keep all teams informed. This also serves to uncover any risks that haven’t yet been identified. In my experience, there is often a vital piece of information that is held with one or more stakeholders that would not have come to light if it weren’t for the dissemination of information.

 

The issues mentioned here are not the only challenges that can be encountered in business analysis. Depending on the complexity of the work, there may be several other considerations to address and balance. Being mindful of these challenges will help to deliver good business analysis outputs.

Business Analysis certification

Posted on by

To become certified as a Business Analyst, the most relevant qualifications are given by the IIBA. After roughly two and a half years of experience, you can be recognized as a BA practitioner by having a Certificate of Competency in Business Analysis (CCBA). After roughly five years, you are considered a professional and duly receive Certified Business Analysis Professional (CBAP) status.

While waiting, what can you do before achieving these certifications, or in between them? Continue reading →

How to take career advice

Posted on by

Throughout life we are lucky to have people around us that care enough about us to wish us the best. Due to this care, advice is always given around your career and what one should do next.

People in Canberra tend to advise others on joining the public service as it’s a great career option that offers job security. I find that this advice comes from people of an older generation. Perhaps a generation that values job security more than career diversity and exposure to different job roles.

So it’s no surprise that many local graduates aim towards the APS after finishing University. And this isn’t a bad option. Graduate places are limited so getting a job there can certainly be a confidence boosting achievement. Continue reading →

Don’t be boring: business analysts should have social skills

Posted on by

In the business analysis profession, skills, qualifications and an ability to represent one’s self is needed for success. Most professionals I’ve met demonstrate these abilities. However, meeting the above does not mean you are an all-rounder.

A BA is first and foremost a communicator. Therefore social skills must be a priority and they should be a strong characteristic of a BA. With all the interactions with stakeholders, it would be assumed that you will gradually develop social skills over time even without much effort. Continue reading →