Agile Program Management: The Simplest Lesson

Program Managing a Large-Scale Distributed Agile Program involves several challenges such as team structuring, team induction, training, delivering in short-iterations, team retention and attrition management, system architecture, dependency management, risk management, software testing and automation and so on.  I am writing this post based on a large-scale distributed Agile program we undertook with more than 300 team members across two time zones with involving multiple business critical projects.   The objective of this post is to share experiential knowledge on managing large-scale distributed agile programs and present one of the simplest lessons. This is not it. I will be sharing many more lessons in my subsequent posts.

Program Management involves a higher degree of challenge and complexity as compared to Project Management.  This is because you need to cover multiple projects involving different lifecycles, pricing models, stakeholders, integration requirements, and dependencies. Of course, there are numerous other elements that add to this list.  When we move up from the role of a Project Manager or Scrum Master (in Agile world) to play the role of a Program Manager, we see program management as a role that involves managing more than one project and we stop there. We ignore the need to understand the possibilities of different technologies, stakeholders, regulatory needs, integration challenges and so on.  With over simplification we tend to ignore all the important aspects and eventually it hurts.

So, what is the simplest lesson that we need to know? Here it goes.

“Not all projects are the same. What worked in one project need not apply or work in another project.”

Obviously! We all know that.  However, how many times have we seen program managers as well as experienced project managers establishing a set of rigid rules or expectations on projects or labeling projects based on technology or lifecycle or something else? Here is an example.  Once, a program manager started opining that all agile projects must start doing Test Driven Development from the beginning.  Later, she mandated it.  It did not work because in some projects teams were getting ready to do automated unit tests right before jumping in to TDD. In some other projects teams were finding it tough to implement TDD because those projects involved data migration and the development activities were not mature enough to bring in TDD.

 

Let me present you with another example. Years ago, I came across a program manager who was very fond of three metrics - Schedule Variance, Effort Variance and Defect Density.  She ran program management meetings by looking at these three metrics. She wanted these three for projects of all sorts. It did not work because there were projects following iterative cycle. There were projects following Scrum and there were maintenance projects running in Kanban mode.

 

Well, is this simple lesson specific to Agile Program Management? No. It can be applied in Program Management in general.  Let me give you another example.  I had a Program Manager who used to manage multiple projects and most of them were following Scrum. Some of them were large-scale projects.  She recommended the same style, intensity and schedule of coaching – I mean Agile Coaching, for all Agile projects that would get added under her program no matter what.  She was ignoring the need to understand the needs of the project well and custom fit a coaching solution.  When an Agile Coach suggested this to her, she did not take it on the face of it. It took us some time to sell the idea.

 

“It worked in my previous project. It must work here as well.”  This is a typical Project Management mind block.  Many rookie project manager jump on to their second project with this belief. They bang their heads before they learn the hard lesson. And that is of course the simplest lesson.

 

Be open minded, listen to ideas, think logically and collaborate with your project managers. That is one way to keep remembering this simplest lesson and avoid fundamental mistakes.

 

Do you relate this simplest lesson to your experience or an incident happened at work? Please feel free to discuss. In my next post, I will continue with the next lesson.