Establishing The Agile PMO
By Jim Stewart
Long back, I posted an article on LinkedIn titled, Lessons Learned in Establishing a Project Management Office (PMO.) It centred around the discussion of plan-driven projects, typically manifested by the waterfall methodology.I subsequently spoke on this topic at a Project Management Institute (PMI®) chapter meeting and was asked to incorporate some thoughts on how the PMO might support adaptive or Agile methodologies. Having now helped establish several PMO’s, I’d like to share a few thoughts on this.Firstly, Agile is different philosophically in many ways than waterfall. One of the main tenets of the Agile Manifesto is "Working Software Over Comprehensive Documentation." This does not mean NO documentation; it just means that working software is valued more.Conversely, the plan-driven project typically relies heavily on documentation. And therefore, the waterfall-based PMO reflects this by having any number of templates, forms, and archived notes. So, for example, the well-stocked plan-driven PMO has templates for charters, risk registers, project management plans, etc.But in Agile, let's say specifically in the Scrum variant, the team requires artifacts such as product backlogs (essentially all the requirements), sprint backlogs (what activities you will perform during a sprint), and release plans (how many sprints you will need to perform). Often – outside of reporting – Agile teams don’t use much more than that.In the PMO’s in which I have been involved, we created these templates and put them in the repository, but, depending on the type of PMO it was, teams were free to use them or not as they decided.If teams in Agile are, by definition, self-organizing, what else besides templates might a PMO provide? Well, the best practices organizations will be able to provide Agile coaches to kick-start a project. As one Agile coach advised me, this helps create a mindset in the team right from the start. And of course, the PMO can then provide ongoing mentoring and training.This same coach advised that not all projects should be Agile. If a product that the team is creating is well-understood or the culture of that division does not support the Agile philosophy, the PMO can advise as to whether a project should be Agile. It should not impose its philosophy on every project.You might argue that the “world is going Agile.” In a very real sense, yes, it is. But there are any number of projects that have lent themselves for years to the waterfall methodology and continue to do so. A colleague of mine works for a telecommunications company and they are always rolling out new networks. This is such a well-understood technique that classic waterfall works quite well for them.One area in which the Agile PMO can assist is in gathering metrics. Since Agile is all about delivering value, how well teams deliver that value might be of interest. You can track and measure such things as a team's velocity, burn-up or burn-down rate.Since the Agile PMO has visibility across the organization, it has the unique ability to coordinate resources and best practices among teams. In a sense, it is an overseer of quality and resource management. Some organizations employ the concept of Scrum of Scrums, wherein Scrum Masters who are "ambassadors" from other teams regularly convene. The PMO could facilitate this get-together to share ideas, especially if teams are siloed.And while it is by no means known as an exemplar of agility, PMI recently published an Agile Practice Guide1. They noted three things about the Agile PMO that I agree are worthy of note:An Agile PMO is value-driven. It provides the right value at the right time, not imposing on its customers but working with them in a consultative fashion.An Agile PMO is invitation-oriented. A corollary of the first precept, the PMO is available to all in the organization but especially invites in those who find the concept and its services of value. Their interest makes them much more likely to engage.An Agile PMO is multidisciplinary. Not all PMOs are created equal. The more successful ones are centers of excellence and provide not only project management-related expertise but also advice in disciplines such as change management.Key point - if you're introducing Agile into a more traditional organization, try to do it in such a way that management is comfortable with the tools you're using. In one company that I consulted to, we made sure to use recognizable formats and templates wherever possible. People ask for change but nobody really likes it very much.These are just a few of the ideas that we (it's a team endeavor to set up a PMO), considered. In the instances where I've done this work, I've kept a copy of the Agile Manifesto handy. The takeaway here is to make sure that the Agile PMO is ....Agile!1. Agile Practice Guide, p. 81. ©2017, Project Management Institute, Inc.© Jim Stewart, PMP, CSM 2018
based on 59 customer reviews
The Personal Agile Transformation: An Agile Journey To Productivity
By Jim Stewart
Much is made lately of the fact that some organizations are making the transformation to Agile, finding the greater emphasis on self-organizing teams, incremental deliverables and maximal business value compelling. However, whenever one reads about this transformation, it’s usually from the perspective of the organization and how Agile impacts it as a whole.
But while from the outside it would appear that an organization is some faceless monolithic structure, we know that it is comprised of living, breathing people who themselves deliver the goods and services that the organization provides. And so, it seems important to consider what the impact is on those who must deal with their own personal Agile transformation.
I have been performing traditional project management for over twenty years. I teach project management as well, and I’ve always been fond of telling my students that project management is, like accounting, a mature profession. Accountants talk about debits and credits and the only thing that really changes periodically is the tax code. The lingua franca of project management is, and for many years has been, artifacts such as Gantt charts and Work Breakdown Structures.
But to a great extent, the ground has started to shift under the feet of traditional (plan-driven or waterfall) project managers, especially in the last few years. This is because the Agile approach, initially defined in a manifesto in 2001, has really begun to establish itself in corporations. Not, I would say, to the extent that it is replacing traditional methods and not everywhere.
But significantly enough that project managers now need to be not only conversant in it but must also begin to consider being trained in it and getting some experience. (Its greater recognition in that bastion of traditional project management, PMI’s Project Management Body of Knowledge, Sixth Edition, is a fairly significant development).
On a personal level, I got my Certified Scrum Master certification in early 2013 but never used it, at least not initially. It wasn’t so much that I was opposed to Scrum as much as that I was working in traditional project management and hadn’t really witnessed first-hand the revolution under my own feet.
But gradually I began to realize that there was going to be a significant shift in the direction of the use of Agile and that in order to stay conversant – and, I might add employed – it would be necessary to start getting exposed to Agile projects and working in them.
And in thinking about it, I realized that perhaps the very first thing I had to contend with in Agile was the fact that not only is the project manager role not quite as significant, in fact, there is no defined PM role as such. In the Scrum variant, there are only three defined roles – Scrum Master, Product Owner, and Development Team.
When I got my Scrum certification, I realized even then that it was a different type of role. As a project manager, I might – and should – do all the planning with my team. But when it comes time to decide who did what and when, that was always my job. It is very much of a command and control structure. And not only did I expect to lead the team, the team expected to be led.
But in Agile it’s quite different. In that role, I am much more of a facilitator or coach than I am a driver of the team. The team is self-organizing, meaning that while I can help remove impediments for them, it is not my job to tell them what to do as such. It is their job to figure out what to do as a team and for the Scrum Master to facilitate and coach.
Find some useful tips on how to succeed with your Agile transformation below-
This is a major shift, not only for the project manager but also for the team. For the project manager, he or she must stop being directive and start being facilitative. For a lot of PMs, this is a very challenging transition. They don’t know how not to direct. And as likely as not, if they have been a PM for a long time, they are very much used to using a scheduler such as MS Project. But a Scrum team doesn’t necessarily need such a tool, preferring workflow tools such as Jira to track progress.
The challenge is that the traditional project manager must hold back on telling the team what to do when they ask. He or she can remove impediments when they arise. But his or her best advice when asked what a team member should do is “take it to the team.” In a sense, he or she has to rethink what he knows and throw some of his or her training out the window.
Be a Scrum Master, Not a Scrum Manager https://t.co/ohOBBzH5Lb #agile #scrum #dev @HyperRTs @DNR_CREW pic.twitter.com/XrmsCAdzwK
— Seth G. (@Nicko_iCorplife) October 14, 2017
And it isn’t just the PM that may have a problem adapting to this new reality. Imagine the team member who is used to being told what to do in a hierarchical situation. Now he or she is faced with, to a certain extent, being self-directed. Some prefer not to go through this experience.
And while Agile can be used for a variety of projects, it still tends to be heavily used in software development environments. And some developers, for example, used to working alone, are now expected to meet every day not only with the team but with the business. For some, this is outside their comfort zone. I spoke to a woman at an Agile conference who advised me that several developers on her team asked to be moved or left the company when Agile came in.
I think the main takeaway here is embracing change and adapting. (Ironically, hallmarks of Agile itself.) Some people just prefer to do things the way they’ve always done them. And then when change overtakes them – as surely it is doing in an Agile world – they are unable to make an adjustment and wind up on the outside looking in.
Once I realized that I needed to get into this world, I made this transition not only by getting trained but by adopting an Agile mindset. (Which is what Agile coaches help teams do.) I started reading everything I could get my hands on, networked as much as I could and then when the time came, leveraged that knowledge and my years in project management into a role within a company that, while Agile-ready, still saw the value of both approaches. And when I let go of the need to be in control – and realized I needed to be a coach and facilitator - I found that things just fell into place.
based on 22 customer reviews