September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
Interesting your question
Thanks for sharing
What led to the initiative to introduce some basic governance items?
In your opinion, what is the reason that leads teams to react like that?
The initiative was requested by our new CIO; there was little to no governance previously, and "project management" was considered to be of little value because of past experiences among teams. The CIO wanted to see the value of the projects that were greenlighted, to deliver value faster, and to become more Agile.
The teams' reaction stems from a resistance to change, mostly from the employees that have been with the company for longer terms. They are used to doing things their own way and don't see any value in some of the governance items that have been proposed. (Most do add both upstream and downstream value, but realizing that value is taking time.) So, since we are making continuing efforts to get people used to the terminology and mindset of Agile, there are some teams that feel that the idea of a "self managed team" means no PMO governance, so they push back.
It's one of the many myths that Agile teams and developers can do what they want, anything else "isn't Agile," coupled with a previously free-form organizational culture with no governance at all and it becomes a change management nightmare.
We should make a distinction between self-managing and self-organizing teams. Teams can be self-managing, but that's not defining trait of agile teams. If your team insists they need to be self-managing, ask them why. The term that documents like the Agile Manifesto and the Scrum Guide typically use is "self-organizing."
This term causes confusion, too. Self-organization doesn't necessarily mean that everyone gets to choose what team they belong to on any given day. It means that the team gets to decide how their work gets done. As long as the team has all the cross-functional roles it needs to get the work done, then they shouldn't need a manager showing up and telling them how to do the work. (This also implies that a "self-managing" team needs to have embedded management of some type.)
Look up an HBR article from 1986 called "The New New Product Development Game." It goes into some nuance around self-organization. Some guidelines for finding the right balance of management:
"Although project teams are largely on their own, they are not uncontrolled. Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos. At the same time, management avoids the kind of rigid control that impairs creativity and spontaneity."
Expect your teams to continue to resist management. That's healthy, to a degree. Too much management is not only wasteful, but it erodes any degree of agility that you're trying to establish in your organization. It will take time and experience to find the right balance, but as long as everyone is open and committed to continuous improvement, you'll find it.
I will write after working on this type of things from 1995 up to date, including I lead the transformation in my actual work place. Agile is not a mindset. That´s the key point. The question is: "what must be transformed?". That´s the question most of the people do not know the answer. What it has been transformed is the whole enteprise architecture, which is composed by business/application/technology/security/information layers. So, first thing to take into account is you need to stay clear on impacts. If you are talking about the Manifesto for Software there is no line about self-management teams. That´s an "invention" of Scrum framework. You do not need self-management teams to implementa Agile. It could be good go for it? Indeed. But you can apply agile in your current situation. Some people think that Agile is about to use a method. That´s the first step to fail. So, my question for you,with the aim to help you, is: are you thinking to use a method/framework because you think it will help you to transform to Agile?
Disciplined Agile provides a number of good resources related to lean governance which is that delicate balance between control objectives and team empowerment/autonomy.
This page from the DAD site provides some good ideas: https://disciplinedagiledelivery.com/enterpriseawareness/
The purpose of the PMO is not to manage teams but to guide and support team wrt governance. There is a huge difference and in my opinion, do not overlap.
In line with Anton, the PMO provides governance, support and performance management to the project teams. If the PMO is getting strong pushback from the already high performing teams, it may indicate the PMO needs to step back and ensure the purpose and goals of the PMO are understood by the project teams. Conversely, a PMO that adds management complexity may need to assess increasing team resources from distracting the project teams to serve the PMO.
You definitely need to establish a framework - within which the teams can self organize . For example , establish a team structure (eg Disciplined Agile ) and governance structure (project board / Steer Co) to report on projects .
Once a Project Manager and/or Product Owner have established the scope and prioritized the backlog ( IN consultation with the delivery team ) , then the team is given autonomy on how to produce the deliverable (self organizing) .
The PMO definitely needs to guide on WHAT .....and leave the self organizing team to define the HOW .....
Please login or join to reply