Is it Agile? Recently, while working inside a PMO Office that was not my own creation, I was able to experience that age old question with a renewed interest. The layout was a larger shop with dozens of PM’s and multiple tiers of management. Most would engage in the importance of Agile design and processes in a framework and culture that was clearly not. It had me wondering two things:
- If we are to be Agile, what requirements would an organization have to fill in order for it to be true?Â
- Why do we feel being Agile is important?
Preface of personal opinion. To be up front with my own personal (insert large number) years experience in various frameworks and styles, not withstanding working on a masters in Project Management, I do not think Agile is a great solution for mid-west businesses. FDD (Feature Driven Design) or SAFe (Scaled Agile Framework) is probably the most effective for leadership, governance, and implementation with varied teams and experiences. Especially as clear objectives, timelines, and milestones tend to be known from the onset as it’s how the project was green-light from the start.
Let’s take a look at the 4 pillars and 12 principles of Agile.  If you’re following some other definition, you can call your processes anything you like, but not Agile.
Four Pillars of Agile:
- Individuals and interactions over processes and tools.
- Working software (or objective success) over comprehensive documentation.
- Customer collaboration (dialog) over contract negotiation (written direction).
- Responding to change over following a plan.
5 Agile Supporting Requirements (You cannot pick and choose)
Let’s start with the basic requirements needed to lay the groundwork for these core values. Notice that many of these may fall into best practices adjacent, which is why I believe Agile is incorrectly promoted in many organizations. Best practice in PM is a different conversation.
Requirement 1: Core values MUST be adopted organization wide, across all departments, not just a culture of the Project / Program Management team.
Why? A project manager / team is a facilitator in the lifecycle of a change management event. If any human segment of that event, especially stakeholders, do not follow these guiding principles, then it would be impossible and irresponsible for a project lead to adhere to a different method in a lifecycle.  A project team’s greatest flexibility will always be the least flexible stakeholder.
Requirement 2: Training in Agile project processes, frameworks, and tools (especially communication) MUST be companywide.
Why? This cannot be limited to just the PM group. EVERY stakeholder needs to be both familiar, and compliant, with the processes and procedures a company has agreed upon in the Project Management office. I’m not saying this is an easy sell, but a required buy-in on the above list from the Executive team down to implementation resources.
Requirement 3: Project management processes, procedures, and tools MUST be universal across all departments.Â
Why? Customization is always allowed as different departments and stakeholders have slightly different needs. However, especially in larger shops, “project silos” are where good projects go to die. If the Executive team is using Power Point, IT is using Jira, and Operations is relying on that one outstanding person to always sit in on meetings, the Babylon pillars will result in overbudget, miscommunication, and out of schedule. Cross-departmental agility MUST have a common language. When the tools and processes are universal, resources can move and flex from a FinTech project to a Logistics project and contribute on Day 1 because the “how” of the work hasn’t changed—only the “what.”
Requirement 4: If any part of a project does not fit Agile, or has aspects of hybrid, or Kanban needs, your project CANNOT be run Agile in method.
Why? It is an assured failure to try to shift between project methodology midflight. If your procurement process requires a 6-month fixed-bid contract or your hardware delivery has a hard 12-week lead time with zero flexibility, trying to run the software side in two-week sprints is an exercise in poor leadership.
Agile relies (some would say demands) on the ability to pivot. If any segment of the project—be it a vendor, a regulatory requirement, or a physical dependency—is a “fixed-point,” then your project plan is constrained. In these cases be honest -a mandate in PM best practices- rather than simulate an Agile form.
Requirement 5: Agile leadership MUST be available, and an internal resource, at all times including hands-on project experience, within the last 3 years.
Why? Agile, even effective modern Project Management, isn’t something you can teach from a textbook or well written Wiki page in Confluence. The landscape of tools, automation, orchestration, CI/CD, testing, JIT, and virtual deployments change every six months and are unique to the people and personalities in each company, even if you may share a similar industry.
If leadership hasn’t been “hands-on” recently, they won’t understand the technical and resource debts accumulating when you rush a sprint, or why a team is asking for a refactoring. You need a leader who has felt the consequences of a failed internal deployment and the pressure of a shifting backlog. Without that recent scar tissue, leadership will always default to “Command and Control” the second things reach the client or CFO desk.
In retrospect. Promoting a culture of flexibility and resilience with Agile adjacent frameworks, tools, and processes will not make a business Agile in function. Agile is a management, not just PM, culture based on the four core values listed above (let alone addressing it’s 12 principals) adopted, and adhered to, throughout an organization. I also feel that most Agile tenements are also excellent culture adjacent functions of any high-performance project management team. Being flexible when needed. Having dedicated process and communication expectations. Ensuring domain expertise in project management and core business functions. All these things sound like Agile concepts, but technically are not. For instance: Silo’s can be extremely important and valuable in many scenarios. Having different project management styles for different projects is not always a bad idea. Stylized communications for specific stakeholders can sometimes be a great asset in ensuring success and transparency. However, indicating that you are an Agile functioning shop, requires all of the above. Teaching otherwise I feel can be a detriment for those learning PM and invariably moving on to other opportunities with incorrect information that gets further propagated.
