Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile
Agile Delivery Challanges
Hi All,

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?

Regards,
Mohit
Sort By:
Page: 1 2 next>
Mohit -

I'd suggest you read the multiple good blog articles written by Scott Ambler in the Disciplined Agile Applied blog (https://www.projectmanagement.com/blogs/57...-Agile-Applied) on this site.

While a project manager is still needed on mid-large sized projects following an adaptive life cycle, goals such as estimating how long work will take or how much it will cost can still be accomplished but in a different method than on a project following a predictive life cycle.

The key is to look at the planning horizon. Whereas traditional approaches might end up planning beyond the safe visible distance of the horizon, agile approaches focus on where there is greatest confidence when it comes time to forecast.

Agile is NOT an excuse for scope creep. The guardrails for an agile delivery initiative will include the overall project/product vision, specific high-level capabilities or themes which the project/product needs to deliver, and techniques such as story mapping can help to ensure traceability from high-level needs to low-level work items.

Kiron
Hi Mohit,

Agile and Scrum are not the same thing. Scrum is one framework that encourages teams to take an agile approach and your question seems to be about Scrum rather than agile.

In Scrum the Product Owner is accountable for scope and cost and should take all those decisions. Estimation is the collective responsibility of the team actually doing the delivery, meaning the whole development team. Many/most Scrum teams use Relative Estimation (points based) and collaborative techniques ("planning poker" is one method) to sense-check estimates. Agile teams tend to be trusted to take ownership and resolve conflicts internally but the Scrum Master is someone who should facilitate that, help develop individuals and deal with any blockers that the team can't handle effectively.
My friend, you are mixing lot of things. But it is not your fault. It is because lot of people are adding confusion to the market. First of all, Agile is not Scrum. For example, I used DSDM (one of the four always named into agile based books) from long time and you will find the project manager role inside it. With that said, my recommendation is now that DA is taking impulse thanks to PMI adquisicion take a close look to it. In fact, Scott Ambler has published a book free of cost for PMI members. Take into account: I am using DA and related work from the very begining it was created each time I have the opportunity to apply it. Second, related to estimation and this stuff my recommendation is take a closer look to Mike Cohn site and mainly to Mike Cohn´s book "Agile estimation and planning". A must read.
You will find, Mohit, than many agile approaches expect the product owner/manager to fill out project management areas like release planning and cost management. My experience is that product owners don't have the skills or gravitas to do project cost management. At the end of the day, all the project management functions will have to be covered by the project team or their supporting organization (for example, a PMO.)
Thank you all for your views & suggestions. For some reason, the interface had a glitch for me & I couldn't see the responses in this thread. Seem to work now.

Yes, I will continue read more on this topic and I am sure things will start to make more sense. I was informed of a project where the client wanted to try scrum & picked up just the "scope remains flexible" part to keep asking changes. Even the team (who worked previously with waterfall approach) remained same (with limited knowledge & experience in scrum). It didn't work well, for both the service provider & the customer :)

I think as a starter it is very important that everyone (including the customer) involved in a project understand "why" and "when" to use agile (and not just try it because it may be picking pace in the industry).

