One of the most talked about sessions yesterday was delivered by Seth Norburg, Program Management Supervisor at Caterpillar. In his session, Seth walked through their journey 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.
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
Providing flexible service offerings to support the right methodology
But… which methodology was right?
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
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 – sohow 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
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.
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.
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