(Re)Introducing Project Management in a SAFe world - Revision history

S206391: /* Why (Re)Introduce an (A)PMO */

2021-02-28T22:35:49Z

Why (Re)Introduce an (A)PMO

← Older revision		Revision as of 22:35, 28 February 2021
Line 207:		Line 207:

	'''Dean Leffingwell says so...'''		'''Dean Leffingwell says so...'''
	As Dean Leffingwell (the creator and chief methodologist at SAFe) advocates having an APMO ~~from Version 4,5 the most up to date~~ versions of the model ~~suggest having one optimal~~ for ~~organizational performance. As the monitoring and control of value is managed out of the APMO it may also be advantageous~~ to as Dean Leffingwell ~~says himself~~ in his 2010 book "Agile Software Requirements"<ref name ="ASR">Dean Leffingwell, Agile Software Requirements, (Wesley, 2010),</ref> "~~Project Managers should be re~~-~~tasked~~ as Agile Project Managers." ~~to monitor value on projects.~~		Dean Leffingwell (the creator and chief methodologist at SAFe) advocates having an APMO in recent versions of the model.
	Both then and now Dean Leffingwell appears to be recognizing ~~the value of all of the parts of project management~~ that ~~were not passed explicitly into~~ the ~~scrum teams themselves~~ such as ~~contract and relationship management and communication interfaces with suppliers~~, ~~customers and other parts of the enterprise~~.		His support for this appears to have been longstanding as all the way back in 2010 Dean Leffingwell in his 2010 book "Agile Software Requirements"<ref name ="ASR">Dean Leffingwell, Agile Software Requirements, (Wesley, 2010),</ref> he suggested "Re-tasking your project managers as Agile Project Managers." Both then and now Dean Leffingwell appears to be recognizing that PPPM was more than just the tasks handed out to Scrum Masters and Product Owners but it has other responsibilities such as stewardship of value, facilitating strategy execution.

S206391: /* Why (Re)Introduce an (A)PMO */

2021-02-28T22:26:24Z

Why (Re)Introduce an (A)PMO

← Older revision		Revision as of 22:26, 28 February 2021
Line 203:		Line 203:
	2) 4.1 times more likely to agree the company has the right Vision and strategy <ref name ="intagpract"> https://docs.broadcom.com/doc/how-agile-and-devops-enable-digital-readiness-and-transformation /Page 12</ref>.		2) 4.1 times more likely to agree the company has the right Vision and strategy <ref name ="intagpract"> https://docs.broadcom.com/doc/how-agile-and-devops-enable-digital-readiness-and-transformation /Page 12</ref>.

	This leads to the conclusion that ~~larger~~ companies benefit the most from Implementing SAFe with a strong PMO supporting strategy formation and execution regardless of any specific direction or lack of direction about this from SAFe.		This leads to the conclusion that companies benefit the most from Implementing SAFe with a strong PMO supporting strategy formation and execution regardless of any specific direction or lack of direction about this from SAFe.

S206391: /* Conceptual Issues with SAFe */

2021-02-28T22:25:42Z

Conceptual Issues with SAFe

