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.
Adopting Agility: The Journey towards Success in Product MaintenanceHiruna Dissanayake
schedule 5 months agoSold Out!
Being a product based ERP solution which is available in 60 different countries through its 79 different offices worldwide, IFS faced a major challenge with regard to providing agility among product maintenance teams within the organization.
A matured well defined product support process was already in place due to the fact that the application is used by 500,000+ users among 2000 customers worldwide using 20 different languages and it was clearly evident that there was a high risk related to making changes to this process. There were two major challenges identified in this set up.
- Neither a SCRUM nor a SCRUMBAN based approach was suitable due to the dynamic nature of work within “full-fledged” maintenance teams.
- Even if we came up with a uniquely different approach to find a better process, can we measure the success of this through metrics? If so how?
Agile Transformation kick start: Creating a Foundation for Success: case study in a real timeSathyanarayana H R
schedule 5 months agoSold Out!
This experience report presentation will discuss an approach deployed for successfully initiating an Agile Transformation. The organization has adapted Scaled agile framework as a means to achieve business results. This presentation focus on 6 elements of agile transformation kick start.
- Solution Design
- Preparation of agile release train launch in agile way – Preparation via executing one week sprints
- Training and Coaching teams – Preparing the teams
- Define and measure effectiveness
- Challenges and Learning and Benefits
- Team size: 80 people
- Location Bangalore, India.
- Domain: Healthcare
Coaching Distributed Agile Teams Through A Coaching Cohort
Collaboration, a cornerstone of agility, is inarguably a key success factor for self-organized productive teams. Despite being separated by thousands of miles, the need to collaborate successfully and to build team synergy is unchanged for agile transformation journey.
We are going to share some key highlights from our recent work for standing up agile coaching cohort and how it helped to coach highly distributed teams and scale agility at an enterprise level.
Agile beyond IT - Applying Kanban in HR functions for enterprise agilityPadma Satyamurthy
schedule 4 months agoSold Out!
Human Resources is an important function of an organization today. Like before, it's no more all about recruitment and people management but a complete paradigm shift on People Development. Today's organizations are more knowledge workers and hence they are no more looking out for jobs but are aspiring for long lasting and rewarding careers.
However, HR practices that are followed today are many a times still primitive and not updated to match with the aspirations of today's players. A shift in mind set and practices are very much the need of the day if an organization truly wants to develop its people and create a knowledge organization.
Kanban is an extremely effective way to bring in Resilience into the HR practices. This paper will walkthrough the case study of how HR has been implemented successfully in my client organization to keep up with both the speed and the development aspects of the organization.
We used most of the key Kanban principles while applying Kanban for the HR team. Here is an example for one of the HR teams – Talent Acquisition – on how Kanban was implemented: I will have multiple examples in the ppt.
- Visualize the workflow - we used this specifically in the talent acquisition teams to track the number of applications, applications selected, interviews lined up, offers rolled out and candidate joining. These were the columns we used in our Kanban board and each item was tracked and during the daily stand up, if any of the line item was in the same column for more than 3 working days. Each column was further split into – To Do, WIP and Completed (refer to the ppt for the visual of the board)
- Applying WIP Limits – We had a two –way limit to the WIP – one at the time level with a 3 working day limit for completing the pending work and second – not having more than 3 work items on the board
- Manage flow – since the requests for hire come from all over the organization, managing flow and identifying a point of contact for the business units was critical and helped manage the flow and predict the flow for the future as well
- Make process and policies explicit – since all of the business units are the customers, being transparent with them on making the hiring process explicit and bringing them into the Kanban fold was essential
- Feedback – As all the business units are the customers, taking a monthly feedback on the talent acquisition process and a retrospection on the feedback for continuous improvement was essential
- Improve and Evolve – Improving on the feedback as well as inspections within the team and evolving as an efficient lean team was not just a principle for us but it was our Goal!
The key problem we were trying to solve were:
1. Agility in IT only can only bring that much change and will continue to be constrained on human factors. Hence agility should go beyond software development and we started with HR to begin with.
2. Agile is a team and people focused philosophy. If these are ignored, the initial improvements we will see in IT will stagnate without able support from the HR function over a period of time. So to sustain the IT agility, it's essential we go beyond to bring in enterprise agility
The key measures that helped us to tell that we are in the right direction were:
1. Frequent feedback - from teams, managers, stakeholders on any new changes / processes we introduce (e.g.: managing recruitment pipeline for various business units - current # of days vs post Kanban implementation days etc)
2. Feedback from candidates on recruitment experience
3. Learning & Development progress - participation, applying the learning
4. Feedback on new performance / talent development process
All changes were introduced gradually and frequent inspect and adapt helped in streamlining the gaps. We looked not only at Kanban principles but also the 4 values and 12 principles of agile manifesto to see and measure our progress.
The Future is Decentralized, Distributed TeamsRajat Talwar
schedule 3 months agoSold Out!
The future is decentralized , distributed teams. Offices are a thing of past. Work from your home or a beach is the new thing.
In this case study I am going to talk about my experience working remotely and in distributed scattered teams . The talk will be focused around what are the new patterns I see while I worked across three companies - hike messenger, confengine & poolmyride . How the knowledge,tools, resources were shared across organizations . How some of these teams are totally remote and creating new products ,and are sustainable without external funding. How the culture of such orgs is enforcing everyone in it to be a leader and not just an employee of the company.
Some of these orgs are hybrid in nature serving both B2B markets and trying to innovate in B2C space.Will go deep into how it worked for me and my team.
I will also discuss what tools and strategies work best in such organizations .
Will also deep dive into the culture of such organizations and how it is totally different from the corporate culture we see in conventional companies.
I will also discuss few companies which have scaled enormously with this culture .
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.
How to be Maniacal about User Experienece with the help of Performance Test
Hike is an user-centric, mobile-first product, where user experience is the top priority. Hike started as an instant messaging app but during the course of the last four years, it has evolved into a messaging platform that offers a bouquet of features and services on top of messaging.
As a part of quality team, it becomes our primary goal to make sure that app is doing well in terms of performance for a 100+ million user base with an average smartphone cost of $120. We as a product want to achieve and solve lot of user problems but with a constraint of app running with limited device resources.
So the question arise, how do we achieve this goal?
Now, every night, every Sprint (2 weeks) and every public release (monthly), we run our automated perf tests. We measure our app's performance using several app specific use-cases on 4 key areas:
- Network (data consumption)
We also benchmark the following scenarios for app latency:
- App launch time upon Force Stop
- App launch time upon Force Kill
- App's busiest screen opening time
- Scrolling latency in different parts of the app
- Contact loading time in Compose screen
Embracing the fail-fast, fail-early principle, we now provide the necessary feedback to the developers as quickly as possible to avoid downstream delays.
Zinio way to removed project dependencies in a world wide environmentOscar Lopez Alegre
schedule 4 months agoSold Out!
Zinio is the largest magazine newsstand in the world. Currently we have multiple development teams distributed across three locations.
Growing we found out that communication across different teams working on a same platform was one of our biggest pain points and we decided to remove it.
During this session we will discuss what are the actions that Zinio did to increase communication on the engineering teams avoiding dependency locks and process overhead.
How we managed our dependencies in SAFesubhashree mishra
schedule 4 months agoSold Out!
This is a case study on How we managed our dependencies in SAFe.