One of the most talked about sessions at the PMI Symposium ’17 was delivered by Seth Norburg, Program Management Supervisor at Caterpillar. In his session, Seth walked through the Caterpillar Equipment’s Agile Journey and what it was like introducing Agile methodologies to this 100 year old industrial giant.
Mr. Norburg’s team was a central PMO which provided something like consulting support to local teams as they structured and implemented projects.
Caterpillar Equipment’s Agile Journey
They initially had one software team that had 
adopted agile, which was quite successful . When another team asked the central PMO to help them adopt agile as well, it did not go so well. In fact, the words they used were “total failure.” In reviewing the lessons learned, they determined that their failure to implement agile for the second team was because they had:
- Insufficient knowledge of Agile methodologies
- Didn’t know which “agile” methodology to use
- Needed to engage more teams
The next opportunity they had to implement agile was with a team that had rampant scope issues – uncontrolled scope, frequent requirements changes, and constant planning and re-planning cycles.
What they did this time before implementing was to start by reaching out to key stakeholders to identify the team’s current understanding of and attitudes toward agile, so they could plan appropriate training and response strategies. They found that the team thought that:
- If we use agile, we no longer need to meet deadlines
- our project is too big for agile
- we are not executing an it project, so agile is not applicable
- we cannot use agile unless we’re co-located
- We don’t need a plan in agile!
Their early and 
consistent focus was on education and training, which included identifying key points of resistance and trying to address them. Key to this was focusing on the things that are similar between Agile and Waterfall:
- BOTH use iteration and progressive elaboration
- Both have a project leader – both have a charter. The PM / lead facilitates collaboration between team and stakeholders. So, in the end, it’s all about working with people to achieve something.
And, ultimately, 
business sponsors don’t care what we do to deliver, they are just concerned with the results.
As they implemented, they focused on three areas:
- Education and training
- Change Management
- Providing flexible service offerings to support the right methodology
But… which methodology was right?
The Methodology
The Caterpillar team looked at Agile methodologies, and decided that the only methodology that could manage their work at a project, program and portfolio level, and address the needs of waterfall components in a program was SAFe Agile. This approach:
- Is based on Lean/Agile principles
- Supports Scrum, Kansan and XP
- Provides agile portfolio and program management
- Best scalability and adaptability
Hybrid Programs
Of course, it did not make sense to take all teams agile, nor could they ensure that all teams on the same program were agile – so how to manage a hybrid program? Below is an illustration of how they combined Agile and Waterfall projects in the same project –
- They aligned user stories to hit key milestones and dependencies.
- Their general rule was that each sprint sprint had to have some kind of material deliverable, even if that didn’t go into full test
- They then superimposed management milestones
- Added GANTTs of Waterfall based work (legal, infrastructure, etc.)
- Finally, to tie it together, they maintained a detailed Dependency Log, which outlined dependencies between the Agile teams and Waterfall teams – this is KEY to making it all work
Waterfall Remains
They are and plan to continue running in a “hybrid” environment, because 
some projects are more fit for Agile, some for Waterfall. Generally, their approach was that if a project had a very hard scope, it was better for waterfall. If there was any chance or opportunity the scope would or could flex, they would drive it to agile. And they freely admitted that this choice wasn’t always easy, nor always 
right the first time. They found on occasion that they needed to take a Waterfall project Agile, or an Agile project Waterfall.
Tools
As far as tools go, it sounds like this is a work in progress. For the Waterfall components, they use Primavera – this also seems to be where they do the bulk of their financial planning, representing each agile sprint as a 2 week task-bar. There is no automated integration today – it is all manually entered – each and every sprint.
On the Agile side, they use Microsoft Visual Studio Team Services (VSTS). This tool allows teams to enter and manage epics, features, stories and tasks, and also supports Kanban. Though other tools can provide these features, they already had in-house expertise, so decided to go with it.
The down side of these tools is that there is no integration, so there is a lot of post-processing manual number-crunching done to get monthly actuals. Though not stated, I imagine the dependency tracking must have all been manual, and probably a lot of work to maintain and keep up to date.
Lessons Learned
- Education is absolutely key to success in implementing Agile, and it must be a top-down transformation
- Target a successful pilot
- Develop a robust model for education, addressing the needs of team members, scrum masters, product owners and agile coaches
- Transformation is not easy, and requires a total mindset change.
- Understand the benefits of when/where to use agile, waterfall or bot
Ready For Agile?
Contact Us to find out more about our Project and Change Management Services, please email us at PPManswers@KolmeGroup.com.
Be sure to follow us on Twitter, LinkedIn and YouTube and use #KolmeGroup on shared posts!
Book Your Consult