Things I do

I learned SQL pretty much at the beginning of my career while working in an AML-related position in Garanti BBVA Bank. As a part of my job; I was receiving transaction dumps, importing them to MS Access and then analyzing the data using SQL to see outliers, potential patterns, etc.

During my masters, I had “DB Programming with PL/SQL” classes where I learned the relational database model properly and then all the other, more advanced SQL functionalities such as cursors, stored procedures and functions. However, I can’t say I used these functionalities that much considering my position as BA. But, I used CRUD operations pretty intensively during my career whenever I needed to fetch some data from tables, create test scenarios, solve issues, generate reports and call stored-procedures to initiate operations.

While I was in Istanbul, my employer was using MSSQL so I used SSMS to work on DBs, while in Dubai we were using MySQL so I used MySQL workbench for day-to-day tasks.

I have 7+ years of experience with Agile methodologies, mostly Scrum, and some Kanban. I started my career working on projects managed with Waterfall, then I worked with make-believe Agile for some time and of course with the real thing extensively; so I have a deep understanding of those three.

I know how easy it is to misunderstand Agile and reduce it to rituals of having walls covered with sticky notes, an acceptable way of interrogating team members every morning and changing things arbitrarily without creating working software that solves problems. However, I also know that Agile can bring out the best in people and teams when it is properly understood and embraced.

I used Jira and Confluence to manage my tasks, deal with the roadmap, communicate ideas, keep track of requirements, and create and manage bugs. For some projects, I have created Trello boards to keep track of deliverables.

I have attended many training classes and seminars related to Agile, provided by the companies I worked for. I also believe Scrum Co-creator Jeff Sutherland’s book “Scrum: The Art of Doing Twice the Work in Half the Time” is a must-read for anyone trying to understand Agile from Scrum’s perspective and make sense of Scrum as a tool.

I believe it is safe to say that being a business analyst is all about communicating. All the tools I can use, all the knowledge I have and all my experience are there to ensure that I can properly and effectively communicate with stakeholders.

Obviously, communication here is not just about having the linguistic capability of understanding other people but also combining tools, knowledge and experience to make information move between the minds of people. The CEO has this brilliant idea of a new app, which should be understood by the people who will develop it. A tester should know the context of the feature to properly test it. A product manager should be able to interpret the verbal clues of customers to know if the new function will get traction or not.

Luckily, my first real job was answering customer calls and solving their problems in a contact centre. From day one, I noticed that people are not that good of conveying their situation, talking about their expectations and especially describe the solution they need. So I learned not just properly listen to people but also empathize with them; why they want “A new report” or “A button to delete data”, how they imagine themselves to use it, how I would use it… And of course, all the other tools come in handy; creating a mockup reduces the abstractness of an idea and elicit more information; most people think better when there’re concrete examples. A brainstorming session may bring the best in the people and create a lot of fresh ideas.

On the other hand, having the wisdom to know when to use these techniques can be much more important. A high fidelity mockup may cloud stakeholders’ judgements and prevent the creation of better designs. An untimely brainstorming session may cause a lot of distraction on what to do next.

I learned to communicate quite some time ago and for the last decade or so, I am trying to get better and wiser on it.

I was always interested in computers and coding so I read and learned a lot about them, as an addition, I have also studied various technical subjects during my masters such as “Introduction to Programming”, “Introduction to Java”, “Computer System Architecture”, “Design Patterns”, “Relational Databases and SQL” and “ASP.NET with C#”

I recently taught myself some Python in my free time to make sense of Pandas, NumPy and Matplotlib. Once I have even coded*DisclaimerWith using Google and Stackoverflow at every line in average a crawler to download all the XKCD comics. I enjoy computer-related subjects in general. I read or watch, and try to have a general understanding of them whenever I see something interesting.

So, I am not a developer by any means, not even close. On the other hand, my technical knowledge allows me to read technical documents and API specs, make sense of a block of code and most importantly understand the system we use and have a better idea about the technical implications of a project’s requirements. Of course, this works the other way around also. When a DBA tells me such and such functionality is not feasible in the current context because it would require a full table scan, I can interpret this properly to the business stakeholders or better yet start thinking about possible solutions that wouldn’t upset the RDBMS with a table scan but also fulfil the business needs.

This is mostly related to communication since a broad definition for “stakeholder” is “anyone who has anything to do with the product.” and management of them involves communication a lot.

Stakeholder management is a vital part of business analysis; the application is developed because a stakeholder thinks there’s an opportunity (CEO, a committee, external customer), for a stakeholder (end customer), by a set of stakeholders (developers, testers, DBAs, DevOps team, data engineers), with the help of some external stakeholders (vendors, integrators)

Obviously, all of these stakeholders are at different levels, have a different understanding of the product and possibly expect different project outcomes. A business analyst’s initial duty is to establish healthy communication channels with these stakeholders to understand their needs and motivations. Then, bring them together around the product vision, adhere to the project agenda and ensure that they carry out their respective responsibilities for the project, without having any seniority or authority over them.

Throughout my career, I had the chance to work with many different types of stakeholders. I was involved in projects where there are literally tens of subject matter experts with different priorities, technical teams with conflicting schedules, vendors delaying their part of the development.

I also worked in a startup environment where the CEO provided all the requirements and a development team coming from 15+ countries working on the project. I also managed stakeholders that are physically scattered all around the world; some in Europe, others in Asia and Africa.

Each stakeholder I worked with taught me something new about managing stakeholders. Sometimes it is as easy as understanding their motivation and giving them what they want, most of the times it is a “give and take” relationship where you also need to compromise.

However, It gets much more complicated when a stakeholder wants to use your project as leverage for their ongoing dispute with another stakeholder.

It may come down to invoking contract clauses, having serious meetings with colleagues or saying “No” to the CEO.

I have used a couple of different mockup tools throughout my career, such as Balsamiq Mockups and Moqups. I also know a bit of CSS and HTML, enough to modify existing webpages or create basic layouts. Furthermore, I also use Inkscape and GIMP to create basic icons, buttons and edit images, etc. In the end, depending on the needs, I am pretty capable of creating high or low fidelity mockups.

• 

• 

Flows and diagrams are other good ways of simplifying complex, abstract things in software development. A database diagram can greatly help understand how the data of a platform is organized, while a sequence diagram provides a deeper understanding of what happens when.

I used UML to create many different flow charts and sequence diagrams. I have also created entity-relationship diagrams for some projects depending on the need. I used MS Visio, and mostly draw.io in recent years due to its integration with Confluence.