← Older revision		Revision as of 22:25, 28 February 2021
Line 152:		Line 152:

	A common theme across articles on SAFe is ultimately that SAFe is not Agile enough <ref name ="problems">https://productcoalition.com/the-major-problems-with-safe-1e797f7e48f8 </ref>		A common theme across articles on SAFe is ultimately that SAFe is not Agile enough <ref name ="problems">https://productcoalition.com/the-major-problems-with-safe-1e797f7e48f8 </ref>
	<ref name ="problems2">https://blog.projectmanagementacademy.net/common-problems-with-safe#:~:text=%20Common%20Problems%20When%20Using%20Scaled%20Agile%20(SAFe),approaches,%20the%20word%20%E2%80%9Cepic%E2%80%9D%20refers%20to...%20More </ref>		<ref name ="problems2">https://blog.projectmanagementacademy.net/common-problems-with-safe#:~:text=%20Common%20Problems%20When%20Using%20Scaled%20Agile%20(SAFe),approaches,%20the%20word%20%E2%80%9Cepic%E2%80%9D%20refers%20to...%20More </ref>it:


	- Focuses on Methodology. Processes and velocity ~~over~~ creation of value		c- Focuses on Methodology. So things like Processes and velocity become the focus rather than creation of value

	~~- Lack of Flexibility & Autonomy for the teams when constrained by ART structures, PI's and processes to support control in a wider organization~~

	- ~~Too structured~~ to ~~be truly agile~~		- Lacks of Flexibility & Autonomy. Teams are constrained by ART structures, PI's and processes to support control in a wider organization

	- ~~Hides~~ the real issues. Co-ordination ~~and Interdependencies~~ between teams ~~can become more meetings~~ to ~~organize the~~ dependencies ~~rather than re-organize~~ the ~~ART's~~		- Can hide the real issues. For example by focusing on Co-ordination between teams to manage dependencies it can look over organization as the underlying problem


	Although these are not issues that would be resolved by a PPPM or a PMO specifically, they do point to a need for organizations to have a clear idea of what Agile is to their organization. They also need to align everyone in the organization with that vision to ensure everyone is pulling in the same direction. An APMO can support the Lean Agile Center of excellence with this		Although these are not issues that would be resolved by a PPPM or a PMO specifically, they do point to a need for organizations to have a clear idea of what Agile is to their organization. They also need to align everyone in the organization with that vision to ensure everyone is pulling in the same direction. An APMO can support the Lean Agile Center of excellence with this


	===Personal observations on SAFe implementations===		===Personal observations on SAFe implementations===

S206391: /* General issues with Agile Frameworks */

2021-02-28T22:21:24Z

General issues with Agile Frameworks

← Older revision		Revision as of 22:21, 28 February 2021
Line 143:		Line 143:

	For example: Autonomy and flexibility in choice of tooling is difficult to scale as corporate IT systems and policies are not designed to support unlimited variety in tooling. Tooling often also represents the working behaviors, practices and limits of teams activities and the variety of working practices works against the principles of flexibility of the teams across the whole organization to work together on new challenges. Dependencies across team can also be problematic when there are a wide variety of possible communication channels, prioritization methods and cadences etc		For example: Autonomy and flexibility in choice of tooling is difficult to scale as corporate IT systems and policies are not designed to support unlimited variety in tooling. Tooling often also represents the working behaviors, practices and limits of teams activities and the variety of working practices works against the principles of flexibility of the teams across the whole organization to work together on new challenges. Dependencies across team can also be problematic when there are a wide variety of possible communication channels, prioritization methods and cadences etc
			PMO's can help manage the complexity of different teams working differently

	9.Misalignment between Customer Processes and Large-Scale Agile Frameworks		9.Misalignment between Customer Processes and Large-Scale Agile Frameworks

	~~Manifests in 2 forms. Customer engagement especially on larger Epics is not well accounted for.~~ Agile suggests customer engagement but SAFe stops at the Epic Owner assuming the are ~~always aligned with~~ the customer~~. But there is also a wider point~~ that ~~SAFe does not have specific customer engagement roles which may be required to manage for example: large Client contract relationships. It~~ is ~~also does not account well for management of third parties~~ and ~~interfaces~~ with the ~~wider enterprise it operates in~~.		Agile suggests customer engagement but SAFe stops at the Epic Owner assuming the are a proxy for the customer that is always engaged with and aligned with the customer.
	~~PMO's can provide flexible resources to help deal with things like supporting the development organization deal with external stakeholders~~

	===Conceptual Issues with SAFe===		===Conceptual Issues with SAFe===

S206391: /* General issues raised with SAFe */

2021-02-28T22:17:28Z

General issues raised with SAFe

S206391: /* Background */

2021-02-28T22:06:00Z

Background

← Older revision		Revision as of 22:06, 28 February 2021
Line 42:		Line 42:


	- General issues with ~~Scaled~~ Agile Frameworks		- General issues with Agile Frameworks

	- Conceptual Issues with SAFe specifically		- Conceptual Issues with SAFe specifically

