Category: Featured Blog

How I Became a Salesforce Certified Administrator

How I Became a Salesforce Certified Administrator

This is my 3rd article on “How I became a …” So, I’m at it again, learning to do new things and going in directions I had not considered just months ago.

In February, I found myself sitting at a computer taking an exam for Salesforce Certified Administrator. Of course I’m familiar with this kind of setting, as I’ve already completed CBAP and AAC from IIBA, as well as PSM-1 from Scrum. I believe in the current economy, if you are in IT, certifications are a necessary part of ensuring you remain relevant.

But why go for Salesforce?

As I’ve mentioned before, I am a lifelong learner. That thirst for new skills, sources of information about the world and how it operates (or doesn’t operate, which is equally as important at times), is something that has driven me.

However, I needed to do something that would expand my usefulness into areas inaccessible to my previous experience. It’s not that I’m giving up Business Analysis, but that I needed to refocus it. And what I see from Salesforce will allow me to do just that.

Yet, these don’t really answer the question. How did I land on a decision to pursue a Salesforce Certification?

The short version is I got advice from some total strangers.

Well, they don’t feel like strangers to me because I’ve been listening to their podcast for over a year (3 years worth in 1 year). The ChooseFI podcast features two regular guys discussing Financial Independence, which I discovered can be highly relevant to Salesforce. In December 2019, I finally caught up with their backlog. And one of the last 3 episodes I needed to hear was actually released the prior December (remember, I was catching up). So 14 months before taking the exam, ChooseFI released what I was hearing 2 months prior. What was it about?

Go for it

This was one of those actionable messages in which I said, “I’m going to do that. I’m starting on that today.”

The guest was Bradley Rice. And his story gave me hope that that I can still start something new.

Remember my drive to learn? That’s well and good to have it. But it needs an outlet. Preferably one that can be marketed. And what I heard from Bradley was exactly that. A new world to conquer, along with an opportunity to combine the new skills with my Business Analysis background in a way that is challenging and opportunistic.

Personal Goals

The reason Bradley’s message resonated with me is how well it lined up both my experience and with my hopes and dreams. I have a goal of putting my daughter through college. I have a dream of working from home. And although I’ve worked remotely for clients, that work was actually performed in an office 50 minutes away. I have a vision of a sustainable business that I can run from anywhere. But getting the clients has been a challenge.

The story Bradley told answered all of those goals, hopes, dreams and visions, and a few more that I’ve not mentioned here.

Beginning To Learn

Bradley described enough of how to get involved with Salesforce that I had all the knowledge I needed to get started – or so I thought. There’s more to learn than I had imagined.

The first step is signing up on the Salesforce training platform, Trailhead. This is amazing because it allows up to 10 fully functional training copies of Salesforce to be used as a playground for all of your training. And if you need to, you can delete the older ones and spin up new ones in just a few minutes. Plus the cost was a very prohibitive $0.00.

The training materials walk you through everything. There are career and certification paths defined for administrators, developers, consultants, architects and partners.

Trailhead gamifies the learning process. Each module has a maximum number of points for completion. Badges can be earned associated with specific skills, and you can collect points and badges as you move from Scout to Ranger.

During this phase of my learning, I discovered Superbadges on Trailhead. These are the secret sauce for learning Salesforce. Superbadges are real world scenarios in which you must demonstrate that you understand how to perform a complex function, such as establishing security, building a platform or even writing APEX code. Where other badges walk you through doing a few simple tasks, Superbadges give you the requirements and you have to apply what you’ve learned. One of the Superbadges (Billing Specialist) required stringing together about 10-12 steps, in the correct order, to complete only one of the 10 challenges, so they can be very tough.

Superbadges have the added benefit in teaching how to research Salesforce. Since the answers are not apparent by any means, you need to look through all the documentation available on-line. Being able to research is a key skill that I have as a Business Analyst, so again, Salesforce dovetails nicely with my experience.

My first three Superbadges were Security Specialist, Lightning Experience Reports and Dashboard Specialist (Lightning Experience refers to the latest-greatest technology for building applications on the Salesforce platform) and Business Administration Specialist.

There are even some non-Salesforce topics included, such as resume writing, management philosophy based on Drucker, meditation, health and wellness.

Within about 2 months, I had devoured the Trailhead material for Administrators and was ready to prepare for the certification exam.

Final Preparations