Thank you again for your inputs.
...
3 replies by Kiron Bondale, Sergio Luis Conte, and Stéphane Parent
May 15, 2020 2:42 PM
Kiron Bondale
...
There's a good reason why the authors of Scrum said it is easy to understand but hard to implement...
May 15, 2020 3:11 PM
Stéphane Parent
...
The biggest challenge for customers is to understand that they can ask for changes but that it will push something down in the backlog. That means some of the backlog will fall off the project's scope.
May 15, 2020 5:57 PM
Sergio Luis Conte
...
If you will use Scrum the only and only source you have to read is the Scrum Guide (https://www.scrumguides.org/). With that said, what some people forgot and because of that fail is: Scrum is a framework. It does mean everybody that have to use it must fill it up with the process and techniques that best fits for your situation. That´s what makes Scrum "dificult". Just in case you decide to use what most of the people use without making an impact analysis first then you can read what I stated above mainly Mike Cohn´s site.
May 15, 2020 10:15 AM
Replying to Mohit Joshi
...
Thank you all for your views & suggestions. For some reason, the interface had a glitch for me & I couldn't see the responses in this thread. Seem to work now.

Yes, I will continue read more on this topic and I am sure things will start to make more sense. I was informed of a project where the client wanted to try scrum & picked up just the "scope remains flexible" part to keep asking changes. Even the team (who worked previously with waterfall approach) remained same (with limited knowledge & experience in scrum). It didn't work well, for both the service provider & the customer :)

I think as a starter it is very important that everyone (including the customer) involved in a project understand "why" and "when" to use agile (and not just try it because it may be picking pace in the industry).

Thank you again for your inputs.
There's a good reason why the authors of Scrum said it is easy to understand but hard to implement...
May 15, 2020 10:15 AM
Replying to Mohit Joshi
...
Thank you all for your views & suggestions. For some reason, the interface had a glitch for me & I couldn't see the responses in this thread. Seem to work now.

Yes, I will continue read more on this topic and I am sure things will start to make more sense. I was informed of a project where the client wanted to try scrum & picked up just the "scope remains flexible" part to keep asking changes. Even the team (who worked previously with waterfall approach) remained same (with limited knowledge & experience in scrum). It didn't work well, for both the service provider & the customer :)

I think as a starter it is very important that everyone (including the customer) involved in a project understand "why" and "when" to use agile (and not just try it because it may be picking pace in the industry).

Thank you again for your inputs.
The biggest challenge for customers is to understand that they can ask for changes but that it will push something down in the backlog. That means some of the backlog will fall off the project's scope.
...
1 reply by David Portas
May 16, 2020 1:28 AM
David Portas
...
Hi Stéphane,

I would put it differently. The backlog is the forecast scope of work at any point in time. Depending on the contractual relationship it's possible that different commercial terms may be relevant when scope and priorities change but that doesn't automatically mean anything falls out of scope - it obviously depends on how your contract works. One of the potential advantages of an agile approach for both customer and service provider is that cost (and risk) can more easily be kept aligned with business and commercial priorities.
May 15, 2020 10:15 AM
Replying to Mohit Joshi
...
Thank you all for your views & suggestions. For some reason, the interface had a glitch for me & I couldn't see the responses in this thread. Seem to work now.

Yes, I will continue read more on this topic and I am sure things will start to make more sense. I was informed of a project where the client wanted to try scrum & picked up just the "scope remains flexible" part to keep asking changes. Even the team (who worked previously with waterfall approach) remained same (with limited knowledge & experience in scrum). It didn't work well, for both the service provider & the customer :)

I think as a starter it is very important that everyone (including the customer) involved in a project understand "why" and "when" to use agile (and not just try it because it may be picking pace in the industry).

Thank you again for your inputs.
If you will use Scrum the only and only source you have to read is the Scrum Guide (https://www.scrumguides.org/). With that said, what some people forgot and because of that fail is: Scrum is a framework. It does mean everybody that have to use it must fill it up with the process and techniques that best fits for your situation. That´s what makes Scrum "dificult". Just in case you decide to use what most of the people use without making an impact analysis first then you can read what I stated above mainly Mike Cohn´s site.
May 15, 2020 3:11 PM
Replying to Stéphane Parent
...
The biggest challenge for customers is to understand that they can ask for changes but that it will push something down in the backlog. That means some of the backlog will fall off the project's scope.
Hi Stéphane,

I would put it differently. The backlog is the forecast scope of work at any point in time. Depending on the contractual relationship it's possible that different commercial terms may be relevant when scope and priorities change but that doesn't automatically mean anything falls out of scope - it obviously depends on how your contract works. One of the potential advantages of an agile approach for both customer and service provider is that cost (and risk) can more easily be kept aligned with business and commercial priorities.
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.
...
1 reply by Stéphane Parent
May 16, 2020 11:18 PM
Stéphane Parent
...
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.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

A conference is a gathering of important people who singly can do nothing, but together can decide that nothing can be done.

- Fred Allen

ADVERTISEMENT

Sponsors