Scrum in different Contexts

Last post 06:13 am May 24, 2020
by Ian Mitchell
3 replies
Author
Messages
10:09 am May 22, 2020

Hello,

just passed the PSMI exam. I do like the whole framework and especially the core values behind them.

 

Howerver, I am curious how Scrum is applied in different contexts. For example a lot of OEMs in the automotive world make

their contractors follow certain PM Methods as Prince2. 

 

Consider a software vendor that aims for "Scrum by heart", "buttom up responsibilty and top down support". How does such a company

incorperate methods that involve different roles such as a Product Manger, if their customer demands it?

08:49 am May 23, 2020

The most simple answer is to follow the Scrum Guide and its underlying principles, and treat any outside dependencies in roles and people as stakeholders (and Scrum Users), to be addressed by the PO of the company

12:52 am May 24, 2020

I don't think Scrum is saying there is no such thing as a "Product Manager" though the PM does not manage the team.

If you study for the Professional Agile Leadership certification (PAL), you will see many references to managers outside the scrum team though Scrum does not define their role. 

I like Prince2 Agile's philosophy that the interface between Managers and the Scrum team is dictated by the maturity of agile in the organisation. In a mature agile environment the 'manager' will pull information from kanban boards and use this to report to the CEO, and will pass on important information about market conditions and competitor's activities to the product owner. The scrum team is left to self-organise.

There is an analogous point made by the book Agile Leadership Toolkit. My view is that while there is tension between Prince2 Agile and 'pure' Scrum, they are compatible. 

 

06:13 am May 24, 2020

Consider a software vendor that aims for "Scrum by heart", "buttom up responsibilty and top down support". How does such a company

incorperate methods that involve different roles such as a Product Manger, if their customer demands it?

The pressure is always on to change Scrum rather than the organization, so the framework becomes more relevant to "context". The result is usually little change where it really matters...an unchanged organization, and disappointment that value delivery has not improved. 

The best way to respond to such demands is to explain the Scrum framework, and to put as much transparency as possible over the consequences of trying to change it. The emphasis, instead, should be on finding the best way to respect and to implement its roles, events, artifacts and rules.