The Blurred Line Between Methodology and Framework
Special Guest Post by Shamshad Shaukat, Lead Technical Program Manager, who has worn many hats and is now bootstrapping an AI healthcare startup.
Towards my ambitious goal and ethos of growing together and strength through community, my plan for this newsletter was to bring diverse voices with diverse opinions as well as collaborate on posts with leaders from the tech industry so they can share their knowledge and lived experiences with you, my dear readers, to help us become GREAT at the art of Technical Program Management.
So far, I have done two collaborations:
What is a Technical Program Manager? 🗺️ (Refactoring.fm) (Collaboration with
)Staff Engineer & TPM: A conversation about tech's two most unique IC roles (Collaboration with )
Today, I am excited to share the 3rd guest post/collaboration.
Hope you enjoy it as much as I enjoyed reading the final draft from this extraordinary TPM leader.
🔔 This is a special post available to both FREE and PREMIUM subscribers.
Guest Author - Shamshad Shaukat, Lead Technical Program Manager
A Lead TPM who transitioned from enterprise applications development and implementation to a program management role about twelve years ago. He wore multiple hats filling in for product managers, engineering managers, business intelligence, customer success, and sales operations roles in taking a product from zero to one. Shamshad brings a diverse background of technology domains, product delivery, and operations. Shamshad is currently helping bootstrapping an AI based Health Care startup.
The Blurred Line Between Methodology and Framework
Over the past few years, the role of the TPM (Technical Program Manager) has gained a lot of attention. Just like any new role, the TPM role is still evolving and finding its place in the software development world. It's great to see TPMs authoring books, sharing their knowledge on Medium, Substack, and LinkedIn, forming groups on Discord and Slack, teaching others how to become TPMs, and helping people succeed in their TPM roles.
Anyone who has been in the software industry for a few decades has seen the evolution of the project management role. The traditional waterfall methodology for software development has lost popularity to its younger relation - agile methodology. Built around the need to build complex software ever faster, a whole crop of agile frameworks have risen to meet the call for velocity and more features. Therein lies a conundrum for the modern TPM - when methodology and framework lines blur leading to camps and fans of various frameworks who proclaim one way is better than the other, how does a TPM navigate these tricky waters?
Before we dive into those waters, let's talk about terminology.
What does a methodology and framework mean to you?
A methodology is a set of principles and practices that guide the development of software.
A framework is a more specific implementation of a methodology.
Here are some of the key differences between methodologies and frameworks:
Methodologies are more general. They provide a set of principles and practices, but they don't specify how they should be implemented.
Frameworks are more specific and provide a detailed plan of action.
Methodologies are more flexible. They are designed to be flexible and can be adapted to different projects.
Frameworks are more rigid and are not as easy to adapt.
Methodologies are more comprehensive. They cover all aspects of software development, from planning and design to testing and deployment.
Frameworks may only focus on a specific aspect of software development.
The best methodology and framework for a particular project will depend on the specific needs and requirements of the project.
In the case of TPMs, they are responsible for helping to define and implement the methodology and framework for software development projects. They work with the team to identify the specific needs and requirements of the project, and then they use this information to select the appropriate methodology and framework. The methodology and framework that they select will help to ensure that the project is completed in a consistent, efficient, and successful manner.
Here are some additional thoughts on methodologies and frameworks:
There is no one-size-fits-all methodology or framework. The best approach will vary depending on the specific needs of the project.
It's important to be flexible and adaptable when using a methodology or framework. Things will change during the course of a project, so it's important to be able to adjust your approach as needed.
Remember that methodologies and frameworks are just tools. They can't guarantee success on their own. The key is to use them wisely and to combine them with other best practices to improve your chances of success.
Culture plays an instrumental part in the success of methodologies and frameworks. You cannot simply copy and paste what Apple or Google do to your company. The secret sauce is culture and how the methodologies and frameworks exist within that culture is crucial.
The issue with the methodologies!
Methodologies and frameworks are not programming language syntax.
A methodology or framework is not a set of rules that your code must follow in order to compile or run. Instead, it is a way of organizing and optimizing your work in order to achieve a desired outcome.
Every new methodology or framework is created in response to a failure or shortcoming in a previous approach. Some people learn from these failures and adjust their processes accordingly. Others simply continue to follow the old process, even if it is no longer effective.
In some cases, following a process is the best way to ensure success. However, in software development and other creative fields, there are often no absolutes. The best approach will vary depending on the specific needs of the project.
In the context of software development, a methodology or framework is a tool that can help teams organize and optimize their work. However, it is important to remember that methodologies and frameworks are not a guarantee of success. The key is to use them wisely and to combine them with other best practices.
Here are some additional thoughts on methodologies and frameworks:
Methodologies and frameworks are not a substitute for common sense or experience.
It is important to be flexible and adaptable when using a methodology or framework.
It is also important to remember that methodologies and frameworks are just tools. They can't guarantee success on their own.
Let's put our new aligned understanding of methodology and framework through a test.
Let's talk SAFe
SAFe in a nutshell provides a framework for the planning processes and roles necessary for planning and execution of programs without deviating from the Agile methodology in principle.
SAFe at a glance
SAFe → Scaled Agile Framework for Enterprises that need the best of waterfall and Agile/Scrum methodologies: Higher Productivity with Better PredictabilitySAFe main Rituals
Quarterly Planning → Program Increments (PI)
Quarter = 5 + 1 → 5 Sprints for development and 6th (IP) sprint for Innovation (hackathons) and Planning
Roadmap [Executive → Product Management + Architectures + Engineering] Readouts
PI Objectives (Main/Stretch)
Dependency Handshake
Agile Ceremonies → Sprint Planning, Backlog Grooming, Daily Standups, Sprint Closure (Sprint Demo, Retrospectives), Scrum of Scrums (SoS
Meaningful use of Acceptance Criteria (AC), Definition of Done (DoD) - Link
Reporting → Velocity, Burndown, Scope Drift, Sizing or Story Pointing, Skills Matrix Spider Chart, Harvey Ball Assessment
Roles → Agile Leads, Scrum Masters, Product Owners, Release Train Engineers (RTE). TPM/EPM is not called out as a specific role in SAFe methodology.
What people have been saying about SAFe
It's become common practice to blame the tools or processes used for managing work when things go wrong. However, rarely do we blame the people who are running the processes or selecting the tools.
It came to me as no surprise when even a gifted writer and an excellent TPM also apologetically said something in the praise of SAFe methodology (Real Skills / Data, Opinion, Decisions / Safest thing about SAFe). He is not the only one, he is not the first one, and he is certainly not the last one to have expressed his critique of SAFe making sure that he does not offend anyone.
This post by Jem Kelley describes the PI Planning part and it is indeed how I felt about the first PI planning session that I participated in at Veritas. It was the third PI Planning at Veritas since its launch, and over the next 4-8 quarters, the PI Planning part changed in terms of preparation, ceremonies, participants and participation. We tailored the PL Planning and we made several changes to the agile ceremonies and allowed for the team to pick an agile lead on a sprint/quarter basis as opposed to always having a dedicated scrum master. A “TPM/Project Lead role” was established to help the various engineering leaders for driving the delivery of the goals forf a team/programs.
I still get some kind of reactionary response whenever I mention SAFe in my experience. A common reaction to the PI/Quarterly Planning has been that, "That's not agile anymore" or "That sounds so much like waterfall".
Its SAFe to be Agile
As they say, go slow to go fast!
SAFe is a framework that is constantly being updated and upgraded. My certifications and practice date back to 2019 (SAFe v4.5 vs current SAFe 6.0).
SAFe was perhaps a reaction to agile missing certain bells and whistles (read planning, product roadmap, execution) that were left behind due to the Waterfall to Agile transition. Good product delivery requires a certain level of planning. A “0” to “1” approach may not be the best approach for “1” to “n”.
The solution to shipping code better and faster was not just rooted in the Waterfall methodology. It was largely rooted in bad product development/engineering as well. The agile methodology made it faster, but not fast enough. We realized that we had to bring scale and performance considerations into requirements and design. DevOps was also needed to be made robust with Test automation and adding security (DevSecOps) to the pipeline.
With the rise of machines (generative AI), the landscape is changing rapidly. Not only is faster code development no longer a major concern, but the process of developing products is also changing. There are a plethora of GenAI-enabled/powered tools that can outsmart the best note takers, schedulers, and information aggregators. Based on my limited research and real-life user feedback, Glean is becoming quite a formidable tool for managing work.
In conclusion, it's not the tools or processes that are to blame. We need to focus on training and developing our people so that they can use the right tools and processes effectively.
What is not good about SAFe?
SAFe can be overwhelming
On first look, SAFe can be overwhelming for anyone involved in the product development lifecycle. It has the potential to scare engineers, architects, and product managers. Ceremonies like PI Planning and readouts can bore engineers to death. There is a lot of extra rigor that it brings to the standard agile practice, such as sprint demos, Harvey Ball Assessment, Skills Spider, and the roles of scrum master, Release Train Engineer, and the required coordination.
It is generally believed that managing two scrum teams with a dedicated scrum master will be quite some work, managing a third team will be a total stretch. My brief scan suggests that SAFe does not mention the role of Technical Program Management.
SAFe is not a silver bullet
SAFe is not a silver bullet. It is not a magic potion that will solve all of your product development problems. It is a framework that can help you improve your product development process, but it is up to you to use it effectively.
Don't follow SAFe blindly
Pretty much anything a methodology or framework, including SAFe, advises on practices such as "skill/competency spider", "Harvey Ball Assessment", the refined definitions of SoS, Acceptance Criteria, DoD, should be used as a guard rail and not to be followed as a religious ritual. In other words, adopt it where it helps you in delivering products and features better, faster, and cheaper and make changes if the process or methodology or the framework slows you down.
Be flexible
Not every sprint requires a sprint demo and not every engineer needs to do a sprint demo if his work does not warrant it.
There is no need for a 2+ day of PI Planning readouts (Key Product Management/Roadmap Readouts, PI Objectives, Dependency Handshake). PI Planning serves the KPI spirit quite well, that is, keeping people informed, involved, inspired and interested.
There is no need to force everyone to attend all sessions of a PI Planning, but do educate on the KPI spirit of PI Planning.
Retrospectives are a must, but they do not always need to happen quite the way recommended by the methodology.
An assertive TPM can exercise judgment.
There are certain things (for example, retrospective or even daily standups) that a UX/UI engineer, or a product manager, or an architect, and of course an engineer may not/never like to be a part of regardless of the methodology.
Final Word - Use what works for you
The most important thing is to use what works for you and your team that aligns with your culture. Culture is everything and as TPMs we must find what works for the culture we operate in.
Don't be afraid to adapt SAFe to fit your specific needs and culture. If something isn't working, don't be afraid to change it. The goal is to find a process that helps you deliver high-quality products on time and within budget.
What did you think about this guest post?
Would you like to collaborate with me on a guest post? Send me an email at aadilmaan@gmail.com with your proposal.
If you enjoy and love reading what I write, perhaps you know someone who could also enjoy and love reading these essays and dispatches. Share this with your friends and colleagues and lets grow together. 🙏 ☺️ ❤️
You can suggest topics or questions for me to write about in the future. It could be something you are curious about or maybe something you're struggling with right now.
I seriously love the way you think about these frameworks. It’s refreshing
Also, new to the TPM space, and as a DE consultant at a data & analytics firm (Aimpoint Digital), that’s a role my colleagues and I tend to play. Excited to learn more from you!