In the previous post, we outlined a simple process, which did not solely focus on development but instead considered the path a feature takes from definition to production deployment. A, well, release process.
And although for us Salesforce developers it seems tons of unnecessary overhead, there is a reason, why multiple parties are involved: it’s a system of checks and balances to make sure that features are stable and according to end-user expectations.
Imagine you shop online for a TV and you get delivered a simple 23” monitor. It’s kind of similar, but not what you wanted. And although you can see a movie on it, it will not fit the use case you had in mind when ordering a kick-ass UHD supersmart ludicrously large television.
A process introduces the necessary structure for defining, developing, testing and delivering a feature so you can watch the world cup with your friends (no jokes about Italy please…).
We also introduced Copado as our release management platform in the last post, and we did not ditch it. It allows to unify and drive the collaboration between teams, and there are specific items, where I think Copado help teams to do their job.
But I want to take a step back further, because in order to know how a tool can make a process more efficient, we need to understand how each team in a project impacts overall delivery time. So instead of talking about technology, I want to focus on people in this post, describe the roles typically involved in a Salesforce implementation, their tasks and what each team member can do to improve the flow.
Excuse me, but: what exactly are you doing?
Let’s recap the process focusing on the tasks per team member:
Define a feature:
Working in an agile way, a feature is usually defined by client business stakeholders, ideally by the product owner. As there are a lot of features to be defined and also tested, the project setup includes one or more business analysts to support the product owner in story definition, documentation and follow up. Toughened in uncountable meetings and armed with knowledge about the business process they tend to become advocates for the business side and bounce ideas with developers to get a feature done in a way business will like it. We could spend a whole post on that topic, but for now: time for action.
Develop a feature:
Well, do magic. But stay in time and in scope. Oh, and please, make it as scalable and maintainable as possible. You know, the usual.
Peer or Lead Dev review and rework:
Regardless if you just do a face to face explanation or if you use a more structured approach, such as a pull request: having your development reviewed has too many benefits to skip it. It prevents you from introducing a bad design crippling the project in the long run for short term success. Insights are shared within the team so there are no surprises. And you become a better developer through feedback.
If you work with Git (which is surprisingly easy with Copado), a pull request can prevent you from introducing bad items in your feature branch, which at the end will result in easier deployments.
Deploy to QA:
Well, this can be easy or an endless pain. If you work with Git, follow the golden rule, and you should avoid most of the issues:
– Review your commits and never include other people changes as part of your branch. (See why the pull request comes in handy?)
– Less references → less potential deployment errors or conflicts.
Test a feature:
There are elements in this world, which are natural opponents bound in eternal struggle. Water and fire for instance, or cats and dogs. And of course:
(copyright: https://www.monkeyuser.com/2018/the-struggle/)
Yet, without testers, our features would be less robust and might not be according to business requirements. Or even worse, we could break existing functionality. And believe me, you rather prefer a testers feedback, than explaining to your project manager and business sponsor why you broke the internet. On larger implementations, you are more likely to have a QA team focussing on writing and reviewing tests for current developments and automating regression testing.
Finally, the approval of a feature, at least in agile, can only be performed by product owners or delegated business users.
They ordered a TV, so only they are entitled to approve they received one.
Teamwork in software development is a real thing
Great, now we know the main roles involved in a project. But how does that help us to improve our releases? I mean, those business analysts, they don’t do development or any Git stuff; just talking, meetings and powerpoints. How can they possibly impact delivery speed?
A lot.
Analysts: Define and conquer
User stories are an easy way to capture requirements. Right? Well, yes and no.
Yes.
Because the basic format is easy. For instance: as a user, I want to see how much is an account worth, so that I always know on what to focus during sales and service.
No.
Because it misses tons of details. How do you calculate an account’s worth? Where should you see it? In which moment? Do we need information from other systems? If so, do we need it in real time? This simple story could result in fetching the latest orders from the ERP system on account page load.
Here is where the business analyst would spend time with the client, guide them towards a reasonable solution and future iterations and document it as part of the acceptance criteria.
Regardless of your project framework and methodology, good acceptance criteria fulfill at least three criteria:
- Provide process context.
- Provide enough information for the developers to know what to do, so they can outline a design and estimate the effort.
- Be precise enough to be testable. Who needs to log in? Where should you navigate? What action do you need to perform to get a result?
Ultimately, the time invested in documenting decent acceptance criteria will result in multiple benefits for other teams. For instance, less guesswork for developers during estimations and test scripts can be written in parallel with development.
As we use Copado as our release management solution, the User Story created by analysts will be used by developers to scope and deploy the changes. How neat is that? Definition, estimation and deployment all aligned.
Developers: A short cut for you but a long run for the team
After a feature is defined (estimated, prioritized and included in the sprint backlog) it is time to develop it. Done.
But is there anything a developer can do to increase process efficiency?
Just as the business analyst can impact overall speed by investing time in preparation, a developer can impact delivery to production investing time in working according to best practices and reviewing his or her work.
- Documentation, for example, is something most devs dislike, however it is crucial for others to understand the overall design and making informed decisions when moving the feature towards higher environments.
- Writing org-independent apex tests, which don’t rely on existing data. Just remember: every time you write @isTest(SeeAllData=true) a kitten dies with puppies crying and unicorns get sad.
- Do not hardcode references to a specific org. Do that and the unicorn will fade away.
- Check your feature branch, if you work with Version Control (Git). Always make sure that, whatever is committed in your feature branch includes your feature only. A peer or pull request review process can help to catch those wrongly committed items (e.g. reference to a field you don’t expect in a layout or a report type).
- Make reviewing easy. How? Well, what about pasting the URL for feature definition and documentation in the pull request description? Takes less than a minute, but saves minutes in searching for the reviewer.
- Perform a validation deployment towards the target org including running the test classes.
- Write down pre or post deployment tasks in an understandable way, because it might be that less tech-savvy team members need to perform them.
So that’s it? Well, not entirely.
With the right solutions in place, such as Copado, you can even go further, and there is a good reason to do so: there’s more than one deployment.
In our setup, there are two deployments required to release a feature. One to QA and another to Prod.
But what if your pipeline has further orgs? Staging, for example, a hotfix org and multiple dev sandboxes? In such a scenario, each manual step needs to be executed multiple times for different orgs.
Luckily Copado has some fancy logic under the hood, which can increase the level of automation considerably, so that you don’t even need to worry about hard coded references (yes, indeed).
In the next post we will take a closer look on how this can be achieved, but just as a teaser, the magic words are: Deployment Tasks and Environment Variables. And of course: “Please”.
Test team: Heavy lifting – easy testing
In an ideal agile world business testers would just check the functionality against the acceptance criteria and say yes or no, but the reality paints a different picture. Client stakeholders are caught between user story definition workshops, maybe their ongoing non-project work, internal stakeholder management and testing. Therefore a dedicated QA team can be of great value to drive testing effort, where better preparation results immediately in a shorter test time.
As soon as a feature is in a QA environment the clock starts ticking, so the core objective of the QA team is to make sure, that everything is ready for client business stakeholders to test and approve the functionality (or reject it (-_-) ). Here are a few things the QA team can do to prevent a story being stuck in testing:
- Ensure you have a test script indicating the steps to follow to achieve a certain result. If acceptance criteria are well documented they will come in handy to work on them in parallel to story development.
- Get the test script steps approved from a peer, who ideally dry-runs it on the dev org if the feature is available.
- Make sure testers have access to the org with the appropriate permissions to execute the test. Just in case, because who would miss something that obvious, right?
- Dry run tests in QA org, to avoid any surprise. Not required, but highly recommended.
- Identify a test owner who will perform the test, with the help of business analysts and/or product owners.
- Chase and support business for and during testing. Make sure they are notified and co-ride tests to support their efforts.
- Chase and support developers if issues are found and a fix is required.
If you think: “That sounds like a lot of documentation, tracking, monitoring, and coordination.”, you are completely right and tooling can help here which in our case it is an easy thing. We defined the user story in Copado with all the required agile information, then developers used it to commit and deployed their changes to QA. The test team can use the same User Story record to define their scripts and track execution. Nice.
Release Managers: Connect the dots to align
Analysts document, developers work according to best practices, testers prepare. So, what can release managers do to move features faster to prod? Apart from the obvious tasks this role implies (e.g. helping teams to fix errors and resolve conflicts) release managers are owners of the overall release process, the technology enabling it and as a result they need to run continuous improvement efforts. Sounds like lean management? Absolutely. Reducing errors, increasing automation and avoid waste (including time) are key lean principles – and still valid, although we produce software instead of cars (or TVs).
Ok, let’s say I’m a release manager. What do I need to do?
- Increase tooling knowledge. Regardless of which tool you use, you can only apply what you know, and being aware of what a tool can do is your foundation.
- Monitor and analyze the process. What are the steps done by the team? How long they usually take? Is there anything which you might have missed?
- Analyze challenges. Some deployments are easy, while others may take ages. List them down and investigate the root cause.
Once you have a good overview you can start applying your knowledge to tackle the issues:
- Identify and implement automation. Even smaller improvements add up. For instance, we could fire a message to the assigned tester as soon as a story is in QA and the script is approved. With Copado this can be done easily with a process builder.
- Document solutions. Usually deploying Salesforce metadata is easy. Select, deploy, hope, done. Yet some metadata types, such as profiles, standard picklist values or processes have their own tweaks to them. A good documentation of best practices and how to handle specific situations will enable teams to avoid pitfalls.
- Listen to the team. Yes, people complain – often with a valid reason. So although nobody likes to get complaints, resolving them will lead to improvements.
Because in Copado your overall flow is aligned to User Stories and you have the power of the force.com platform on your fingertips you can tinker around with your Copado installation to provide you the information required. With process builder, you can set up time stamps on the User Story object to analyze the time spent per step and identify bottlenecks. You can even make dashboards and share them with your team.
And if you don’t have a dedicated place where you store process documentation, just create a new object to document solutions, and another one to hand in suggestions (which you later can take as input for User Stories).
Technology does not implement technology. People implement technology.
With all the innovation, features and what not being released each week, we sometimes forget that at the end of the day you work with people. You might like one more than another, however everyone who participates in an implementation is bound to a common goal. There is real value in working together, communicating, helping each other at the cost of being nice. Even to testers.
And once you got your team mojo going, the next logical question is: How to make it faster?
Well, this is the moment when tooling is back on the main stage. Copado has some nice features on how to automate steps in your process and in the next post we will take a detailed look at how to set it up so you spend less time with clicking around and more time with the team.
And watching the FIFA world cup on a kick ass UHD super smart ludicrously large television.