S206391: /* Background */

2021-02-28T22:05:24Z

Background

← Older revision		Revision as of 22:05, 28 February 2021
Line 44:		Line 44:
	- General issues with Scaled Agile Frameworks		- General issues with Scaled Agile Frameworks

	- ~~Specific~~ Issues with SAFe		- Conceptual Issues with SAFe specifically

	- Personal observations on SAFe implementations		- Personal observations on SAFe implementations

S206391: /* Background */

2021-02-28T22:04:40Z

Background

← Older revision		Revision as of 22:04, 28 February 2021
Line 38:		Line 38:


	As a consequence many companies have had to contend with a variety of issues caused by the removal of PPPM practices and would benefit from (Re)-introducing ~~them~~. Issues:		As a consequence many companies have had to contend with a variety of issues caused by both the Agile Transformation and the removal of PPPM practices and would benefit from (Re)-introducing a (A)PMO. This wiki looks at 3 groups of Issues:

S206391: /* Background */

2021-02-28T22:02:22Z

Background

← Older revision		Revision as of 22:02, 28 February 2021
Line 40:		Line 40:
	As a consequence many companies have had to contend with a variety of issues caused by the removal of PPPM practices and would benefit from (Re)-introducing them. Issues:		As a consequence many companies have had to contend with a variety of issues caused by the removal of PPPM practices and would benefit from (Re)-introducing them. Issues:

	~~- During Implementation~~

	- General issues with Scaled Agile Frameworks		- General issues with Scaled Agile Frameworks

S206391: /* Implementation issues with SAFe */

2021-02-28T22:02:03Z

Implementation issues with SAFe

← Older revision		Revision as of 22:02, 28 February 2021
Line 117:		Line 117:

	My personal experience at a Mid Sized software firm was introducing basic Agile practices such as cross functional team Scrum to a traditionally Waterfall organization raised productivity from 70-80% of estimated scope per to circa 104% within 12 months. In the case I mention we had the rare situation of 3 Agile teams having the old waterfall estimation process running throughout the period as the main development organizations processes still required the provision of hourly estimates. Therefore the figures are not subject to comparison errors as is usual during an agile transformation. This experience would seem to support the kind of figures SAFe advertise.		My personal experience at a Mid Sized software firm was introducing basic Agile practices such as cross functional team Scrum to a traditionally Waterfall organization raised productivity from 70-80% of estimated scope per to circa 104% within 12 months. In the case I mention we had the rare situation of 3 Agile teams having the old waterfall estimation process running throughout the period as the main development organizations processes still required the provision of hourly estimates. Therefore the figures are not subject to comparison errors as is usual during an agile transformation. This experience would seem to support the kind of figures SAFe advertise.

	~~== Implementation issues with SAFe ==~~

	~~In the study~~





	== General issues raised with SAFe ==		== General issues raised with SAFe ==

