Get certified - Transform your world of work today

Close

How a Project Manager Can Supervise an Agile Transformation

19 December 2017

Samarjit Mishra
Wipro Consulting


This post is a collection of my experiences and notes from others with whom I have worked. I have also interviewed different levels of project managers (PMs), in various capacities, who have embraced Agile wholeheartedly. This post is not meant to blame any individual or any profession, but merely to draw attention to the pain points of an Agile transformation for a specific scenario.
 

Top five challenges of an Agile adaptation

Having worked on various Agile transformation and DevOps transformation projects, and having acted as a ScrumMaster for different teams, I’ve discovered that there will be challenges in every project — that is nothing new. I had always taken each challenge as a learning opportunity, which has enriched my experience and bolstered my confidence. But which challenge was the toughest one for me? According to the VersionOne 11th Annual State of Agile Survey report, the following are the top five challenges for adapting to the Agile way of working or scaling Agile.
  • Company philosophy or culture at odds with the core Agile values
  • Lack of experience with Agile methods
  • Lack of management support
  • Organization’s general resistance to change
  • Lack of business, customer, or product owner
I also looked at the next six challenges that respondents had given, but I was unable to find the one that I have faced the most and was difficult for me to fix. The biggest challenge that I have faced to date is working under a PM to deliver Agile transformation. Have you faced a similar situation?
 

Eight ways the project manager can improve Agile transformation

Based on my experiences, to ensure a successful Agile transformation, the PM must create these eight improvements in his or her way of working.

1. Embrace rolling-wave planning and unlearn up-front planning.

Whenever I join a transformation program, the first thing expected from me is to provide a short-term plan and a long-term plan for our deliverables. I prefer to give a list of well-defined, prioritized activities in the form of a product backlog and then inform the team that I have visibility into, at best, the next two sprints (each sprint being two to three weeks long). This way, I do not need to manage scope and instead can build detailed GANTT charts.

However, the challenge comes when there’s demand for the short-term plan (three to four months) and the long-term plan (six to 10 months). There is nothing wrong in having a plan up front, but the level of detail that we look for in a plan is the point of contention. Also, it depends on your approach to accepting the frequent change in plan or adjustment of the goalpost as the result of a new understanding or the impediments that strike along the way. Any transformation strategy is like R&D work in any innovation-minded company, where you try out different ideas and juggle different priorities with different stakeholders. Any plan we can design is sure to change in the future because of unforeseen challenges and impediments.

In every organization that I have worked for, transformation is always a side project and not the main focus. As a result, the teams working on their specific deadlines are not available to give the time required for the success of the transformation. Hence, any exhaustive advance planning will never fly.

2. Achieve an Agile mindset through coaching and training.

The first thought that crosses a PM’s mind is to send all team members for Agile foundation training. Members are usually not part of those sessions or discussions. They think that by reading or listening to a few seminars on Scrum, they now know everything, and they start working toward Agile transformation.

Agile transformation is simple if you understand the essence of agility and try to live by its values. Merely reading and using some buzzwords will not bring the required transformation. My experience teaches me that there is nothing to learn in Agile; rather, there’s a lot more to unlearn. The difficult part to unlearning can be overcome by training and coaching and pursuing your individual interests.

3. Focus on timely value delivery.

The traditional PM is tuned to the Iron Triangle, in which the scope never changes. By focusing all our energy only on scope, we lose the time-to-market competitive advantage. In the Agile triangle, the scope is flexible,. As a result, we have the advantage of reprioritizing the work as time progresses, maintaining the value that is generated. This complements Improvement #1, which recommends rolling-wave planning.

I was never successful in giving a milestone transformational plan and achieving that target every time, because some things are not quantifiable. I can define a milestone for providing Agile training to 100 team members per quarter, but I won’t be able to guarantee that they all are following the Agile values. This effort requires continual engagement, and therefore there will be lots of tried and tested mentoring for different team members.

4. Learn ways of working over forms and processes.

Governance is good, and it is always nice to have an overview of what is happening and how to improve on it. The governance meeting has always been a source of contention in any transformation I have worked on or heard about from other Agilists. The intention is to work collaboratively to improve, not to play mud-slinging games. But, unfortunately, this governance, assessments, and audits have become a yardstick of your achievement.

The purpose of creating different processes and filling out documented forms is to help and collaborate with teams. But if it becomes a repetitive task of filling in the same set of data in different formats for different stakeholders, then it’s a waste. How many times have people gone back to read the meeting minutes? Can we look at the alternatives and keep it simple, with minimal action points to track? Many times I have heard senior leadership asking why this or that is not done, and why haven’t they been informed about it. Can we change this tone to how can I help to rectify this so that it will not happen in the future? Or: How can I be informed about this in the future without negatively affecting your work? These subtle changes in our approach will make a significant difference in the ways we work.

5. Embrace iterative and incremental value delivery and unlearn phased working.

Distinct multiphase project planning phases must become part of the past to enable iterative and incremental value delivery. What is the point of developing a phase that will not create value for the customer or business? Can we look at different options to make the different phases linear and repetitive?

Let the team work independently of the plan that senior management wants to see. If the PM needs to present it in a different way, look at the existing ways of working with the team, and create and maintain your own template separately. The moment we try to bring our traditional approach into the Agile ways of project delivery, it will dilute the essence of Agile philosophy.

6. Build cross-functional teams.

The number of handovers that happen in a delivery pipeline are directly proportional to the delay and waste. If someone is working on multiple projects, his or her working hours can be added to reach 100% billability, but in actuality, the individual will be delivering 70% or less productive value. We all consume time for context switching between activities.

PMs must break the organizational silos and build a cross-functional team that can resolve its own differences and deliver without any handover or SLA parameter. In this case, everyone’s goal and focus is the same objective.

7. Collaborate with the team to empower it.

No one wants to be commanded to do anything; that is basic human nature. We create an environment in which we commanding something and realize short-term benefits, but in the long term, this approach will backfire, as the team members will be fully dependent on getting assigned to do their work. Therefore, we will always have a single point of failure.

There is no quick method of empowering the team. It will take time until the team realizes the benefit and feels respected. In the name of maintaining scope, cost, and time, PMs invariably step into the mindset of getting involved in everything. Let’s give team members the space and environment to express themselves. Let the Agile team define the processes and tasks required to accomplish goals. Try to facilitate conversation and delivery.

You may feel like you’re losing your control and authority, but the pleasure of working with the team and celebrating successes together go far beyond those losses.

8. Make goals that are “people and culture” transformations.

According to the VersionOne survey, the top objective of every organization is to increase productivity and the business margin. I have yet to see an organization whose sole goal is to transform their people and culture.

I firmly believe that if I can bring this transformation, then all other objectives will be the by-product of this work. This is the area that I always look to for the PMs. They are the folks who are closest to the team, and who have the highest, most influential ability to bring tremendous improvement.



Read the story of “The Famous ‘Social Experiment’: 5 Monkeys and a Ladder.” Future generations will reap the benefits of the culture that you set now.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.8 (6 ratings)

Comments

Tom Mellor, CST,CSP,CSM,CSPO,REP, 12/21/2017 1:52:42 PM
The number one way is to get rid of the archaic, outdated role of project manager. The next thing is to realize that you cannot do a transformation. No organization is going to be magically transformed into something that embraces agility. At least I've never seen it. Heck, it probably doesn't even have a definition of agility. This post might be helpful: http://bit.ly/2pci8Nd.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe