In part 2 of our 'Living Our Values' mini-series, Deniz Berrak explores what the core value, "Embrace Change", means to her
As a company, lives and works by 6 core values. These values govern how we do business, how we plan for the future, and how we understand and support our team. In part 2 of our 'Living Our Values' mini-series, Deniz Berrak explores what the core value, "Embrace Change", means to her -- at and beyond.
As a company, Architech lives and works by 6 core values. These values govern how we do business, how we plan for the future, and how we understand and support our team. In part 2 of our 'Living Our Values' mini-series, Deniz Berrak explores what the core value, "Embrace Change", means to her -- at Architech and beyond.
When I first started as a Business Systems Analyst, I learned and worked within the Waterfall approach; I sat through months-long conference calls with the same people going through the same problems, I gathered requirements like a pro and documented my heart out. I tested, re-tested, and tested some more. Then came deployment and all of us sat together holding hands, praying to whatever we believed in and hoped the system didn’t crash and that millions of users weren’t affected. In hindsight, this may not have been the most expedient approach but, little did we know, there was an easier way.
At Architech, we apply Scrum Methodology to Agile Software Development. If you’re a classically trained Business Analyst, it may seem a bit overwhelming to make the transition from Waterfall to Agile but what I’ve learned is that it’s essentially the same thing, just packaged in a different casing. In this article, I hope to help bring clarity and show just how similar the role of a BA is in Waterfall vs. Agile.
As Business Analysts, you strive to understand business goals, requirements and exception scenarios in addition to identifying assumptions, dependencies and risks. The end result winds up being documented deliverables that are usually quite large and detailed. Business Goals turn into Business Requirement Documents, Requirements turn into System Requirements Documents, and so on.
In Agile we still go through the process of identifying goals and gathering requirements but we’re less concerned with making things perfect and more focused on diving in and learning from the process.
What I mean by that is that we want to get our requirements in front of the stakeholders as quickly as possible so that we don’t waste time building something that isn’t what they wanted (core value: fail fast!). For instance, if you have a client meeting instead of trying to focus on the end-to-end solution, you make a conscious decision to focus on one specific piece of functionality, like a widget on a webpage, or one report to display in a dashboard. You strive to elicit requirements around that particular function; why is it important, who’s going to use it, what business value does it have and how will end users benefit from it?
Once you’ve had just one meeting, in a typical waterfall project, you wouldn’t be ready yet to present your Software Requirements Specification (SRS), but that’s the beauty of Agile because you can, in fact, start formulating requirements right away. In this case, we just name them a bit differently and so Business Requirements become User Stories. Early on, I figured out a set of criteria for formulating effective User Stories:
As a (type of actor), I want to (function that needs to be built), so that I can (give context of business value).
Example: As a customer, I want to be able to view all available products, so that I can select and purchase the one most suited towards my needs.
These User Stories can be used as a starting point to discuss available options with your development team/tech leads and use them to put together a draft of the System Requirements - or in Agile terms the Acceptance Criteria to give the story more detail.
Acceptance Criteria will typically be a description of what this piece of functionality needs to achieve in order for it to satisfy the business needs/requirements.
Example: user should have the ability to filter products by: price, colour and style
Thanks to this foundational work, by the next meeting with your client, you’ll have your User Stories (Business Reqs) and draft Acceptance Criteria (System Reqs) for one specific piece of functionality. Once you review it with your client, you can make the necessary updates and pass it on to your dev team who now has an actionable piece of work they can get started on. You then go back to your client -- and while your dev team is working -- you go through the same exercise again until you’ve documented all of them. In the process what you’ve done is created a Backlog (repository of User Stories with detailed Acceptance Criteria) that your dev team will continue to work from.
What this allows you to do is facilitate continuous development integration which allows you to fix any issues before you get too far down the road. Your role as a BA is still the same, you just adjust your process and change the way you present your work.
As I mentioned in a previous post, I view my role at Architech and the work we do as falling closely in line with the company core values. The one most fitting to the transition from Waterfall to Agile is, of course, Embrace Change. The imperative here is: don’t be scared to venture into the unknown, you’ll never know how rewarding it can be if you don’t try. If you don’t flex, you break -- or worse yet, you don’t grow, so remember to Embrace Change at every opportunity and don’t let the unknown world of Agile deter you from exploring your potential.
We're always looking for great team members. If you’d like to grow with us, please reach out and see what career opportunities are available.