← Older revision		Revision as of 22:17, 28 February 2021
Line 132:		Line 132:

	5.Top-down versus Bottom-up Implementation of Large-Scale Agile Frameworks		5.Top-down versus Bottom-up Implementation of Large-Scale Agile Frameworks

	For example: Bottom up models tend to create large numbers of teams that have fragmented working practices, Tooling, Methods of communicating, Definitions of done etc. This can create additional complexity coordinating amongst teams and getting a clear picture of the organization from the top. Whereas Top down models tend to take the enthusiasm out of the Agile transformation by being seen a prescriptive and unresponsive to the needs to the teams		For example: Bottom up models tend to create large numbers of teams that have fragmented working practices, Tooling, Methods of communicating, Definitions of done etc. This can create additional complexity coordinating amongst teams and getting a clear picture of the organization from the top. Whereas Top down models tend to take the enthusiasm out of the Agile transformation by being seen a prescriptive and unresponsive to the needs to the teams
	PMO's can support the bottom autonomy while helping deploy best practice and standards that may be needed across ART's and Value Trains to support consolidated business level planning for the top		PMO's can support the bottom autonomy while helping deploy best practice and standards that may be needed across ART's and Value Trains to support consolidated business level planning for the top

	6.Over-emphasis on 100% Framework Adherence over Value		6.Over-emphasis on 100% Framework Adherence over Value

	For example: Maintenance teams that rely on kanban for their workload management being called into PI planning events and 2 weekly sprint cycles despite the practice being wasteful and unnecessary for the team.		For example: Maintenance teams that rely on kanban for their workload management being called into PI planning events and 2 weekly sprint cycles despite the practice being wasteful and unnecessary for the team.

	8.Maintaining Developer Autonomy in Large-Scale Agile Frameworks		8.Maintaining Developer Autonomy in Large-Scale Agile Frameworks

	For example: Autonomy and flexibility in choice of tooling is difficult to scale as corporate IT systems and policies are not designed to support unlimited variety in tooling. Tooling often also represents the working behaviors, practices and limits of teams activities and the variety of working practices works against the principles of flexibility of the teams across the whole organization to work together on new challenges. Dependencies across team can also be problematic when there are a wide variety of possible communication channels, prioritization methods and cadences etc		For example: Autonomy and flexibility in choice of tooling is difficult to scale as corporate IT systems and policies are not designed to support unlimited variety in tooling. Tooling often also represents the working behaviors, practices and limits of teams activities and the variety of working practices works against the principles of flexibility of the teams across the whole organization to work together on new challenges. Dependencies across team can also be problematic when there are a wide variety of possible communication channels, prioritization methods and cadences etc

	9.Misalignment between Customer Processes and Large-Scale Agile Frameworks		9.Misalignment between Customer Processes and Large-Scale Agile Frameworks

	Manifests in 2 forms. Customer engagement especially on larger Epics is not well accounted for. Agile suggests customer engagement but SAFe stops at the Epic Owner assuming the are always aligned with the customer. But there is also a wider point that SAFe does not have specific customer engagement roles which may be required to manage for example: large Client contract relationships. It is also does not account well for management of third parties and interfaces with the wider enterprise it operates in.		Manifests in 2 forms. Customer engagement especially on larger Epics is not well accounted for. Agile suggests customer engagement but SAFe stops at the Epic Owner assuming the are always aligned with the customer. But there is also a wider point that SAFe does not have specific customer engagement roles which may be required to manage for example: large Client contract relationships. It is also does not account well for management of third parties and interfaces with the wider enterprise it operates in.
	PMO's can provide flexible resources to help deal with things like supporting the development organization deal with external stakeholders		PMO's can provide flexible resources to help deal with things like supporting the development organization deal with external stakeholders

	===Conceptual Issues with SAFe===		===Conceptual Issues with SAFe===

	A common theme across articles on SAFe is ultimately that SAFe is not Agile enough <ref name ="problems">https://productcoalition.com/the-major-problems-with-safe-1e797f7e48f8 </ref>		A common theme across articles on SAFe is ultimately that SAFe is not Agile enough <ref name ="problems">https://productcoalition.com/the-major-problems-with-safe-1e797f7e48f8 </ref>
	<ref name ="problems2">https://blog.projectmanagementacademy.net/common-problems-with-safe#:~:text=%20Common%20Problems%20When%20Using%20Scaled%20Agile%20(SAFe),approaches,%20the%20word%20%E2%80%9Cepic%E2%80%9D%20refers%20to...%20More </ref>		<ref name ="problems2">https://blog.projectmanagementacademy.net/common-problems-with-safe#:~:text=%20Common%20Problems%20When%20Using%20Scaled%20Agile%20(SAFe),approaches,%20the%20word%20%E2%80%9Cepic%E2%80%9D%20refers%20to...%20More </ref>
Line 159:		Line 164:


	Although these are not issues that would be resolved by a PPPM or a PMO specifically they do point to a need for organizations to have a clear idea of what Agile is to their organization ~~and~~ to align everyone in the organization with that vision to ensure everyone ~~in the organization~~ is pulling in the same direction. ~~That effort however may be something an~~ APMO ~~aligned with a~~ Lean Agile Center of excellence ~~might be tasked~~ with ~~ensuring~~		Although these are not issues that would be resolved by a PPPM or a PMO specifically, they do point to a need for organizations to have a clear idea of what Agile is to their organization. They also need to align everyone in the organization with that vision to ensure everyone is pulling in the same direction. An APMO can support the Lean Agile Center of excellence with this


