Process improvement success stories

Problem we solved - The team that was handed to me was split geographically (US and India). The team was new to agile and we had to figure out the way of working. We didn't have experience too with building automated test cases. Besides, my business owner too was new to APIs. She had a lot of domain knowledge but wasn't familiar at all with APIs.

How we did it -
1) With all these problems, we knew that the 1st few sprints would practically be training ones. We did agile training and spent time getting to know each other. With geographical constraints, we did video and there were trade offs too - Some days we would do late calls and other days the offshore folks would stay late.
2) Our PO was great at the domain and so we had her share some of her knowledge.
3) We then got down to coming up with our backlog. It wasn't pretty but we had set expectations accordingly. The rest of the team also helped the PO with the same.
4) As SM, I also helped the team with understanding the concept of spikes and story maps, which helped the team understand the backlog despite geographical distances.
5) In terms of automated tests, we had some exploratory spikes to understand different tools like protractor for writing business tests. It was important to spend time on these to really have impact.
6) Retrospectives were good because the team came up with improvements and got better over time. This team became one of the highest performing teams in the company.

Key to process improvement is that the organization should embrace the "test-and-learn" strategy. Some solutions for different problems may or may not work, especially in a net new area. The roadmap should account for time needed to learn because if we just patch the old solution i.e. could be app or process, we will never get to the new. The senior management should empower the teams for real process improvement to happen! Hope this helps!

Problem we solved - The team that was handed to me was split geographically (US and India). The team was new to agile and we had to figure out the way of working. We didn't have experience too with building automated test cases. Besides, my business owner too was new to APIs. She had a lot of domain knowledge but wasn't familiar at all with APIs.

How we did it -
1) With all these problems, we knew that the 1st few sprints would practically be training ones. We did agile training and spent time getting to know each other. With geographical constraints, we did video and there were trade offs too - Some days we would do late calls and other days the offshore folks would stay late.
2) Our PO was great at the domain and so we had her share some of her knowledge.
3) We then got down to coming up with our backlog. It wasn't pretty but we had set expectations accordingly. The rest of the team also helped the PO with the same.
4) As SM, I also helped the team with understanding the concept of spikes and story maps, which helped the team understand the backlog despite geographical distances.
5) In terms of automated tests, we had some exploratory spikes to understand different tools like protractor for writing business tests. It was important to spend time on these to really have impact.
6) Retrospectives were good because the team came up with improvements and got better over time. This team became one of the highest performing teams in the company.

Key to process improvement is that the organization should embrace the "test-and-learn" strategy. Some solutions for different problems may or may not work, especially in a net new area. The roadmap should account for time needed to learn because if we just patch the old solution i.e. could be app or process, we will never get to the new. The senior management should empower the teams for real process improvement to happen! Hope this helps!

I would focus on stakeholders requirements management. Here, I would start bringing together all people with particular knowledge about the business process, not only senior managers or the business owners, but also main users, IT people, finance, operations, etc. The objective of these sessions would be to diagram or document the business process and then collect ideas for process improvement, automatization, bringing new potential technologies mapped to the process area.
It is very important to bring a representative of each stakeholders group, this in order to cover all experiences and perspective into the business process.
Re the skillset of the team, more than a skillset is an attitude to hear from others and respect their opinions. Believe me a lot of good inputs are lost, because lack of interventions/participation.
Re PM methodology, to me I see this as a business analysis topic where you need to manage stakeholders, collect their requirements, manage expectations, and the most important to me: manage to get decisions, so everybody is happy!

I would focus on stakeholders requirements management. Here, I would start bringing together all people with particular knowledge about the business process, not only senior managers or the business owners, but also main users, IT people, finance, operations, etc. The objective of these sessions would be to diagram or document the business process and then collect ideas for process improvement, automatization, bringing new potential technologies mapped to the process area.
It is very important to bring a representative of each stakeholders group, this in order to cover all experiences and perspective into the business process.
Re the skillset of the team, more than a skillset is an attitude to hear from others and respect their opinions. Believe me a lot of good inputs are lost, because lack of interventions/participation.
Re PM methodology, to me I see this as a business analysis topic where you need to manage stakeholders, collect their requirements, manage expectations, and the most important to me: manage to get decisions, so everybody is happy!