31 August 2019 - Managing change for enhancement requests

A while ago a post went out on Twitter asking for advice on change management processes when it comes to enhancement requests. I pinged back to say I would write a few lines for them. Their response to my work was; "wow, have you written this as a blog?" I hadn't, so I thought I would, with a few tweaks. Here it is.  

You’re now live in a Salesforce Org and now need to manage enhancements and change requests from many stakeholders in the business.

Each stakeholder who raises a request will consider theirs to be the most important.

As a Delivery team you may start to feel squeezed and pressured to deliver everything for everyone at the same time. Guess what, it's impossible. You’ll end up disappointing everyone and burning yourself out. You need structure before this gets really messy.

Here’s a way to do this:

Create a sense of product ownership within the business

What this means is identify key stakeholders, Department Product Owners (DPO), in the company who may represent different departments who use Salesforce. Have them as the go-to contacts for any requests set by their colleagues. Immediately you are starting to funnel your requests to a smaller network of people, which suddenly makes the task a bit more manageable.

Define a process for everyone to follow

This can start with any tools for the business to use to raise and track enhancement requests. Then decide who should have the ability to raise a request. Could it be any individual or just your selected DPO's?

Once requests have been raised then you can ask for your DPO's to triage them. This is a good opportunity to catch any that may not be required in the first instance. This could be due to a duplicate request or something that transpires as a training need for an individual. The ticket can then be closed or an action for follow up training. 

After the initial sifting by the individual DPO then put in place a regular meeting (one per sprint) for all the DPO's and a Business Analyst to get together to review all the requests. Are there any that might have conflicting functionality needs? This can be common when sharing the same Org environment. Creating a forum where departments can learn the impacts of their requests on others can be enlightening. It can help to avoid potential conflicts by airing concerns before anything is built. If at this stage there are tickets that have been agreed by all the DPO's not to proceed with then it is the responsibility of the DPO to communicate back with reasons. You'll note that so far it is the business that is self managing their requests and not the Delivery team who is pushing back.

Prioritise

For the requests that the DPO’s feel are worthy to proceed then next part of the meeting agenda is to consider their priority. By asking the DPO’s to accept tickets and agree their priority it takes this away from the Delivery team’s concerns. To also gives full visibility of the amount of requests that are coming into the Delivery team to action. It’s a political gain, the Delivery team are no longer seen as the blockers to any configuration. Instead, it is their own business colleagues.

Once the priority of tickets have been made then the Delivery team can see if there are any that have dependencies or cannot be done for whatever technical reason. If these exist then communicate back to the DPO's asap with the reasons. A re-prioritisation process made be needed. 

Refinement

The tickets raised may require refining to ensure that there is full understanding of the requests and what their desired outcomes are. Bring together a ‘3 Amigos’ meeting once a sprint. This Refinement meeting is to look at all the requests that have been raised and prioritised. The 3 Amigos are: the BA to represent the business and ensure the needs of the requirement are fully expressed, a ‘Developer’ to solutionise and estimate and a Testing resource to see what is being requested and how it can be tested and passed. 

Prioritisation done, solution done, now the delivery team can see when a ticket can be worked on in a sprint, known as Sprint planning. This will depend on the velocity of the team – how many tickets can be completed within the sprint time. There could be a chance that not all requests can be completed within the sprint. Communication back to the DPO's is needed to manage their expectations and maybe further prioritise on which tickets to tackle first.

Work delivery

Many development teams now work in a more Agile way, breaking up the workload into Sprints so that at the end there is a useable product. A sprint is a defined unit of time to work on a particular activity and is often 2 weeks in time, but you can define the time duration that suits your business. 

During the course of the sprint work activities will include Agile ceremonies: daily stand ups, refinement meetings with the business to clarify anything, sprint planning, delivery demo’s of items produced in the previous sprint, and a Development team review and retrospective at the end.

• Daily stand up: for each member of the team to state what they are working on and if they have any blockers with the aim to keep momentum going to deliver the useable product
• Refinement meetings: To understand what needs to be delivered and how to go about it
• Sprint planning: to organise when item will be worked on
• Delivery demo: to show and tell what has been built for immediate feedback from the DPO should any changes need to be done
• Review: for the delivery team to share their learning from the sprint on any new functionality so to avoid any single points of failure
• Retrospective: to share what went well, not so well and what to change for next time. A process of continued learning and improved changes within the delivery team

Let's talk more about the Delivery demo. This is the opportunity to show your key stakeholders, which might be a wider audience than your DPO's, what the team has built during the sprint. It's the chance to illicit feedback from stakeholders to know if it meets the requirements or if any tweaks are to be done in a future sprint. The feedback is gathered by the BA and future enhancements are added to the backlog to be discussed and prioritised by the DPO's in a subsequent meeting. 

And so the cycle continues. 

If you are in a position where requests seem to be coming from all corners of the business then you may want to consider these points mentioned and suggest some process to your stakeholders. It can help everyone define what's really important through visibility of all requests and their prioritisation. By putting the ownership of this task on the business then it helps to avoid the Delivery team seen as the blockers and bad guys, instead allowing them the space and mindset to deliver great functionality and enhancements the business really needs.