Line 167:		Line 172:

	- Issues with Epic ownership.		- Issues with Epic ownership.
	Epic owners have influence but not authority to get their initiatives prioritized. ~~When absent from~~ a PMO escalation of issues can be more difficult as ~~can~~ access to peers and best practices. If Epics are run from within an ART/Value stream (Usually by Product Management) they have great authority within their ART but are often unable to focus on the Epic as it is only one of very many responsibilities they have, ~~through~~ a ~~wide range~~ of factors from ~~Knowledge of other ART/Value streams businesses ,~~ Politics between Peers ~~in other ARTs~~ to maturity of Dependency management processes ~~and~~		Epic owners have influence but not authority to get their initiatives prioritized. Without a PMO escalation of issues can be more difficult for an Epic Owner as they have less access to peers and best practices. If Epics are run from within an ART/Value stream (Usually by Product Management) they have great authority within their ART but are often unable to focus on the Epic as it is only one of very many responsibilities they have, the Product Manager may have factors limited knowledge outside their ART/Value stream and a number of other factors from Politics between Peers to maturity of Dependency management processes can effect their ability to execute

	-~~SAFe’s~~ is rooted in Scrum which in turn made its biggest successes in Business to Consumer product development and when used inside companies in house IT teams. ~~This means it~~ is optimized to ~~delivery of~~ small packets of work that create value at the end of each sprint. This works very well for delivery of a new feature or a trading desk ~~that wants their developers to give then a new feature~~. But it does not necessarily support delivery of large complex packages of work that are tied into formal contracts. ~~In particular there~~ are issues with A) the conflicts between MVP for a contract and making the customer ~~very~~ happy B) Very large cross functional things are hard to get prioritized C) Regulatory and Contract penalty dates for Large developments~~. As they~~ are ~~infrequent~~ estimates based on the last "large thing" can easily be wrong by a significant margin ~~and therefore the~~ approach to solving ~~them~~ is not ~~appropriate~~. Mitigations like Spikes to look into work for the next PI can give an illusion of progress rather than ensure success ~~which~~ in ~~some cases requires taking~~ more ~~of the~~ analysis work upfront than SAFe suggests		-SAFe is rooted in Scrum which in turn made its biggest successes in Business to Consumer product development and when used inside companies in house IT teams. It is optimized to deliver small packets of work that create value at the end of each sprint. This works very well for delivery of a new feature for an app, or delivery of new feature to a trading desk. But it does not necessarily support delivery of large complex packages of work that are tied into formal contracts or large deliveries. There are issues with A) the conflicts between MVP for a contract and PO's making the customer happy with every feature, B) Very large cross functional things are hard to get prioritized C) Regulatory and Contract penalty dates for Large developments are problematics as estimates based on the last "large thing" can easily be wrong by a significant margin. The approach to solving these problems is not the same as smaller more certain things. Mitigations like Spikes to look into work for the next PI can give an illusion of progress rather than ensure success, in effect more analysis work is required upfront than SAFe suggests.

	- Interfaces outside of the SAFe Organization Interfaces with the rest of the organization, Management of customer contracts and 3rd party suppliers etc is very unclear in the model. SAFe pretty much ignores that this may require substantial effort and assumes it can easily be absorbed into other roles. SAFe does not open up to roles that may be needed as part of managing these interfaces		- Interfaces outside of the SAFe Organization Interfaces with the rest of the organization, Management of customer contracts and 3rd party suppliers etc is very unclear in the model. SAFe pretty much ignores that this may require substantial effort and assumes it can easily be absorbed into other roles. SAFe does not open up to roles that may be needed as part of managing these interfaces


			A formal PMO could assit with all of these points.

	== (Re) Introducing a SAFe APMO ==		== (Re) Introducing a SAFe APMO ==