September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
In Scrum the Product Owner sets scope, priorities and is ultimately accountable for the project while the team as a whole are responsible for planning and delivery. This makes sense especially for technology projects and other complex pieces of work where it's often the case that no one person alone has sufficient expertise or capacity to plan and manage everything. More on Sprint Planning: https://www.scrum.org/resources/what-is-sprint-planning
In environments where Scrum is used you will often find former PMs taking the role of an agile coach, facilitator of agile adoption and troubleshooter to project teams. PMs often also have a role in programme/portfolio management where multiple Scrum teams are involved.
There is no project manager in Scrum. The project manager duties are splitted between Scrum defined roles, mainly Scrum Master. In my actual work place I was in charge to define "the way" to create solutions, it does mean all related to project process methods and life cycles for creating software and non software products.. We hve five different, some based on Agile approach, some based on Lean and some based in something different of both of them. One of this ways is by using Scrum. The same person is assigned to lead more than one initiative simultaneously where some of them use agile based approach, Scrum for example, and other use non agile based approach. No problem with that. It depends on that person understand exactly which the role is and it is trained on that. Is like a medical doctor that have specialized into a specific field of the medicine. And remember: Scrum is a framework each organization must fill it up with the tools and techniques best fits for the situation but not for the roles and ceremonies. If roles and ceremonies are changed then the organization is not using Scrum. Something "bad" with that? Not at all. Just to stay clear of the impacts.
What is critical to understand is Scrum is a PRODUCT management framework, not a project management one. Most organizations which try to implement Scrum for delivering projects (as opposed to products) quickly find they still need a PM...
This is interesting and a cause of confusion among most (at least for me). When you say Scrum is a product management framework and not a project management one, that is accurate. However, is it a right comparison? What I remember reading from PMBOK guide is - we have different development approaches viz. predictive and adaptive. Scrum falls under the later (is it?). So ideally, project management is a layer above that - whether you take predictive or adaptive development approach to deliver the product, wouldn't there still be the need to manage the project as a whole (where delivering the product might just be a subset - project management life-cycle includes all that is needed to manage the work from initiating to closure)?
The Scrum Master supports stakeholders by facilitating the work (which the PM also does), but, unlike the PM, he does not hold responsibility for the deliverable (the development team has) and for achieving the business objectives (which is the Product Owner)
The Project Manager is responsible for the entire project result.
With a gamble we could say that the responsibility of a Project Manager, in Scrum, is divided into the three roles of the Scrum Team: Product Owner, Scrum Master and Development Team.
I hope Kiron will reply but I think far too much is sometimes made about the apparent distinction between product and project. Maybe that just reflects the fact that I work with software and data tech where products tend to be king and projects often insignificant by comparison.
If you are properly managing product creation and evolution, if you are constantly keeping resources and costs aligned with business priorities then you don't necessarily need to do anything different just because you put up a sign that says project. If you aren't doing product management well enough then you have a problem you should fix, but project management doesn't have to be the answer. Better product management ought to be the answer.
Scrum does NOT allow for initiation & closeout activities which normally fall within any PM life cycle. That is why I make the distinction. Now, if you look at the Agile life cycle of DA, it includes those wrapped around a Scrum core.
Scrum also does not reference release or change management activities. All we create is a "potentially shippable product increment" at the end of each sprint but the deployment of that increment (or increments if you bundle many sprints worth) is not covered in the Scrum cycle.
Folks have tried to get around the lack of initiation activities by defining a "sprint zero" but in many companies it takes much longer than 1-4 weeks to mobilize a project in terms of forming a team, getting stakeholder alignment on vision, defining a backlog and all the other prerequisites needed for Scrum to kick in...
Scrum is used for things other than software development so it's understandable that it doesn't call out release and change management explicitly. However, change and release are very often part of the Definition of Done which typically can include a DevOps pipeline or other release activities.
Initiation and product vision are implicitly a PO rather than PM responsibility in Scrum and various approaches are taken. One way is to begin the backlog with "As a customer/stakeholder I want to understand the vision and roadmap for the product". That deliverable can be refined over a succession of short sprints that include other early deliverables. Of course you are right that the bigger picture evolves and is sometimes completely redefined over a long period of time. In a complex environment I would not expect to refine the vision only during project initiation, and after all that is what the iterative approach is all about.
In my experience Scrum works well as a way of delivering projects but the real question is this: if you are doing a good job of developing and managing products then do you really need a project at all? The view of Scrum's creators is that you can see each sprint as a project in its own right.
I can't speak for every CSM class taught, but my experience, and what I've heard from a few others who took a class from different providers, is that the CSM class is focused on teaching the fundamentals of how Scrum works at the individual team level. The instructor might mention Scrum of Scrums, but what is covered is not EVERYTHING you might want to know about Scrum. A two-day workshop is not long enough to provide the depth and breadth needed for that.
One example is the CSPO class. In the CSPO class, the instructor said that the Scrum Master is the coach for the whole team, including the PO. The PO role goes beyond what is covered in the CSM class. While you can coach someone without knowing all the details of their job, if you have a new PO who has not been trained (been there!!!) your job as a coach is a lot harder if you don't understand the PO role outside of backlog creation and sprint planning.
Then there is scaling Scrum. This takes you from team level Scrum to Organizational Level Scrum - multiple teams and more than software development is going on. Once you pass the team level, unless EVERYTHING can be run using Scrum, you get into a hybrid organization, where Scrum and other approaches, predictive or adaptive, can be practiced. Project Managers can still exist, you just might not need them at the individual team level.
I hope this helps. There's more to it, but like the CSM class, there is not enough room here to go in depth into everything.
Sergio L. Conte is correct, there is no PM in Scrum. But a Scrum Master does not take on all of the role of a PM, only a subset of them. Thus, IMHO, a Scrum Master is not as rich a position as a project manager. I have served as both and find SM more thrilling but PM more challenging. If you, as a PM, go Agile, consider moving to a SAFE role - Release Train Engineer, maybe?
Please login or join to reply