Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, PMO
What are your follow-up questions about Agile for a PMO team?
Now that you've gained some basic information about Agile methods, but I know we didn't cover all your questions. What are some of the key issues or questions you have about Agile methods in the PMO world?
Sort By:
Network:4666
Few typical questions & answers I came across -

1. How well agile methods can be integrated?
2. Not all (stakeholder) familiar with this buzz word.
3. Traditional waterfall method is still widely accepted.
4. Resistance in accepting & learning agile methodologies.
5. What wonders it can do? Projects existed, and were successful much before agile?
...
1 reply by Jesse Fewell
Aug 18, 2016 10:51 AM
Jesse Fewell
...
Anupam, thanks for your post. Here is my take as some quick talking points...

1) How well you can implement agile methods is directly related to organizational change management. I strongly recommend looking into organizational change management techniques (e.g. ADKAR model). IMHO, this is a fundamental job skill for any PMO practitioner or "agile coach"
2) No, stakeholders will NOT know what agile is. It's OUR job as project leaders to have brief talking points at the ready, "Certainly Mr. Vice President I can tell you what agile is. It's a movement that is focused on (1) delivering business value earlier and more often, but doing that is hard so we (2) empower self-organizing teams to leverage our talent, but they're usually not ready so (3) start with what we have and use continuous improvement"
3) It's okay that waterfall is still accepted. There's a time-and-place for plan-driven projects. The point is to advocate for an empirical approach (iterative/incremental) to higher risk projects.
4) Resistance to change is a fundamental human behavior. See answer above to #1
5) Agile is not the goal; it is a means to an end. The key question for agile is WHY? If projects were completed to full satisfaction of stakeholders and employees all these years, then there is no need to change. The annual "state of agile" survey (google it) tells of key business benefits of going agile.
I know it is a myth that Agile means no documentation and status reporting, but I want to dig in to that more - specifically around project performance monitoring. How can you ensure that stakeholders are informed during product development projects when the product is being developed using Agile methodologies? We know we will keep getting the standard questions from leaders ("Is the product going to launch on time?!"), so how do we make sure we can answer them? How might Agile methodology impact and influence a standard project performance dashboard?
...
1 reply by Jesse Fewell
Aug 18, 2016 11:13 AM
Jesse Fewell
...
Hey Julia, there are 2 points here....

FIRST, regarding documents, the agilemanifesto.org says at the bottom "while there is value in the items on
the right (i.e. documentation), we value the items on the left more ("working product"). So the original statement of agile methods admits there IS value in documentation. The point is to shift SOME of the energy we pour into documents into actually building product. Any agile guys who says "we don't do documents anymore" did not read the document properly.

SECOND, regarding agile methods, the point is to accelerate and amplify business results, NOT to be compliant with a manifesto or methodology. So, it does matter when your business needs a performance dashboard to make strategic decisions ("this project has only 35% stakeholder satisfaction after 5 incremental deliveries!?!? Then we should kill this investment").

Here are some tips:
* Start first with the questions your leadership is asking (e.g. "when will projects be done?"..."what MVP will we have by this fixed date?")
* Then, see what data you already have available to help address those questions. Don't reinvent the wheel if you don't have to.
* Finally, if there are gaps between leaderships questions and our ability to answer then, try as much as possible to minimize the impact to delivery teams. One CIO wanted every employee to record their activities in a new timesheet system, so that he could find inefficiencies. When you did the math, he had a 100 person organization and a portfolio of authorized projects totaling 400 man years. The real problem was NOT efficiency reporting; the real problem was that his organization was over-committed by 4x

So...generate as many documents as necessary to empower leadership, but do so without impacting the empowerment or effectiveness of delivery teams as much as possible. That sweet spot is different for every organization.
Jul 23, 2016 10:20 PM
Replying to Anupam
...
Few typical questions & answers I came across -

1. How well agile methods can be integrated?
2. Not all (stakeholder) familiar with this buzz word.
3. Traditional waterfall method is still widely accepted.
4. Resistance in accepting & learning agile methodologies.
5. What wonders it can do? Projects existed, and were successful much before agile?
Anupam, thanks for your post. Here is my take as some quick talking points...

