Month: March 2021

There are several schools of thought around certifications in the Salesforce world, as there are in many IT segments.  Often in the Big #(who can keep up with how many there are today) category, certs are a prerequisite for employment and they count during selection.

There is another school of thought around certs.  It says they are all more or less meaningless.  While there is merit to both arguments, you won’t find many certified technical architects in the latter category.  They had to prove real knowledge in front of a board of experts which is no small task.

Of course, some certs are harder than others.  We’ve all seen a Certified Admin who took the test 5 times and finally passed it.  That said, one of my favorite certs to see in a peer is far from the hardest.  This cert doesn’t ask that you code anything, it doesn’t ask that you translate security models into weird sharing groups for community cloud, and it doesn’t require you to learn the 180 degree switch in framework that is marketing cloud.  This cert simply asks you to show an understanding of the very principles that Salesforce operates on.  You’ve probably guessed since the title that I’m referring to the Platform App Builder certification.

So, what is it?  Apple did a pretty good job branding the word “app” as a mobile application for the iPhone, but an app is really just anything you interact with on a device that has a processor in it.  As such, when we build something for users to access and interact with inside of Salesforce, we’re essentially building an application.

The Platform App Builder Cert is ultimately designed to test your ability to build an application inside of Salesforce.  To explain what it is, I’d like to describe the individual test sections.  The % refers to the approximate portion of questions on the exam that will cover that topic.  There are 60 scored questions.

Salesforce Fundamentals: 23% of the exam or ~14 questions

When you can’t find the solution on Salesforce, visit the App Exchange.
Do you understand roles, profiles, sharing rules, and how to manage logins?
Do you know enough to experiment with reports and dashboards, and will you share them correctly?
People have different screen sizes.  Some small enough to fit in their pockets.  Do you know how to account for that?
Chatter is great, but only if people use it.  Can you get them to use Chatter with customizations?

Data Modeling and Management: 22% of the exam or ~13 questions

Do you understand what a data model is?
Junction objects are crazy.  If you really understand them, then you understand relationships.
Do you find yourself using the word cardinality in casual conversation? (One to Many, One to One, Junction Object Magic, etc…)
The relationship type questions are most of this section and they make you think.  They deserve a third line.
What happens when you change field types, delete fields, and in general mess around with objects?
Can you read a schema builder?

Business Logic and Process Automation: 28% of the exam or ~17 questions

Who doesn’t love a formula field?  Do you know how to use them correctly?
Roll-Up Summaries are even more powerful, and even more complicated.  We’ll test that knowledge.
Validation Rules or an Approval Process?  That is the question.  How do you implement each?
When should you use Flow?  What unfortunate scenarios force you to resort to a workflow or Process Builder?  When you have to use them together can you keep them from breaking each other?
Some questions that tie it all together round this out.  Understanding this section will really help you avoid using code unnecessarily.  I’m glad it has the most questions.

User Interface: 17% of the exam or ~10 questions

Since it is the App builder cert exam can you create an app?
A basic understanding of buttons, links, and actions is key to this section.
Can you do things declaratively?
Lightning is objectively better.  Can you customize it to show that?

App Deployment: 10% of the exam or ~6 questions

We’ll give you some use cases, you explain:

• Change Sets
• The Deployment Plan
• Managed Package &  Unmanaged Package

​This section makes sure that we can get things in production without failing QA.

As I read through those areas, I don’t think they’re restricted to any role.  I think anyone from a Jr. Admin to the CIO could benefit from understanding these core tenants of how Salesforce works.  And for a dev coming from outside of Salesforce, what could better show that you understand Ohana?

The passing score is 63%.  This is probably where a lot of the hate comes in.  The exam is merely meant to show that you have a basic understanding.  Of course, we’re always aiming higher than a basic understanding.

But, while you could get lucky and pass the exam, more likely you studied a bunch of things that had to have helped you understand the “Salesforce Way” of doing things.  A thing I’ve always loved about Salesforce is that it draws together people from all walks of life, industries, and career backgrounds.  But, the starting point of buying into Salesforce is actually buying into Salesforce.  I think Platform App Builder shows that a person has.

Happy Trails on your journey to better understand Salesforce and the great things it can do for your business and career!  I hope you’ll look at the Platform App Builder Certification as an upcoming step!  If it is, visit the Trailhead page below to begin!

https://trailhead.salesforce.com/credentials/platformappbuilder

What does Scrum mean to you and your organization?  While Scrum is a fairly well defined framework, this question will elicit a different response in almost any organization.  Scrum.org defines Scrum as a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.  I like this description.

Scrum.org goes on to break down the role of a Scrum Master as fostering an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat

A Product Owner will often be a PM or Analyst depending on the organization/product size.  This person manages a fairly complex discovery process.  There are lots of failure points throughout this part of the process starting with finding the right individual to manage the product, but branching out much further.  Blockers occur when intra-department work happens, when a vendor is required, and when leadership shifts priorities for the business.  While none of these are directly related to Scrum Fundamentals, they will all make the process fail.

Next, we get into really planning timeframes and quality control.  The development team should be coming together here and deciding how difficult projects will be.  Point values are then assigned to tasks/sub-tasks, and the team takes ownership of the work.  All too often in this scenario, we’ll see the PM exert undue influence on this process because of business priorities.  Resources are often finite, and goals can be pushed from leadership that don’t align with them.  But, trusting the development team to gauge as a team the difficulty of tasks will have a much better prediction rate than other methods.   It’s important to keep our expectations aligned with reality during this process.

If this isn’t working, you’ll quickly be able to see results and adjust.  This is key to a good Scrum environment, and ultimately, we find the real problem with Scrum in most organization.  Any experienced developer can make a long list of what is often found during this process.  And a lot of what comes out of this is great knowledge for the team.  People can talk about blockers, and discuss different methodologies and best practices.  And a proper review of the points system and individual contributions will often help better gauge the hierarchy of talent in the organization.

But, there are many problems that we find in review that aren’t truly related to Scrum, but rather the product creation process and organization as a whole.  Scrum has no methodology to fix a vendor who takes 3 weeks to start providing support.  Scrum has no methodology for solving an insufficient budget from leadership.  Scrum has no methodology of to fix culture issues that often occur within an organization or team.  And Scrum can’t stop the natural disasters that happen during the course of business.

So, what’s the real problem with Scrum?  It’s when people have unrealistic expectations of what it is.  Scrum is much more than 4 bullet points on a whiteboard, but it’s by design an adaptable and lightwork framework that can fit into different organizational structures.  It’s not the end-all be-all of helping your development team to succeed.  Scrum can be an effective cog in the wheel when implemented and managed well.  It’s important we don’t get discouraged when we run into issues.

Luckily, the biggest problem with Scrum is resolvable.  Proper communication and expectation setting can go a long way to creating a successful product.

Have you been struggling to properly get Scrum working in your organization?  Alternative Solutions is your expert resource on all things Scrum and Product Development.  Schedule a conversation with one of our resources today about how we can help your team succeed!