In addition to the hands-on experience provided through Trailhead, I joined a group Bradley formed (Learning Salesforce and Building Your Talent Stack) that helps people navigate their Salesforce career transition. From there, I heard about a second source called, which provides sample exams and preparation guides for about $19.00 each – still a great bargain.

Going through FocusOnForce provided me with a better understanding of the philosophy behind Salesforce. Where Trailhead showed me what to do, FocusOnForce taught me how to think.

So in February, I signed up to take the exam, and passed.

Leveraging the Investment

A funny thing happened shortly after certification, a little thing called Covid-19. Now all of a sudden I have a lot more competition for Salesforce jobs. So how do I overcome that added obstacle.

Well, frankly, I’m still working on that obstacle. But here’s how I’m tackling it.

First, I didn’t stop at one certification. There’s a related certification called Platform App Builder which expands on the ideas discussed in the Administrator training.

I already had a pattern for learning. I just needed to cover the additional material and sit for the exam. I finished this exam in April.

Additional Superbadges were also attained. At this time I am up to 8 total.

Team for Travis

Second, I knew I needed to get hands on experience. So I volunteered. Yep, while needing a job as much as anyone else during the pandemic, I volunteered to help a small Non-Profit navigate through the process of migrating to Salesforce. You’d be amazed how many opportunities come because you showed you care.

This gives me the opportunity to demonstrate that I can not only do the work required for a new installation, but it helps show that I can lead, train and coach others on the Salesforce product. There are several platforms set up to help connect non-profit organizations to professionals willing to help. Among them are Taproot and Catch-a-Fire.

I applied for a pro-bono position through Catch-a-Fire for a new Salesforce implementation. I liked that because it was completely fresh, which I felt would allow me to use both my Administration and my Analysis skills. After talking with the founder, we both discovered our stories have several parallels. And the cause was something I felt I could easily get behind. That connection is very important, especially for non-profits and pro-bono work. They want someone who they believe can help them for more than just a gig, to truly help with the organization.

My non-profit is a small organization called T.E.A.M. 4 Travis. This organization is founded by a wonderful parent who lost her son to a rare disease called Asplenia. Travis was a healthy, energetic and happy four year old boy who loved the Texas Longhorns. But the first time he got sick, his body couldn’t fight off the disease due to the undetected abnormality where his spleen did not function properly. Simple testing could have saved his life. Please take a moment to look at this page, learn Travis’s story and, if you can, support this organization.

And it’s showing me that my Business Analysis skills are still very much at work. In the Salesforce ecosystem, Administrators often do double duty gathering requirements for their organizations then building the changes. With the “clicks not code” nature of most of the development, it is quite easy to just build the required changes in less time than it takes to document them.

For example, we are currently discussing various options for documenting contacts made at networking events so that T.E.A.M. 4 Travis can leverage that information in future correspondence. In Salesforce, that is simple, but there are many ways to solve this problem. My BA skills help me find, while consulting with T.E.A.M. 4 Travis which of those ways is best.

Network Strategy – Embrace the Ohana

Third, I am building and expanding my network. I now have long timers in Salesforce who come to me whenever they pass a Trailhead Superbadge! One person has about 10 years experience, and started prior to the existence of Trailhead. So he knows this stuff even though he hasn’t been through the training. But he is very proud to share that he has reached these new milestones.

Salesforce talks about its “Ohana” culture, which embraces traits like helpfulness, involvement and inclusion. It is facilitated through a massive emphasis on Salesforce Communities. Many of these are topical, geographical or skill-set oriented. So I’ve determined to be a joiner.

Once I’ve joined, I’ve observed which groups tend to be more active and that also more closely align with my skills and goals. Then, I began participating (as best as I can while Covid is happening) and connecting with people who can help.

It is very encouraging how many people have been willing to help, giving tips, suggestions and leads. Some have cheered me on saying that I am inspiring them to train more.

What’s Next

I’ll let you know soon enough. But I will say, I’m not done yet.

We Are Neo

We Are Neo

Recently I was talking with someone who is transitioning into Business Analysis. One of the things we talked about is “What other job do you know where you get paid to learn from experts.” Our endless curiosity is met by an endless supply of industries, sectors, changing demands, new technologies, and on and on.

There is another side to that. With that endless curiosity comes an endless demand for applying what we learn – and sometimes for what we have not yet learned. Even for seasoned Business Analyst, there are tools and techniques that we’ve heard of but have not personally used.

