I've started exploring the agile world & the associated certifications (psm1 & csm are a good starter). Having read a few blogs, guides and other related artifacts, my mind is stuck on one question:
How are the estimation, scope, costs and procurement managed in Agile projects if there is no full time project manager? Scrum Master is not same responsibilities as a project manager. I read that most of the agile projects are driven by self-organizing generalists (the development team) while the Scrum Master/Agile Coach work to keep the team within the guidelines of agile framework (educating the team on agile processes, roles, ensuring the time-boxed events are concluded within the set time frame etc.). So who is managing the project/sprint delivery as a whole - check if scope is followed, are the estimates right or inflated, conflicts within the team, procurement? Relying just on the teams on estimation (schedule + cost) can lead to padding (resource might just provide best guess on how much time a task might take - making it relative to who is performing the task). Same goes for scope creep if there is no project manager to keep a track of what's in & what's not in scope (I know product backlog is the main artifact used for it but in real world, it can be a challenge to avoid influences on scope, especially when the product owner is from the customer's side).
It is interesting concept and I am sure as I continue to read I will learn more.
Any real world experience, challenges or thoughts on this?
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
I should have been clearer, David. I was referring to the product backlog which lives before, during, and after the project. Given that we constrain the costs and the time by using iterations, the only thing that can give is the scope, in this case, the product backlog.
Assuming that new backlog items have value enough to be part of the project, which has a fixed end date, that means some lower value items will have to be pushed beyond the last iteration. Of course, the customer may elect to pay for additional iterations. The question for the customer becomes: is it cost-effective to purchase lower valued backlog items? Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
May 16, 2020 10:44 PM
Replying to Adrian Carlogea
...
My experience with software development projects that use Scrum is that the Project Managers coexist with Scrum Masters and Production Owners. I guess someone may have two or more roles for instance the role of the Scrum Master can be played a developer or tester by or the PM.
If you are doing an activity that is not a project (such as product development) then you would not need a project manager no matter if you are using Scrum or not.
It is kind of odd since Scrum is supposed to use self-organized teams but in reality more management is needed for it to work.
You need someone to manage the project, someone to manage scope and someone to manage the Scrum process. In addition each function from the team would need leads such as development lead, test lead, architect lead, etc. A lot of administration overhead and bureaucracy. :) That's Scrum for you, I don't know about Agile in general.
I think the reality, Adrian, is that agile requires the delivery organization to have a certain infrastructure maturity. Agile teams need to be enabled through an underlying organizational layer of admin staff, managers, and facilitators. In a sense, it's "underhead", rather than overhead.
...
1 reply by Adrian Carlogea
May 17, 2020 8:32 PM
Adrian Carlogea
...
Hi Stephane.
I don't disagree with you, I am not an expert in Agile so you may be right. Still from my experience as well as from different opinions I have read so far, it appears that Agile is something hard to get right.
Also the common sense tells me that self-organized teams should require less managers no matter if they are at the organization or the project (activity) level. I have seen the opposite of this.
In waterfall projects you have a PM as the activity manager and one or more functional managers at the organizational level managing the project team members. If you use Scrum as the Agile "method" then in addition to the PM and the functional managers you also need a Scrum Master and a Product Owner. The SM and the PO are more or less considered part of the activity management even if at the organizational level the holders of these roles may not be real managers (PMs also at the organizational level are usually not real managers).
Stéphane is right that agility is very much a feature of team and organization maturity. Practices tend to vary widely. Many scrum teams do not need additional management for "project" and "process" because the whole team takes collective responsibility for delivery and where the team is experienced enough they can deliver without that kind of supervision. There are other teams that need more guidance or perhaps are subject to additional controls just because that is the way their organization works. Saving Changes...
Ganesh KumarProgram ManagerBangalore., Karnataka, India
Hi Mohit, What we did and found some success and continue to refine our internal practice, is that cost, budgeting, procurement, risk are done outside the sprint as it’s done traditionally. Especially estimation and scope are within the sprint. Scope from what was baselined initially and what has been refined to finally till its delivered – is considered as CR. All throughout the customer is in the loop and is done within the sprint. Estimation has been a challenge and sometimes way off the target. One reason is not everyone in the team is able to estimate, followed by scope changes that happen abruptly.
It’s a hybrid model and serves several of our purposes. There is a Product manager from the customer side who manages the product and coordinates with the project manager.
I think the reality, Adrian, is that agile requires the delivery organization to have a certain infrastructure maturity. Agile teams need to be enabled through an underlying organizational layer of admin staff, managers, and facilitators. In a sense, it's "underhead", rather than overhead.
Hi Stephane.
I don't disagree with you, I am not an expert in Agile so you may be right. Still from my experience as well as from different opinions I have read so far, it appears that Agile is something hard to get right.
Also the common sense tells me that self-organized teams should require less managers no matter if they are at the organization or the project (activity) level. I have seen the opposite of this.
In waterfall projects you have a PM as the activity manager and one or more functional managers at the organizational level managing the project team members. If you use Scrum as the Agile "method" then in addition to the PM and the functional managers you also need a Scrum Master and a Product Owner. The SM and the PO are more or less considered part of the activity management even if at the organizational level the holders of these roles may not be real managers (PMs also at the organizational level are usually not real managers).
...
1 reply by Stéphane Parent
May 18, 2020 3:56 PM
Stéphane Parent
...
There's no doubt, Adrian, that agile is difficult to do right. Try to keep teams going for three years! All of a sudden you have to deal with attrition, stress and management oversight. These are not covered in the Agile Manifesto!
Let me explain why I think self-organized teams need foundational support. Suppose I am working from home and I am heating the house using a wood stove. (This actually was the situation for me fifteen years ago.) I know that during the winter I have to stoke the stove every 60 to 90 minutes. If nobody else is around, I will have to do it. It will break my concentration and focus. I will have a very short time, between stove refills, where I am truly effective.
It the same principle with high-performance teams. For the team to be highly performing, you need the support - people, tools, processes - in place to allow them to not worry about the administrivia.
"Development teams are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality".
It would be interesting to know if in reality this works. Does it mean the projects using scrum framework always have highly skilled & experienced resources (work without supervision)?
If the framework expects this as a best practice, then I wonder why would we need a project manager? The scrum master can manage the process & compliance with time-boxed events, the development team can select the sprint backlog & plan to convert into an increment while the product owner can prioritize the product backlog (help the team understand the sprint goal). Saving Changes...
Inevitably most teams have a mix of skills and experience and less experienced members of the team will be supported by more experienced ones.
Some organizations using Scrum do maintain a nominal "PM" role but if you stick with the Scrum approach then a PM does not lead the team and it is the PO, not the PM, who makes the decisions on scope and priorities. In contrast to PMs, the PO is usually a business manager/director not full-time in the PO role but a manager of a business unit, product or service who represents the user or customer of the output of the scrum team. There has been a trend in recent years to designate a PO as a full-time role but unless a PO needs support then there is no definite role for a PM when using scrum.
In the case of technology projects, regardless of the delivery approach, PMs seldom perform a technical leadership role. Often no one person has the expertise to make all the technical decisions. So the Scrum guide is just acknowledging the reality of the way that many teams tend to work.
...
1 reply by Adrian Carlogea
May 19, 2020 7:23 PM
Adrian Carlogea
...
Hi David,
If you are delivering a fixed-price software development project to an external customer and you want to make money out of it then having a very good PM is vital.
The team does not need the PM for its actual work but in fixed-price projects it is vital to have a very well-defined scope, even if you are using Scrum/Agile. If you don't then the customer can ask you to perform a lot of extra work without paying and you may not refuse if the scope is vary ambiguous.
Also during the execution if the customer needs extra work the PM must be there to ensure that Change Requests are raised and money are paid.
I have seen a team of highly skilled individuals successfully delivering a project but the project failed on the financial side because the PM was not good and was unable to charge the customer properly for all the work performed.
For internal projects indeed there is not much need of a PM although it can be helpful.
Only if you are doing pure product development with no fixed scope and no fixed budget you can get rid of the PM completely . :-) Pure product development however is kind of Business as Usual rather than project activity.
Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
May 17, 2020 8:32 PM
Replying to Adrian Carlogea
...
Hi Stephane.
I don't disagree with you, I am not an expert in Agile so you may be right. Still from my experience as well as from different opinions I have read so far, it appears that Agile is something hard to get right.
Also the common sense tells me that self-organized teams should require less managers no matter if they are at the organization or the project (activity) level. I have seen the opposite of this.
In waterfall projects you have a PM as the activity manager and one or more functional managers at the organizational level managing the project team members. If you use Scrum as the Agile "method" then in addition to the PM and the functional managers you also need a Scrum Master and a Product Owner. The SM and the PO are more or less considered part of the activity management even if at the organizational level the holders of these roles may not be real managers (PMs also at the organizational level are usually not real managers).
There's no doubt, Adrian, that agile is difficult to do right. Try to keep teams going for three years! All of a sudden you have to deal with attrition, stress and management oversight. These are not covered in the Agile Manifesto!
Let me explain why I think self-organized teams need foundational support. Suppose I am working from home and I am heating the house using a wood stove. (This actually was the situation for me fifteen years ago.) I know that during the winter I have to stoke the stove every 60 to 90 minutes. If nobody else is around, I will have to do it. It will break my concentration and focus. I will have a very short time, between stove refills, where I am truly effective.
It the same principle with high-performance teams. For the team to be highly performing, you need the support - people, tools, processes - in place to allow them to not worry about the administrivia. Saving Changes...
Inevitably most teams have a mix of skills and experience and less experienced members of the team will be supported by more experienced ones.
Some organizations using Scrum do maintain a nominal "PM" role but if you stick with the Scrum approach then a PM does not lead the team and it is the PO, not the PM, who makes the decisions on scope and priorities. In contrast to PMs, the PO is usually a business manager/director not full-time in the PO role but a manager of a business unit, product or service who represents the user or customer of the output of the scrum team. There has been a trend in recent years to designate a PO as a full-time role but unless a PO needs support then there is no definite role for a PM when using scrum.
In the case of technology projects, regardless of the delivery approach, PMs seldom perform a technical leadership role. Often no one person has the expertise to make all the technical decisions. So the Scrum guide is just acknowledging the reality of the way that many teams tend to work.
Hi David,
If you are delivering a fixed-price software development project to an external customer and you want to make money out of it then having a very good PM is vital.
The team does not need the PM for its actual work but in fixed-price projects it is vital to have a very well-defined scope, even if you are using Scrum/Agile. If you don't then the customer can ask you to perform a lot of extra work without paying and you may not refuse if the scope is vary ambiguous.
Also during the execution if the customer needs extra work the PM must be there to ensure that Change Requests are raised and money are paid.
I have seen a team of highly skilled individuals successfully delivering a project but the project failed on the financial side because the PM was not good and was unable to charge the customer properly for all the work performed.
For internal projects indeed there is not much need of a PM although it can be helpful.
Only if you are doing pure product development with no fixed scope and no fixed budget you can get rid of the PM completely . :-) Pure product development however is kind of Business as Usual rather than project activity. Saving Changes...
I have done successful fixed price projects without a PM. As you rightly suggest, "fixed price" for a software project does not mean the price and scope will not change - almost inevitably they do. Fixed price means that different contract terms apply to additional work outside some defined parameters, usually meaning the client agrees to pay extra for certain features. Scope is often defined in a product backlog form (perhaps with additional supporting documentation).
Sometimes it may be useful to have a "PM" to participate in negotiations with the customer about exactly which backlog items are additional costs and how much they pay for them but that is essentially a commercial account management role rather than a project role. Quite often that commercial role is played by an account manager who is not actually leading the project. Indeed, agile or not, one of the principal reasons why account management often is not done by a PM is that the commercial concerns may go way beyond the scope of a project. The negotiated costs can be highly dependent on the nature of the ongoing commercial relationship, the status of other projects and deals, etc. The customer ultimately decides what they are willing to pay for and in scrum the PO is the person made accountable for those decisions (though not necessarily the sole decision maker).
The question of product versus project is more interesting in my opinion. Evolving your technology ecosystem *is* (should be) a "business as usual" activity. If your software is not changing then probably it is not working as effectively as it should in a changing world. "Project" is a label we give to some iterations of a product, usually when we want to increase the rate of change. I would argue that we don't have to do anything fundamentally different to achieve that increase in tempo, we just have to have teams that are responsive to changing priorities. I think we all understand that the reason to call something a project often has as much to do with perception and promoting an idea as with the practice of delivery. Saving Changes...