1) How well you can implement agile methods is directly related to organizational change management. I strongly recommend looking into organizational change management techniques (e.g. ADKAR model). IMHO, this is a fundamental job skill for any PMO practitioner or "agile coach"
2) No, stakeholders will NOT know what agile is. It's OUR job as project leaders to have brief talking points at the ready, "Certainly Mr. Vice President I can tell you what agile is. It's a movement that is focused on (1) delivering business value earlier and more often, but doing that is hard so we (2) empower self-organizing teams to leverage our talent, but they're usually not ready so (3) start with what we have and use continuous improvement"
3) It's okay that waterfall is still accepted. There's a time-and-place for plan-driven projects. The point is to advocate for an empirical approach (iterative/incremental) to higher risk projects.
4) Resistance to change is a fundamental human behavior. See answer above to #1
5) Agile is not the goal; it is a means to an end. The key question for agile is WHY? If projects were completed to full satisfaction of stakeholders and employees all these years, then there is no need to change. The annual "state of agile" survey (google it) tells of key business benefits of going agile.
Jul 27, 2016 4:26 PM
Replying to Julia Trabert
...
I know it is a myth that Agile means no documentation and status reporting, but I want to dig in to that more - specifically around project performance monitoring. How can you ensure that stakeholders are informed during product development projects when the product is being developed using Agile methodologies? We know we will keep getting the standard questions from leaders ("Is the product going to launch on time?!"), so how do we make sure we can answer them? How might Agile methodology impact and influence a standard project performance dashboard?
Hey Julia, there are 2 points here....

FIRST, regarding documents, the agilemanifesto.org says at the bottom "while there is value in the items on
the right (i.e. documentation), we value the items on the left more ("working product"). So the original statement of agile methods admits there IS value in documentation. The point is to shift SOME of the energy we pour into documents into actually building product. Any agile guys who says "we don't do documents anymore" did not read the document properly.

SECOND, regarding agile methods, the point is to accelerate and amplify business results, NOT to be compliant with a manifesto or methodology. So, it does matter when your business needs a performance dashboard to make strategic decisions ("this project has only 35% stakeholder satisfaction after 5 incremental deliveries!?!? Then we should kill this investment").

Here are some tips:
* Start first with the questions your leadership is asking (e.g. "when will projects be done?"..."what MVP will we have by this fixed date?")
* Then, see what data you already have available to help address those questions. Don't reinvent the wheel if you don't have to.
* Finally, if there are gaps between leaderships questions and our ability to answer then, try as much as possible to minimize the impact to delivery teams. One CIO wanted every employee to record their activities in a new timesheet system, so that he could find inefficiencies. When you did the math, he had a 100 person organization and a portfolio of authorized projects totaling 400 man years. The real problem was NOT efficiency reporting; the real problem was that his organization was over-committed by 4x

So...generate as many documents as necessary to empower leadership, but do so without impacting the empowerment or effectiveness of delivery teams as much as possible. That sweet spot is different for every organization.
...
1 reply by Julia Trabert
Aug 19, 2016 11:32 AM
Julia Trabert
...
Thanks for your input Jesse! This is very helpful. I think focusing on balancing the needs of our leadership and our delivery teams is a really reasonable approach. Everyone can get on board with documenting only when its critical so we can accelerate delivery and improve results!
Aug 18, 2016 11:13 AM
Replying to Jesse Fewell
...
Hey Julia, there are 2 points here....

FIRST, regarding documents, the agilemanifesto.org says at the bottom "while there is value in the items on
the right (i.e. documentation), we value the items on the left more ("working product"). So the original statement of agile methods admits there IS value in documentation. The point is to shift SOME of the energy we pour into documents into actually building product. Any agile guys who says "we don't do documents anymore" did not read the document properly.

SECOND, regarding agile methods, the point is to accelerate and amplify business results, NOT to be compliant with a manifesto or methodology. So, it does matter when your business needs a performance dashboard to make strategic decisions ("this project has only 35% stakeholder satisfaction after 5 incremental deliveries!?!? Then we should kill this investment").

Here are some tips:
* Start first with the questions your leadership is asking (e.g. "when will projects be done?"..."what MVP will we have by this fixed date?")
* Then, see what data you already have available to help address those questions. Don't reinvent the wheel if you don't have to.
* Finally, if there are gaps between leaderships questions and our ability to answer then, try as much as possible to minimize the impact to delivery teams. One CIO wanted every employee to record their activities in a new timesheet system, so that he could find inefficiencies. When you did the math, he had a 100 person organization and a portfolio of authorized projects totaling 400 man years. The real problem was NOT efficiency reporting; the real problem was that his organization was over-committed by 4x

So...generate as many documents as necessary to empower leadership, but do so without impacting the empowerment or effectiveness of delivery teams as much as possible. That sweet spot is different for every organization.
Thanks for your input Jesse! This is very helpful. I think focusing on balancing the needs of our leadership and our delivery teams is a really reasonable approach. Everyone can get on board with documenting only when its critical so we can accelerate delivery and improve results!

Please login or join to reply

Content ID:
ADVERTISEMENTS