September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
While I'm sure some companies benefit from a vanilla approach using a single delivery methodology, we know that there is no such thing as a best practice, hence tailoring and picking the right tool (and role!) for the right context matters.
No one methodology has proven to be universally applicable, hence the origin of Scrumban and other hybrids as well as the development of process decision making frameworks like Disciplined Agile.
Peter, I agree with Kiron. There is no one strategy or methodology. It all depends on your organization and how you can adapt some practices to best meet the need.
PMI Agile Practice Guide is about Agile applied to software.Agile is not about software and you can read about that inside the PMBOK GUide. I was co-author of DSDM versions 1 and 2 where I worked with people likie Arie Van Bennekum that time after was one of the Manifesto authors. Scrum is a framework, not a method then you can fill it as you want. DSDM and Scrum have roles defined into it. The important thing is to understand about roles definitions, not about roles names. I am working on that (including I was requested by the PMI to talk about that) from 2010 up to date. It has no sense to perform a debate about roles. Is about to understand the roles definition and to work on that. Just an example. In my actual work place we have five diffferent life cycles defined to do software and non-software things. The same people is working at the same time in predictive based initiatives and adaptive based initiatives using Scrum and DSDM.
I agree with Sergio, role names are not important, only the totality of responsibilities these roles cover through effective role definition.
What I do like about Scrum another other "old" agile methodologies is that they do not distinguish between the individual "doers" contributing to the final solution. That helps to increase team-level ownership for work and encourages generalizing specialists.
However, they present a fairly rudimentary model which does not scale in enterprise contexts, hence the broadening of roles in most scaling agile frameworks.
The team approach to a solution is good, provided that the performance measurements also assess teams rather than or at least in addition to individuals.
Great responses above. Really about what is required than coloring within the 'defined lines'. The ability to mold and adapt as needed. Great point on role definition over role name.
What I understand is, Scrum is a means to an end and not an end in itself - does not provide a ready solution, but only defines a boundry or a framework to help tailor specific solution as needed
Agree with Sergio
Please login or join to reply