As a Scotsman living in the US I take more than my fair share of trips through Heathrow airport.
There are many things I enjoy about being back in the UK but Heathrow airport is certainly not one of them. For a while HSBC bank tried valiantly to cheer us up, and as we trudged wearily from terminal to terminal, our journey was made more colorful by the many posters from their What’s Your Point of View campaign.
Here is an example of one of their posters:
Looking at these posters made me reflect on my own work as an Agile Coach and how I am often confronted by different points of view.
If I am speaking to a group and criticize waterfall development there is a chance someone will feel I am disparaging their team or their efforts. Sometimes use of the word agile does not serve a good purpose. Many have negative perceptions of Agile and believe it to be chaotic, undisciplined and unpredictable.
As a coach, I don’t like to spend time fixing negative perceptions of Agile. My passion is making teams and organizations successful. I like to steer away from the waterfall vs. agile discussion.
Instead, I focus on sharing what I see happening in high performance teams and organizations:
Without knowing what value really is we can’t reduce waste. Afocus on customer value answerstwo key questions: (1) Who am I building this for? and (2) Why am I building this?Once we have a keen sense of what value is we can then prioritize our work to deliver the highest value first.
By delivering early and often we give ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can help us improve.
One of the biggest impediments to delivering early and often is the inability to reduce batch size and many teams struggle with this. This is a battle worth fighting.
Another impediment to delivering value is not pull testing forward. If we don’t complete our work as we iterate then we are creating technical debt that will affect our ability to release.
Successful teams know it is best to take small incremental steps towards improvement and to establish a rhythm of continuous improvement. We don’t try to define the perfect process, we don’t set the bar too high and we continuously inspect and adapt.
As Émile Chartrier once said “nothing is more dangerous than an idea when you only have one”. Successful teams and organizations know that to survive long-term they need to create a collaborative culture that fosters innovation and shared commitment.
Are these are agile principles or lean principles? Some like to draw an ideological line between the two but like Wille Faler I don’t believe that’s a bottom-line discussion. Call them waterfall if you like, so long as you’re successful.
You might not like my list and that’s fine too. Make your own list but don’t just pull it out of a book. Visit the gemba and come up with something visceral that your team can identify with.
While the answer MAY be “Yes!”, I posited that there may be a way to save our PMOs from going the way of the now extinct dodo bird.
8 Ways To Re-Tool a PMO in an Agile Environment
Have the PMO involved in helping rollout Agile on several pilot projects
This experience forms the roots for how the Agile PMO will engage throughout the organization with other project teams.
Besides ensuring that Agile training occurs, the Agile PMO can become the coaches of coaches, training the ScrumMasters of each team. They can also be the Agile voice into the business to ensure the Product representatives are fully bought into their role in Agile.
Learn from Lean: start a Kaizen and Gemba mentality now
The PMO should be the shepherds of continuous improvement so that the Agile adoption is not only sustained; it is vibrantly organic, every improving. This means moving beyond team-level iteration-focused retrospectives.
Kaizen events create cross-team learning. This learning exposes team practices that can be useful at an organizational level. In such cases, the team practices are elevated to the organizational “Standard of Work” (see later item). Moreover, the Kaizen event clarifies when a practice does not serve the entire organization and can remain a team practice, supported by team agreements and adhered to by the team.
In addition, in between Kaizen events, apply “Gemba”. An Agile PMO learns about the organization and spreads knowledge through the organization by being involved in projects. That means going to see, or “Gemba” according to Lean practices.
Being engaged with teams rather than dictating from afar may be a dramatic shift in PMO behavior. And, it is pivotal to teams’ respecting the role of the PMO in creating a successful Agile adoption.
Change your definition of “Standard of Work”
This is not a set of standards defined by and enforced by the PMO for project conformance.
In Agile, as guided by Lean practices, a standard of work is a statement of what is currently useful, how things are currently done. It provides a team a backdrop from which to perform continuous improvement through Kaizen events such as retrospectives.
The Agile PMO, rather than controlling and patrolling, engages in facilitating teams in continuous learning. This PMO encourages empowered teams and amplifies the learning that arises when such teams are truly empowered.
A great way to provide this facilitation and to engender cross-team involvement is to help organize and facilitate program-level and multi-program release planning meetings and product councils. The Agile PMO formulates a rhythm and a continuously improving agenda to help these meetings deliver the greatest benefit across teams.
Along with being facilitative, Agile PMOs act as Servant Leaders. They serve their organizations by finding out what they need and getting it for them.
They lead by serving. They remove impediments. They measure what is a problem for teams so that they can serve teams be removing the problem. They don’t look for status from teams; they look for how they can serve teams.
So, for an Agile PMO, leading the Agile rollout means finding out what teams need and delivering that. It is about creating collaborative plans, not collecting statuses. For more about Servant Leaders in Agile, check out the first section of my book Collaboration Explained.
Provide guidance on regulatory adherence
In organizations that must adhere to Sarbanes-Oxley, FDA, HIPAA, or other regulatory guidelines, the Agile PMO can represent these “red” (immutable) stories in each team’s Product Backlog.
The PMO governance work can be the guide to each Product Owner on how to deliver the documents or features that help the entire organization remain in compliance with these regulatory constraints. Governance is now a service to project teams versus being a control mechanism.
Seek guidance from Lean to use Flow, Pull, and Innovate as guidelines for organizational-level Agile adoption
Much of the guidance here has a hint of Lean about it. That is because PMOs work at an organizational level. Moving Agile beyond one or more pilot teams requires guidance for maturing and scaling.
I recommend applying a 5-step approach which is based on Full, Pull and Innovate principles from Lean Thinking.
Once Development group is working with the business to deliver prioritized, valued items, the Agile PMO can bring in other ‘back office” functions to help ensure a growing Agile adoption.
Finance, HR, infrastructure, the executive team, and others must eventually all accept the Agile approach for true organizational change and value.
The Agile PMO has an opportunity to be the mentors and guides for this growth and maturation.
Foster useful metrics
Let go of that Waterfall security blanket around what are useful project or program metrics.
Determine which metrics to track that directly help organizations concentrate on value delivery.
Whatever does not deliver value is waste. It may be temporarily necessary waste. Or it may be a pernicious, embedded waste that has been assumed to be necessary.
An Agile PMO ferrets out these “false friend” metrics and works with teams to determine metrics around value: test coverage, team velocity, agile adoption assessment, defect counts, definition of done.
RallyDev.com
