What Is A Scrum?

One of the challenges, albeit a minor one, is understanding the language used in business analysis.  It’s not that I’ll be learning new concepts; these words are just words that mean stuff that already have words for them.

The other day I brought up the Scrum.  I was looking at the VP-Technology’s calendar and he had a meeting called “Scrum of all Scrums.”  One of my former team members brought up that scrum is a word used in rugby.  So, I looked it up and:

Scrum is an iterative and incremental agile software development framework for managing product development. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal,” challenges assumptions of the “traditional, sequential approach” to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.

A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited. As such, Scrum adopts an evidence-based empirical approach—accepting that the problem cannot be fully understood or defined up front, and instead focusing on how to maximize the team’s ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions.

I’m not sure if I could find a synonym in laymen’s terms to say that.  But it’s an interesting concept that will take some time for it to become natural what it means when I hear it.

But the concept of scrum apparently is larger than just a way for people and teams to collaborate.  There’s even a position called a Scrum Master.  And there are other concepts built into scrum, such as a sprint, sprint and product backlog, product increment, burn-down, etc.  Not sure how many of those terms are used here, but I plan on understanding the scrum process thoroughly anyway.

Received permission from Scrum alliance

Though at first I was a bit reluctant (and suspicious) about this new role, I do find learning these new concepts fascinating.  Even eagerly looking forward to adding them to my repertoire of skills, if not replacing my old skills with these new ones.

There’s even a scrum certification.  Several actually, if it ever got that serious.

The challenge for me will be to learn these new concepts like scrum while simultaneously employing them.  It’s like building a boat while drifting further into the ocean.  Where do I start?  What’s essential to grasp now versus amenities that are more optional?  If  anything can be considered an amenity.  How will I know I get it, am employing it correctly, or even doing it right at all?

Whatever.  I’ll get it down at some point.

Who’d’ve Thunk This!?

So the COO asks to speak to me the other day.  Fast forwarding, I was being moved out of my current role — the one I’ve been in for years, the one I’ve spent the last decade of my career doing — to the development team as a business analyst.

Huh?  What?  Me?

After taking a few days to let the shock wear off and see the decision from a logical point of view, fast forwarding through the gruesome turmoil of emotions and gauntlet that my mind went through, I see how this is an opportunity that I should embrace.

Maybe a year ago, I presented an idea to the COO of a new role the company needed.  See, we have several different departments, all with their individuals processes.  And since each process is created in a silo, there’s no way of knowing if there’s an overlap or gap between all the processes where something is falling through the cracks.  We needed someone who would meet with each department, understand each department’s processes, what they want to accomplish, how these processes work with other department’s processes — and how they don’t — and most importantly, how to reconcile them so that all the processes put together form one unified, coordinated, efficient and effective company process that keeps everyone on the same sheet of music.

Well, that’s my new role.  Lead Business Analyst, they’re calling it.  My first To Do is figure out what’s a business analyst.

A business analyst (BA) is someone who analyzes an organization or business domain (real or hypothetical) and documents its business or processes or systems, assessing the business model or its integration with technology.

The International Institute of Business Analysis (IIBA) describes the role as “a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”

Interesting.  In my now former role, I was already doing that, to an extent.  Only I didn’t have the pay grade to compel other departments to change their processes.  The goal was always to get all of us talking in the same language, but I didn’t know how to say that in their language.

Now, that’s my job.

I have a long way to go to be where I want to be to say I know what I’m doing.  Speaking of language, there’s a bunch of new words I’ll have to learn to be able to really communicate with the rest of the IT team.  Sprint.  Scrum.  Use Case.  Instance.  One day in and already I’m Googling four words?

Anyway, as I always do when there’s a significant change in life, I’ve created this blog to capture this journey.  It’s more for me to take notes, save ideas, and more than likely, express some frustrations, but also to be able to look back at today and remember where I was when I started this journey.