And that creates a situation where…

We Are Neo

Who told Neo he could stop bullets?
Who told Neo he could stop bullets?

For example, let’s say a client needs to start embracing Agile but is struggling with a history of deciding everything before the project starts. As an Analyst, you may have worked on many Agile projects, and it’s second nature to you that some questions are not ready to be answered yet.

You do some research in the Agile Extension to the Babok Guide and discover a technique called “Real Options.” But you’ve not used this technique yourself.

What do you do?

You sit in the chair had have one of your Ebenezzer crew-mates plug you in to the “Real Options” program. A few minutes later, you know the pros, cons and concepts associated with using this technique.

Actually, that often is not as far off as it sounds. Oh, we don’t have a portal to plug into the Matrix. But we do have tons of articles, books, blogs and videos we can search.

The Choice Between Two Mindsets.

There’s a couple of ways you can look at what I just described. The first way is through the lens of “Imposter.” How can I claim to be something I’m not? They will see right through me.

The other way is through the lens of “Owner.” If I don’t do this, no one else can or will. Let’s try this and see if it works. If it doesn’t, we’re no worse off than we are now. And this stretches my wings as a leader for our organization.

To move forward we have a mindset that it doesn’t matter if I know it already or not. It’s my job to find the answers, not to have them already. So let’s go.

Consider this famous quote from Richard Branson:

If somebody offers you an amazing opportunity but you are not sure you can do it, say yes – then learn how to do it later!

— Richard Branson

There is a difference between this quote and what I’m describing. It isn’t always just presented to us. As Business Analysts, it is often presented BY us.

Agile, Shmagile – What’s so Great About the Agile Manifesto?

Agile, Shmagile – What’s so Great About the Agile Manifesto?

According to legend, 17 people went to Snowbird Ski Resort in Utah in February 2001, desiring to codify a document uniting their various methodologies. What they came up with was the Agile Manifesto.

Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Alliance


Three sentences and four bullet points upon which countless volumes have been written. Why is it that something so simple has become so transformative?

Clarifies Priorities

Let’s answer that question from the inside out. The first thing is those “bullet points,” or four “comparisons” have turned upside down the value system of previous problem-solving philosophies.

Previous to the methodologies which make up Agile, the focus was process and tool-centric. The problem is, it made people adjust to tools instead of having tools serving people. Agile puts people ahead of tools.

Next the Manifesto talks about how it is more important to have things that work instead of comprehensive documentation. That is not to say that documentation is unimportant. Instead, the implication is to avoid documentation that looks so far ahead that the finished product doesn’t match. In other words, it is better to document what works than what you think will work. Don’t document yourself into a corner.

The third “comparison” is my favorite because it talks about finding out what is needed instead of reading a legal document. The contract would not exist without the customer, and most likely, the customer is not the legal department (unless it’s a law firm). Customer needs are seldom adequately documented through a contract. So, when meeting the need, look at the customer instead of the contract.

The final comparison is also often confused. Change is the plan in Agile. It is a recognition that things change midstream. And if the plan is set in stone before the work begins, the product may be inadequate before it is implemented.

Broader Picture

The opening statement, “…uncovering better ways … by doing it and helping others to do it” brings up some broader perspectives. The first is the value of experimentation and empirical analysis. Some of the things brought out may be addressed multiple ways. The goal is to find the best of many ways to solve the problem.

Once we find the best way, be willing to share the knowledge so that other projects benefit from what is learned. In other words, let the feedback influence the decisions. A decision is not final until it is. Or stated a bit more academically, each item in the plan becomes a hypothesis to be proven, again and again, until that item is delivered.


If you’ve followed my blogs, you’ll know that I love to explore things that appear to be simple, but the impact is profound. That is one of the reasons Agile is appealing to me. No matter how much I understand, there are always new lessons to learn, and ways to overcome problems.

And it’s not just for software since Snowbird in 2001. Here is an article by Matt Hilbert published on Red Gate Software. The article traces Agile principles to the manufacturing of WWII fighter jets and the beginning of the Skunk Works.

How I Became an Agile Business Analyst

How I Became an Agile Business Analyst

A few years ago, I wrote an article about how Business Analysis found me. I cannot say that I found Business Analysis, since I was not looking for it. I did not even know what it was.

