Key Takeaways
As a manager, you should understand what both a Software Development Lifecycle (SDLC) and a Development Process Framework are.
Agile itself is not a system — it’s a set of principles that require an actual framework (like Scrum, Kanban, or SAFe) to put those principles into structured practice.
Most modern frameworks and SDLCs provide mechanisms to create accountability, transparency, and continuous improvement.
You should ensure that these frameworks are thoughtfully selected, documented, and followed.
Familiarize yourself with the frameworks your technical leadership have chosen and understand which metrics and reports you need to support informed decision-making and ask that your technical leadership to provide them
Balance your involvement carefully—engage where your presence adds value but avoid unnecessary micromanagement
An example of operational management visibility in software development shops is provided using the Scrum Agile Framework—plus a bonus example of scaling up Scrum by layering some elements of the Scaled Agile Framework
Overview
The world of software development isn’t just fast—it’s volatile. To be an effective manager that creates maximum value in this realm, you must counterbalance these chaotic forces.
You’ve likely heard countless buzzwords or overly technical explanations about managing software teams—often tied to Agile development and promising endless adaptability and continuous improvement. But as a busy manager, you don’t need vague idealism and whimsy; you need the facts about how this actually works.
To sharpen your understanding, the sections below explain two core concepts: Software Development Lifecycles and Development Process Frameworks. These create the structure that informs you about what should be happening operationally.
The goal isn’t to make you a technical decision-maker, but to clarify what decisions you should expect from technical leaders — and what justifications, documentation, and reports you should be receiving.
The most important action items for you once you grasp these two sections:
Require your technical leadership to officially decide–and document their justification for choosing–both a software development lifecycle and a development process framework
Study the chosen systems and ensure that you are receiving that data and reports on key performance indicators that the system says you should
After these sections, you will be provided with an example of what operations you could expect to see in place after technical leadership decides on a software development lifecycle and process framework and implements them.
The Software Development Life Cycle (SDLC) Model
An SDLC defines what phases are involved in creating a system or individual piece of software. But it is important to understand that it does not determine how these phases will be broken down into individual tasks–that’s the job of the Development Process Framework, which we’ll cover next.
For example, a given SDLC system might define six or seven phases of development. Common phases you’ll see in most approaches are planning, requirements analysis, coding, testing, deployment and maintenance. But the SDLC is not necessarily saying that planning should happen at one frequency or another, or how development tasks should be broken down, what should be happening in the testing phase, or how maintenance is scheduled or managed.
There are many SDLC models, each with strengths and weaknesses. But confusion often arises around “Agile” and SDLCs. Let’s clarify:
Agile is not a single system or fixed method. It’s a set of twelve guiding principles described in the Agile Manifesto which promote flexibility, adaptability, and continuous iterative development. Different groups have then built unique processes and frameworks that each espouse alignment with Agile model principles and Agile’s overall iterative nature.
So, when you hear “a term like Agile Software Development Lifecycle” (Agile SDLC or Agile ADLC), it simply refers to an SDLC some independent group or agency created whose steps are shaped by Agile values.
What is most important for you as a manager is not to critique or overly-involve yourself in your technical leadership’s SDLC decision–your place is not to question their technical chops. They may favor more traditional methods or instead elect an SDLC that is more consistent with Agile methodologies. But you set expectations for a well-documented decision processes, as well as accountability and willingness to evolve if the choice does not bring the desired results.
Development Process Frameworks
Development Process Frameworks define the organized set of activities used to carry out the phases outlined in the SDLC. They determine how work is broken down, sequenced, and managed to deliver software effectively.
While older frameworks like the Waterfall model are still sometimes used, most software organizations today rely on Agile-based frameworks, which are better suited to the speed and changeability of the modern technology landscape.
Just like there are various Agile SDLCs, Agile-based frameworks come in many forms and espouse Agile principles. They each offer a distinct approach to Agile-based processes, project management and Agile team operations.
Every framework has its pros and cons and typically excels with certain types or sizes of projects–often depending on the complexity and scale involved. In some cases, it can even make sense to combine frameworks into hybrid models, blending methods to best fit the specific needs of a project or organization.
As with SDLC selection, you should expect your technical leadership to thoughtfully choose a process framework and clearly document the reasoning behind that choice.
Once selected, it’s your responsibility as a manager to understand the framework’s phases, deliverables, and interactions so you can determine which non-technical stakeholders should be involved and when.
At Scorpion Five Technologies, we’ve found the Scrum Agile framework works well for most projects and can scale effectively when elements of the Scaled Agile Framework (SAFe) are layered on.
However, Scrum is just one example. Every process framework and Agile SDLC aims to create structure, accountability, foster continuous feedback and improvement, and provide stakeholder visibility–some are just more effective than others, and their key differences make them better suited to developing one class of software versus another.
Are you a small business or SaaS startup that needs specialized development help?
Note: there are also practices which can be layered onto both the SDLC and process framework. For example, DevOps practices can be added to provide automations like Continuous Integration and Continuous Deliver or Deployment (CI-CD). This is also true of practices that support customer satisfaction, like quality assurance tasks that take place during testing and review phases.
An Example of Effective Management Using the Scrum Agile Framework
The sections below provide a basic understanding of the Agile practices in the Scrum framework, focusing specifically on what a manager needs to know to gain clear visibility into development team activities and progress.
I will also explain how selected elements of the Scaled Agile Framework (SAFe) can be layered onto Scrum to scale processes effectively for larger, more complex initiatives.
The Scrum Agile SDLC and Framework in Action
Scrum organizes work using three core units: the product backlog, the sprint backlog, and increments. These define what needs to be built, what will be tackled in the near term, and what working software has been delivered respectively.
Progress is governed by a series of structured team events called “ceremonies,” which manage how work is planned, executed, reviewed, and refined.
Scrum Ceremonies
Scrum ceremonies organize work into time blocks and provide continuous refinement of both task lists and work processes–each is explained below.
Depending on which Agile SDLC is in use, its phases are addressed during Scrum ceremonies to keep development and planning aligned. For example, in a typical six-phase Agile SDLC, the planning phase takes place during both the Backlog Refinement and Sprint Planning ceremonies.
Observe that these ceremonies happen on a recurring basis, so the plan is routinely updated as circumstances change. For example, things like customer feedback and market changes will be considered on a regular basis–this is one of many things the Scrum process framework does to be consistent with Agile principles.
Technical leadership should attend all ceremonies, but non-technical leaders must balance their involvement — too little risks losing accountability; too much leads to micromanagement. As a manager, focus on the meetings that provide the detail you need for informed decisions, and ask open, thoughtful questions. The sections below will guide you on striking this balance.
Note: all development work takes place during a “Sprint”. All other ceremonies take place in between Sprints. More detail to come in each section below.
Are you a large business or government organization who needs help with complex systems?
Backlog Refinement
Backlog refinement focuses on reviewing and updating the product backlog — the prioritized list of tasks needed to deliver working software.
In this ceremony, Agile teams, technical leads, and product owners collaborate to prioritize, reorder, clarify, or remove tasks based on evolving requirements, customer feedback, or lessons learned.
While backlog refinement is not formally listed as a Scrum ceremony (Scrum assumes an existing backlog), it is implied in the Agile Manifesto. In practice I’ve found that it’s a vital ceremony for keeping development work aligned, and it’s indispensable.
This is also when developers provide time estimates using “story points.” Story Points are a subject all their own to be covered in a future post—but do note that story points are not the same thing as days, they are measurement of time versus relative complexity.
Metrics will be covered a little further on, but know that the accuracy of story point estimations is measurable, and improving them should be a focused part of ongoing process improvements.
The ceremony aligns the product owner, technical leads, and development teams around project goals and priorities.
Non-technical managers generally don’t need to attend backlog refinement, but should ensure the meeting happens regularly and request periodic briefs about the backlog’s state. The contents and the ordering of the backlog provide a snapshot of the current technical roadmap, and you should maintain high-level situational awareness around this.
Sprint Planning and Sprint Execution
Scrum Agile sprints are fixed time boxes, usually 2–4 weeks, where the team focuses on a set of selected tasks.
These tasks, drawn from the top of the refined Backlog, are chosen in such a ways as to deliver a completely functional piece of new or updated software by the sprint’s end. Strict Agile practices aim for a new working release at the end of each sprint.
In practice, what normally works best is making sure all cards can be completed within the sprint, and that each delivers some discreet feature. Therefore in the real world, a sprint typically delivers a bundle of new features and respects the idea that accurate, finish-line-focused estimation combined with accurate release planning are what matters most. But it may take more than one sprint to create a new releasable version of software.
I contend that you should never push a new version release to production, just because some management framework timeframe has elapsed. It needs to be because the agreed-upon requirements that define the new version have been met. But I digress.
There’s usually a short gap (2–3 days) between sprints when all other ceremonies, except the daily standup, take place.
Sprint planning involves calculating each team member’s availability and applying a focus factor. Like story points, focus factor can warrant its own article and has associated metrics that facilitate constant process improvement.
The basic idea is that no developer can spend one-hundred-percent of their time writing code. They have meetings and calls, but are also slower or faster at different times of day and in different environments.
The team then pulls in the right number of stories into a sprint backlog to match the Agile team’s focus-adjusted capacity. During sprint execution, tasks move through statuses like To Do, In Progress, In Review, and Done, with the team tracking their progress.
Sprint Planning aligns product owners, technical leads, and developers on near-term work, but non-technical managers usually gain little from attending. The Sprint Planning ceremony mostly entails discussing “in the weeds” technical details and specific developer task assignments. The collected sprint metrics covered later will instead provide the sprint details you need.
See how we’ve helped others manage complex projects.
Daily Scrum or Standup
Daily Standup/Scrum is a short (15 minutes typically), daily meeting attended by individual Scrum teams and conducted by a Scrum Master. Typically, each card in a Sprint is show own a board that has columns representing statuses like “In Progress,” an so-on. One by one, the Scrum Master calls out cards and asks the assigned developer to provide a status.
Scrum Master is a role assigned to a member of the Agile team, but should not be though of as a position. Ideally, the role is rotated among junior to mid-level developers to help them build leadership experience. Furthermore, with established processes and adherence to the framework, these duties should only span a few hours per week.
The Standup ceremony fosters team accountability and continuous collaboration and constant communication. Standup also developers a chance to surface blockers or offer each other help.
Non-technical managers should not attend daily standups, nor should any technical leadership that is not explicitly a member of the Agile team. Instead, rely on sprint reviews and collected sprint metrics to stay informed about team progress and performance. More on those below.
Sprint Review
Sprint Review is a ceremony where the development team presents what they accomplished during the sprint, typically through demos and brief explanations.
The team also shares sprint performance metrics, providing transparency on what was completed versus what was planned.
Attendees should include the product owner, technical leads, and the Scrum Master, as each played a role in the team’s performance.
Non-technical managers should attend when noteworthy demos or key updates are presented — visible support reinforces accountability and team morale. This is also a great ceremony to include cross functional teams that might be awaiting the outputs of an internal development team or dedicated software development teams provided by a vendor.
The review provides critical insights into delivery progress and helps stakeholders stay aligned on upcoming priorities and challenges.
Sprint Retrospective
The Sprint Retrospective is a team-only ceremony focused on process improvement, where developers reflect on what went well, what didn’t, and how they can improve in the next sprint.
The team documents identified issues and proposed solutions, usually in a shared space like a team wiki, alongside sprint metrics.
This meeting should be considered sacrosanct. It needs the full support of leadership and should not include external stakeholders unless explicitly invited. Instead, leadership should ensure retrospectives are happening consistently and should periodically inspect the resulting documentation and metrics to stay informed on team challenges and improvements.
Scrum Agile Metrics
Throughout each sprint, the team generates a variety of metrics that can help assess performance, progress, and process efficiency. These metrics, when collected across longer periods and across teams, also provide the foundation for informed decisions at higher management levels.
As a manager, you don’t need to internalize every metric, but you should know which ones matter for your decision-making and ensure technical leadership captures them.
For example, regularly missing sprint commitments could indicate consistent underestimation at Backlog Refinement, shifting priorities during Sprints, or some other workflow issue–only the data can reveal which objectively.
Consider requesting that your technical leadership establishes and documents which metrics from your chosen Process Framework are tracked in Sprints, justify any that are not, and explain what insight they provide in the context of your unique organization.
Scrum Agile Reporting
The data produced by Scrum can and should be turned into information that provides insights for informed decision making. This reporting can be provided through ceremonies but is ideally also available for asynchronous review via shared dashboards or a company wiki.
To determine who should report to you, start by listing everyone whose performance would improve by being accountable to you. Remove anyone already reporting to your direct reports, but make sure those reports are still flowing. For those who remain, require regular performance summaries drawn from Sprint data.
The timing and format of reports will vary depending on your teams and products, but in some cases, it may be valuable to create your own leadership-level ceremony. For example, gather all product owners after sprint reviews for a brief leadership standup, where they summarize backlog status, team performance, and collected metrics across teams.
For smaller orgs, read this post to learn more about specific software development considerations:
Layering SAFe onto Scrum to Scale Up
The Scaled Agile Framework (SAFe) is designed to coordinate very large, complex software projects while still maintaining an iterative approach. But unless your program is pretty large, it’s usually overkill. However, two key SAFe constructs—Epics and Initiatives—layer onto Scrum very well and provide just enough scaling to make it effective for all but the very largest projects. Tools like Jira allow you to create these types of tasking structures right out of the box as well.
Epics represent major efforts that span several weeks and consist of many related stories; their purpose being the delivery of major features. Initiatives span months and are composed of multiple Epics, often defining major product releases or system-level changes.
By adding these larger timeboxes, you can retain Scrum’s core ceremonies while introducing quarterly or annual planning layers that help align teams, focus on long-term goals, and generate higher-level metrics for leadership reporting.
Conclusion
As a manager, your mission is to make informed decisions that drive the business toward maximum success — and that requires the right data, clear accountability, and continuous process improvement.
To get there, ensure that a logical framework has been thoughtfully selected and that the decision is documented. Also ensure that your software development teams adhere to it, and that deviations or changes are well-documented and justified.
Educate yourself on the chosen framework, understand what reports and metrics should reach you, and reinforce a culture where teams report progress openly and consistently.
Finally, prioritize frameworks and practices that promote team accountability, measurable outcomes, and process evolution—because in software development, the ability to adapt, learn, and improve is what turns chaos into competitive advantage.
Frequently Asked Questions (FAQ)
What is the difference between an SDLC and a process framework?
The SDLC defines the high-level phases for building software (like planning, development, testing), while the process framework (like Scrum or Kanban) defines how teams organize and carry out the project management and development work within those phases.
Is Agile itself a system or framework?
No—Agile is a set of twelve guiding principles outlined in the Agile Manifesto that prescribes and iterative approach to software development. To apply these iterative development principles in practice, teams need to adopt a framework, such as Scrum, Kanban, or SAFe, which structures how Agile values are implemented in daily work.
Do non-technical leaders need to attend every Agile ceremony?
No—non-technical leaders should only attend ceremonies where their presence adds value, such as sprint reviews or leadership-level briefings. Trust technical teams to handle detailed Scrum events like daily standups and backlog refinement.
Which Agile metrics matter most for managers?
It depends on the chosen Agile development framework, but key metrics include sprint commitments vs. completions, velocity, defect rates, and blockers. You should work with technical leadership to decide which metrics provide meaningful insight for your role.
