Change Request Optimization with ScrumKarthik Venkataraman
schedule 5 months agoSold Out!
Change requests are mid sized configuration and code changes to the Salesforce.com (CRM applications) which are desired by the Business user community. The expectation from user community is every change request of their's is a value to the organization and hence needs to be deployed during the Bi-weekly release cycle. This now is a open challenge to the Product owner and IT team.
Each release is constrained by Level of Effort and funds available to deploy some of these change requests during the Bi-weekly release cycle. All that was being followed was influence and arm twist Product owner to get a particular CR in the release and get the IT team to develop and deploy it.
Is this how a business process should go? What can we do to improvise?
This was an interesting challenge as we started reviewing the overall change request deployment process from a business and systems perspective. The glaring shortcomings indicated we need create a mini project which first needs to have a plan and team working to focus on process optimization. A project charter was drawn out with special focus laid on AS - IS process to see if we are able to track an ROI for each Change request getting deployed.
ROI was classified as 2 areas of improvements.
- Ease the Business process
- Ease the system functionalities process
The plan was laid out with a Goal statement driven with a well laid out timeline to yield result oriented outcomes. As we started with the AS - IS process we followed the SIPOC process to analysis the entire people and process points and realized the absence of a phase gates which can guide a deployment process and instead we had a Command and Follow methodology which was the major stumbling block. To overcome this we started interviewing the people points in the process. Majority of interviews was with the Product owners who suggested if we could phase gate the Bi-weekly release cycle with a well oiled end to end Framework applicable across all business units and scalable with growth. Business owners felt there are guided by 4 level of capability which measure their success and any enhancements for Level 1 and Level 2 impacting business or system process needs to be addressed with a highest severity
Considering the above interview outcomes, the project team started looking into - Types of request received, business areas sending in the request, funding cycle and resource planning. Analyzing the same, we started looking at a phase gate driven framework. The requirement for the framework is it should tell the business and development team where are in the current cycle, what is the next steps everything built with a timelines.
This is where we started using the scrum way.The product owner's were assigned to put the business request into a Product backlog and start prioritizing. Product owners devised their own prioritization processes with the stakeholders. Considering the business dynamics, 2 Developments team were created out based on business units with 2 different scrum masters. The scrum masters started Product backlog grooming with development team and Product owners for 2 weeks so that a good amount of understanding on the requirements was obtained. Post this 2 week grooming, a read out was provided to the business user community around the backlog and the team readiness now to start delivering fixes during the bi-weekly release in a refined cycle based on prioritization, ROI and capability enhancements.
The read out results were not satisfactory withe business user community asking safety net against failures and faster resolutions. The project team got back and worked on the type of request coming in, instead of taking everything to development team, we started segregation with assistance from Product owners as configuration or code fix. Configuration fixes were routed to Level 1 support team who could do the changes on the fly and in case their analysis fails only then they would re-route the change request to product backlog. Code fixes would reach the Development team only. This revised plan was read out to the business user community however the process was still not accepted as the safety net process was missing and no traces on reporting or traction was presented. We then decided to share the complete framework in presentation to the team and double clicked on the fact after - Assignment :> Prioritization > Requirement Gathering > Level of Effort > Scope confirmation > Development we would be having QA > UAT > Go Live. This sort of satisfied the user community to give us a go ahead to execute a few sprint. A reporting dashboard was prepared to let business user community track the sprint progress on time and place of their choice.
The two week sprint was distributed as below:
- Requirement Gathering > Level of Effort > Scope confirmation - 3 Days
- Development - 2 Days
- QA and UAT - 3 Days
- RFC approvals and Go Live with Retro - 2 Day
Current team velocity is around 8-10 change request for every Bi-weekly release.Releases are suspended during the Quarter end freeze.
The value proposition gained by following the framework within our organisation is:
- Visibility on the backlog items and the time boxed phase approach from assignment to go live.
- Advance alerts on the capability improvement which Business can achieve when the CR's are deployed.
- Ex: Since we have a well laid out framework for CR deployment, this can provide an improvised view for the Senior Management on how the capability level improvements can be seen post the release and commit for metrics like - CSAT/Operational or Business improvement efficiency
- Collaboration was an element which was missing in the system as no one was aware of the progress being made in the change request deployment as no one had any status updates to track and follow. The framework now has emphasized the Product owner to track and report the success to the Stakeholders at the right time and with right levels of focus and information.
Helping Leaders See the Pain of Too Much ChangeEric Rapin
schedule 5 months agoSold Out!
Do teams feel as though leaders move the goalposts every day? Do leaders understand how much pain change causes? How to make that visible?
While we embrace change in agile, there's a useful rhythm and cadence to change that helps people absorb the change and improve. Change too often and it can create resistance to the change.
What if leaders understood the disruption that too many changes in process and goals can cause? What if there was a game we could play that would help us see this more clearly?
We'll play a game (Fluxx) in groups to illustrate the impact that changing goals and changing rules has on people. How this can cause decision paralysis, frustration, and ultimately lead to complete disengagement.
We will also discover how moving people from team to team can impact teams and individuals.