Well, how did I get into Agile as a Business Analyst?

Well, quite literally, I applied for a job and got it, then figured out what the job did. If you read my first article, that should sound familiar. Here is the story for my transition into Agile.

Lightning Strikes Twice

As a 2-year contract with a nationally known liberal arts college was ending, I was entering the job market again. I felt I had a significant impact on things while at the college. Among other things, I had begun a campus wide Project Office, helped negotiate some needed services when the college hosted the Vice Presidential debate, and lead an initiative to automate financial aid packages. Now I was looking for the next adventure. While looking at the job listings, I kept seeing this job title called a Product Owner.

In my first article, I admitted my confusion by the title “Business Analyst” because I did not connect IT projects to Business. I have learned a lot since then. Relevant to this story, I have learned that job titles do not always convey what job roles do, unless you know how those titles were derived. 

I kept seeing this title “Product Owner.”

I did not know what that meant. Why is a “Product Owner” considered an IT role instead of Marketing? Having experienced that unknown in job titles before (when I became a BA), I did not let it stop me.

Reading the job description, I could tell it had something to do with requirements. I figured I could handle that and I had heard of Scrum. So I prayed and applied.

A few days later, I was surprised to hear of my selection for an interview. The client was one of the major health insurance providers, which happens to have its headquarters in the region. 

I drove the 80 minutes to the location. Yes, that was a hike. The company has employees in several buildings in downtown Louisville. On my way in, I quickly discovered that I underestimated what happens when traffic stops on the interstate. Living in a small town, I had not seen that coming. As the traffic started moving again, my nervousness began to leave.

After finding a parking spot, it turns out I was only a few minutes later than I had planned, and the 15 minutes cushion I had given myself was just enough to help me find my way around the tower to the interview.

Just in time. Maybe that should be the basis for a delivery methodology.

Swing and a miss

Then my two interviewers presented a scenario on a whiteboard, and asked how I would communicate that scenario to a development team. 

Simple enough.  I squelched the thought that “You just answered the question you’re asking,” since they had conveyed the requirements to me. Then I gave my answer.

I thought I responded quite well, talking about the inputs, outputs and the processes of transformation along the way.

Strike 2

My interviewer prompted me saying, “Well, we don’t do it quite like that. Can you try again?”

Quizzically, I tried again, paying attention not just to content, but order, maybe they talk about the end result first. I might have added acceptance criteria from some previous experience dealing with User Acceptance Testing. I will not swear to that.

My questioner asked me to try again … again.

3-Pitch Strike Out

I know now this interview is toast. Giving up, I responded, “I know what the elements are, but obviously you’re looking for some magic formula. I don’t know it. But if you tell me, I’ll do it.”

That was the first time I had heard the phrase “User Story” or the format “As a ___ I need a ___ so that I can ___.”

Reached on a Passed Ball

On my way home, I called my recruiter to deliver the bad news, while simultaneously thinking what I would tell my family. Somewhere in the conversation he responded, “You got the job.”

To this day, I do not know how. Desperation I guess.

I started drinking from a fire-hose as soon as I got home and downloaded Mike Cohn’s book User Stories Applied to my Kindle App. Things moved fast, and it has not slowed down.

That was my introduction to Agile.

Transitioning into Agile Business Analysis

One of the recurring themes of my career is that titles do not really mean much. Each organization has a different lexicon for such things. Sometimes it is due to legacy overhead.  Others times, internal creativity outside of the established norm. Whatever the reason does not really matter as much as what those roles actually do.

The same is true for Product Owners, Business Analyst, and Agile Business Analyst. I have held all three titles while doing the same kind of stuff for different organizations.  So, in another parallel to my first “How I Became…” article, the Agile Business Analyst role itself is suffering from an identity crisis of sorts.

However, I do believe I should promote ideas and concepts in a consistent manner. So, in spite of what the broader market is, for the remainder of this article I will choose to go with titles established by IIBA.

So, what is Agile Business Analysis? This time, I will turn to the Agile Extension to the BABOK® Guide (Agile Extension v2, IIBA) for assistance.

“Agile business analysis is the practice of business analysis in an agile context with an agile mindset.” (Agile Extension, page 2)

That clears it up.

Maybe not.

I will have to break that down a bit. First, there are many ways to practice Business Analysis. To get a handle on the broader topic of Business Analysis, I would recommend the Business Analysis Body of Knowledge (BABOK® Guide v 3, IIBA).

