Change Request Optimization with ScrumKarthik Venkataraman
schedule 4 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.
Lean Enterprise: Maersk Line's journeyÖzlem Yüce
schedule 5 months agoSold Out!
- Does your organisation treat I.T. like a factory, taking orders from “the business”?
- Does your funding and approval process force you to work in large batches with commitment to fixed time, budget and scope?
- Do your KPIs lead people to optimise for their role or department?
- Do your legacy applications limit how fast your organisation can innovate?
- Is your fuzzy front end full of queues, analysis paralysis and fighting for approval?
If you want to hear about how Maersk Line, the world’s largest container shipping company wrestled with and changed each of these, this session is for you!
Our journey starts with a revolutionary approach: A $60m mega-project to deliver a new customer facing website. Set up as a “startup” within the company, we attempted to implement and scale Scrum. You’ll learn what worked, what didn’t and what we learned along the way – and how it was ultimately seen as a huge failure in the eyes of senior management.
We then pivoted to take a more evolutionary approach. This time by tailoring and adapting a set of Lean-Agile practices that would fit our context and culture – and mostly focused on increasing end-to-end speed. We studied the whole system and selected 8 Lean-Agile practices that could scale up to the enterprise level and across the whole portfolio:
The challenges of driving change in a Fortune 500 behemoth
How focusing on changing the whole end-to-end value-stream helped to reduce cycle time (and how that also hindered us).
How important changing the funding model was
How to argue for changing KPIs that damage the whole
How to “Do Agile” and make massive improvements in cycletime *without* any changes in downstream practices like automated testing and continuous delivery.
How we changed the common perception that Agile is for Greenfields only.
Scaling organizational changeAngel Diaz-Maroto Alvarez
schedule 4 months agoSold Out!
In this session I’m showing a model that organizations can use to foster the adoption of agile. This model is "locally" based on lean change, understandig Agile initiatives from different countries as startups. It scales by using the validated learning cycles of every organization to create a validated learning knowledge base. The knowledge base is grows with the performed experiments of agile practices in different business units. This "validated learning knowledge base" is co-created by the members of the internal international Agile community and shared through A3 report sheets.
The the model can be de composed as follows:
- Lean Start up principles as foundations for a change strategy,
- A3 thinking and problem solving as a support for lean continuous improvement,
- Agile Journey mapping as a strategy designing tool
- A Validated Learning Knowledge Base as a support for effective sharing,
this is a complete and easy to use framework that can help communities, multisite organizations and groups of Agile leaders to boost Agile adoption in their business units.
This model has being experimented in the Dutch multinational organisation ING.
Agile at Scale For Innovation and GrowthKamlesh Ravlani
schedule 5 months agoSold Out!
Bringing innovative and breakthrough ideas to market doesn't have to slow down due to multiple geographies and scale of product development. In fact that's an added reason to be agile, test the product-market-fit early and reduce risk.
How can organizations benefit from being Agile at Scale For Innovation and Growth?
What are the wastes in the traditional organizational structure at scale? and What does it take to build customer value delivering feature teams?
We'll dissect a case-study, Kamlesh Ravlani - the presenter, was involved with and learn how Google brought one of their innovative idea rapidly to market that involved multiple partners and teams in multiple geographies.