Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, IT Project Management, PMO
Agile Transformation Challenges
Network:408



The company I work for has traditionally been executing IT projects in a waterfall model. Recently senior management have come up with a strategy to shift the methodology over to Agile, and be 100% converted to Agile model by end of 2018. This definitely calls for a cultural (aka mindset) shift in everyone involved in projects. I am curious to know what are some of the common problems that might surface during this transition process until we mature as an Agile PMO?
Sort By:
Network:1687



Soumya:
It's hard to say because it depends on your C-Suites engagement, buy-in and support for the change. I'd suggest that this is more of a transformational change that will require development of new mindsets and behaviors.

What common problems do you expect to see since you are inside the organization?
...
1 reply by Soumya Maitra
Mar 23, 2017 10:59 PM
Soumya Maitra
...
Thanks Naomi. PMO Practice Leaders are planning to bring an Agile expert consultant on board as a first step. I personally think the transformation will need to engage not just IT and PMO, but also the Business areas whose objectives are carried out through the projects. A lot of support areas such as Compliance, Risk, Legal, etc will have to adapt to the new style of executing projects. And my apprehension is that people's reluctance to change will be the biggest obstacle to overcome. Definitely exciting times ahead for us.
Network:1286



It is hard to say, and like Naomi pointed out, extremely dependent on the top-down engagement and support. Is the processes needed, players, etc. all being put in place as needed.

I will be a process, and I'm sure there will be growing pains ... and gains! Keep us posted.
Network:408



Mar 23, 2017 8:49 PM
Replying to Naomi Caietti
...
Soumya:
It's hard to say because it depends on your C-Suites engagement, buy-in and support for the change. I'd suggest that this is more of a transformational change that will require development of new mindsets and behaviors.

What common problems do you expect to see since you are inside the organization?
Thanks Naomi. PMO Practice Leaders are planning to bring an Agile expert consultant on board as a first step. I personally think the transformation will need to engage not just IT and PMO, but also the Business areas whose objectives are carried out through the projects. A lot of support areas such as Compliance, Risk, Legal, etc will have to adapt to the new style of executing projects. And my apprehension is that people's reluctance to change will be the biggest obstacle to overcome. Definitely exciting times ahead for us.
Network:1277



I have the opportunity to work with Agile from the genesis. I was part of the USA DoD NSF/Agilty Forum where agile and agility was formaly defined and I was part of the group of authors of version 1 and 2 of DSDM. So, the first thing to do is to understand what Agile really is. Agile is not IT or software related, Agile did not start with the Manifesto, Agile is not a process or method. And the worst thing people can do is to talk about Agile something. Agile project manageement that not exists. What exists is project management performed inside an Agile environment. Unfortunatelly Agile (as others) becomes a buzzword and lot of people outside there tried to sell something and jopardize the work of everybody. To understand the history take a look to this: https://www.linkedin.com/pulse/when-agile-...e-title-publish
I wrote a short article for PM Network: http://www.pmnetwork-digital.com/pmnetwork/april_2016?pg=73#pg73.
Hope this helps.
Network:1277



On the other side, each thing you introduce inside an organization will impact the organization as a whole. That is basic to consider the organization from the systemic thinking view. And that is because the business analyst role was created (between other things). What you stated must be a solution to the business problem that must be solved when strategy needs emerge. I have the opportunity to wrote an article that was published by the PMI and the IIBA as best practices. Hope it helps too: https://www.projectmanagement.com/blog-pos...-right-solution
Network:0



Organizations who make the 100% agile decree are often trying to solve problems that are more cultural than procedural. Adopting Agile methodologies won't necessarily solve those problems, but sometimes pressing the reset button on frameworks and methods can provide air cover for the necessary cultural changes that really need to happen. The main things that organizations need to consider include impacts to internal demand management processes, methods for project monitoring and control (i.e.using earned value measurement over top of sprint performance measures such as burn down charts), potential staffing impacts (including the impact of having more "durable teams" vs. purely matrixed project teams), and how well incremental build/deploy strategies can coexist with the organization's software capitalization policies and asset accounting procedures. Most organizations don't think about these types of things until they are well down the road with the superficial changes like buying a bunch of kan-ban boards, hiring and/or training Scrum masters, etc.
Network:613



Here are a few problems you might encounter when making an agile transformation:

* Keeping management and staff in sync - both groups need to be on the same page regarding process, outcomes, timing, etc... It's hard to move away from the mindset of "When will it be done." If Agile teams and management expectations are not in sync, management may think they are failing, when they are really just going through a normal transition.
* Resistance to change
* Skepticism regarding whether or not it will work
* Too much focus on the process, not enough results - while your teams are learning new processes, it may take longer to deliver results. This could be seen by some as failure, as opposed to learning new processes.
* Some work doesn't fit inside iterative processes
* Lack of coaching/training
* Unrealistic expectations of what an Agile transformation will accomplish - it won't solve all of your problems, may create new problems for your organization, and will likely bring problems to light that people would rather avoid, but can't if you really want to transform.
* Role confusion - middle management may not know where they fit in the new organization.
* Lack of appropriate authority - Your product owners have to have knowledge of the product AND the authority to make decisions about the product. If you can't finish sprint planning because the product owner needs to get approval to make a change, you will experience unnecessary delays.

Any type of organizational transformation creates the potential for issues. How you deal with the issues is more important than whether or not you have them. I strongly recommend formal risk management before you get any further into your agile transformation.
Network:219



1. Resistance to change
2. People think it is easy as coin flip ....
3. Product/Solutions management change
4. Roles and responsibilities change...
5. Diluted or Agile But ....
6. Lack of documentation/loss of knowledge
7. Insecurity/Job security..
8. Screwing product/project architecture....
9. Delay to market/delivery...
..etc
Network:208



We are doing this to some degree in our unit. I say "to some degree" because I am not seeing that everyone is on board with the change. This makes it difficult. Some projects are still being completed in a waterfall method while others are agile. One of the reasons for this is due to the lack of training across the board on agile and the benefits of agile.

Programmers who are use to developing solutions on their own and not willing to demonstrate progress until it is perfected is also a challenge. Slowly they are seeing the benefit of giving the stakeholders a look at the progress throughout the project. They are starting to realize the benefit of catching any issues early instead of at the end. They have avoided a total redo of code recently and it was their "ah ha" moment.

Lessons learned at the end of sprints and at the end of the project can really help as well. This allows for an open and honest discussion of what worked and what can be improved upon. But it is important that the improvements happen so the discussion is not wasted. Pick one improvement area and use the feedback to implement a change in the next project. When the benefit of the change is noticed, it will drive the momentum in the right direction.

By the way, not all projects are valid for agile. Some should stay in the waterfall approach. It is important to recognize this and work with the team.
Network:187



I'm always curious what organizations mean when they convert to Agile, as stated here. Are they simply switching their project management structure, are they merely adding some new tools, or are they changing the entire IT culture? Is it only the IT department that's transforming, or is the entire company undergoing a cultural shift?

I ask because the pace of Agile requires a great deal of trust in your people. That's the biggest cultural shift you'll experience, but if you can't get this one, your transformation will fail. If you don't trust your people, you'll have to keep managing them- telling then what to do, when to do it, and how to do it. There are many ways to ruin an Agile transformation, but this is too common: you can't reap the benefits of Agile if your organization continues to manage your developers the same way.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Few things are harder to put up with than the annoyance of a good example."

- Mark Twain

ADVERTISEMENT

Sponsors