Since 2003, as a principal of JP Stewart Associates, Jim has been engaged in multiple endeavors including consulting, training and mentoring. A PMP since 2001 and Certified Scrum Master since 2013, he provides PMP Prep training both in public and private in-house sessions. In consulting, he frequently contributes by helping organizations increase their project maturity. He recently consulted to a financial services firm to help them set up a project management office. Jim is on the PM advisory board of MindEdge, Inc. and is co-author of the upcoming book, “Facilitating Project Planning Meetings: A Practical Guide to Ensuring Project Success.”
Long back, I posted an article on LinkedIn titled,...
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.