Next, this is not saying that Business Analysis is Business Analysis whatever the Software Development Life Cycle (SDLC). Although there are commonalities, there are stark differences as well. For an Agile Business Analyst, the distinctiveness comes from applying the Agile Mindset.

So let’s go a little deeper to explore what that means.

Agile Mindset

The Agile Mindset is developed by applying The Agile Manifesto for Software Development to Business Analysis. If you’re reading this, you probably have at least heard of the Agile Manifesto.  But for a reminder, here it is.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

So, these are the guiding principles of Agile.  Any flavor of Agile.

Expanding on the Manifesto

It is interesting that the Agile Manifesto was signed in 2001 by 17 proponents of various software development life cycle methodologies such as Scrum, Adaptive and Rational, and it makes reference to software development in the first sentence – but the Agile Manifesto has much broader applications than software.  In fact, the case can be made that these principles were first put to paper in 1943 by the manager of Lockheed’s skunk works to develop experimental jets and spy planes. A far cry from modern software development.

In fact, there are many examples of the Agile Mindset being applied to all kinds of industries and sectors outside of software.

Going back to the definition of Agile Business Analysis, that means that you utilize principles that can be traced to the Agile Manifesto (or Lockheed’s Skunk Works) to Business Analysis.

But, what does that mean? How does that affect deliverables?


In Agile, whether you are working on Strategy, Initiative or Delivery Horizons, the key component boils down to a loop between Inspecting and Adapting. Inspecting and Adapting occurs on all 3 horizons, and is performed iteratively. This means that new findings can be added that alter the resulting priorities and the product.

The key is that these shifts occur based on feedback from all involved, as everyone discovers new insights into what can or cannot work and what is valued by the customer.

It is called Agile for a reason.

These feedback loops are built into the analysis at all levels to allow changes to occur up until just before the beginning of development of an item of work.

Contrast that to more traditional approaches where the plan is set in stone well before development begins. Changes are difficult and frowned upon. Rework is necessary after developing items who’s function should have been altered as more information was unearthed.

The benefit of continuous iterations and adaptive planning is that there is less rework due to changes that occur during the product. The change can be built into the end result.

This is not only for development, but for planning and initiative as well. On those levels, the analysis includes prioritizing organizational directions on a higher Business Architectural level. Areas of opportunity or risk mitigation can be iteratively and adaptively explored, with the resulting plans taking on more of the flavor of a hypothesis than a set path.

The results are that everyone knows what is expected, when it is expected and how it is supposed to work. With that knowledge, there is a drastic lessening of misunderstood requirements.

Well and Good But…

Now that we know what it means to be an Agile Business Analyst, how do you become one?

You could do like me and wiff on an interview. I would not recommend it. These days there’s more experienced talent out there who have worked with one of the Agile frameworks before. Although there is still much more demand than supply, I doubt you would find a company as … desperate. But still, the path isn’t that far off from what I experienced, though there is some newer developments that give structure to the way forward.

First, you need to be a Business Analyst. I’ve discussed that in my article on becoming a BA.

Next, study one or more of the Agile frameworks, or take a job in which Agile is utilized. This will give you familiarity with terminologies and techniques that apply to Agile frameworks, but not to traditional SDLCs.

Join organizations which promote one of the Agile variants such as The Scrum Alliance or IIBA. I like IIBA because it has a focus that prepares initiatives well prior to the delivery of the product. Their CBAP certification similarly expands the role of Business Analyst both before and after the project. I have found that broader perspective allows for a broader career path as well, such as into Business Architecture.

With a couple of years of experience, you will begin to see what it means when the manifesto says it values the items on the left more than those on the right. The thought process in that shift is profound.

Next, read the Agile Extension cover to cover, taking time to understand the implications of the Agile Mindset, and the 7 Principles of Agile. Learn what those mean to planning, communication, collaboration, value determination, prioritization and rapid delivery.

Now you’re ready to take the next step and get certified. IIBA introduced the IIBA-AAC exam about a year ago to certify Business Analysts that have demonstrated their understanding of how to apply Agile principles across the 3 Horizons.

And when you’re ready to prepare for the exam, please let me know. My local chapter of IIBA is preparing a study group for the IIBA-AAC exam this fall, and I am planning to lead it. I would love to see you there.