top of page
Writer's pictureRick Pollick

Designing Your Own Delivery Process

Updated: 5 days ago

Breaking Free from Prescriptive Agile: A Case for Designing Your Own Delivery Process


Agile is everywhere. It’s become a buzzword that infiltrates almost every team meeting, strategy session, or project kick-off across industries. But somewhere along the way, "being Agile" has morphed into a rigid adherence to specific frameworks like Scrum, SAFe (Scaled Agile Framework), or Kanban. People often talk about these methodologies like they’re sacred texts, leaving little room for adapting processes to meet the specific needs of a team or project.

However, Agile doesn’t have to be prescriptive. In fact, it shouldn’t be. The whole point of Agile is to be, well, agile — flexible, responsive, and adaptable.



In this post, we’ll explore why the best way to deliver value isn’t through strict adherence to any one Agile methodology. Instead, it’s about designing processes that align with the specific needs and challenges of your team and your work. Let’s also dive into how the Agile Manifesto principles still ring true today, despite the seeming antiquity of its delivery, and how process design should be driven by a reduction in overhead, increased communication, and overall simplification.


A Brief Look at the Agile Manifesto

Before we talk about why Agile doesn’t have to be prescriptive, let’s revisit the source: the Agile Manifesto. Written in 2001 by 17 software developers who were fed up with heavyweight development processes, the manifesto (while dated) laid down a still-relevant list of 12 principles and four key values:

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan


Notice a trend? The emphasis is on adaptability, collaboration, and reducing unnecessary steps. The manifesto wasn't trying to tell teams how to do Agile — it was outlining principles to guide decision-making and prioritize what’s truly important in delivering value to customers.


Fast forward to today, and ironically, many Agile practices have become rigid and prescriptive. Rather than shaping a process around a team’s needs, we’re often molding our teams to fit a pre-defined process, like forcing a square peg into a round hole.



Why Prescriptive Agile Misses the Point

One Size Doesn't Fit All

The problem with prescriptive Agile frameworks like Scrum or SAFe is that they often attempt to provide a “one size fits all” solution. These methodologies were built to solve specific problems, in particular contexts, and while they may work perfectly for one organization, they might not be the best solution for another.


Take Scrum, for example. Scrum prescribes a rigid set of roles (Product Owner, Scrum Master, Development Team), ceremonies (daily stand-ups, sprint planning, sprint review, etc.), and artifacts (sprint backlog, product backlog). This can work great for a team with a well-defined product backlog and the need for incremental, time-boxed progress. But what if your team handles operations or support, where work is more continuous and less predictable? For these teams, Kanban’s flow-based system might be more effective than the time-boxed sprints of Scrum.


However, even Kanban can be limiting. What if you’re a team that’s cross-functional, handling both ongoing support issues and new feature development? Do you need a hybrid process? Can you draw from both Scrum and Kanban, and pick what works? Absolutely.


Frameworks Can Be Heavy on Overhead

By adhering too rigidly to an Agile framework, teams can inadvertently introduce overhead that hampers progress instead of accelerating it. For example, SAFe is designed to scale Agile practices across large enterprises, but the framework’s complexity can lead to a significant amount of time being devoted to ceremonies, planning, and alignment rather than actual delivery.


Consider an example of a telecommunications enterprise that tried implementing SAFe across all departments. This required syncing across multiple layers of management, aligning release trains, and planning increments. It quickly became apparent that more time was spent organizing the process than delivering value. The result? They eventually shifted to a lighter, more customized Agile process tailored to each team’s needs. The overhead was slashed, and delivery became more efficient.


Design Your Own Agile Process: Principles Over Frameworks

The beauty of Agile is that it encourages you to be pragmatic. Don’t start with a framework and work backward — start by analyzing the needs of your team and your project, and then craft a process around those requirements. Here are some guiding principles to keep in mind:


1. Focus on Communication & Collaboration

At the heart of Agile is the idea of people over processes. Regardless of the approach you take, your team should have open lines of communication and opportunities for collaboration. For instance, if daily stand-ups are not providing value because they’re too formulaic, consider switching to fewer, more meaningful syncs. Or perhaps opt for asynchronous status updates if that better fits your team’s workflow.


Real-world example:

At UPMC Enterprises, teams working on healthcare software solutions found that their backlog grooming sessions were taking up too much time and not providing enough actionable outcomes. The teams initially spent hours refining every release user story, which slowed down the process and made prioritization difficult.


To address this, they adopted a more focused approach. Rather than grooming the entire release backlog in each session, they introduced shorter, more frequent sessions with a tighter scope, focusing on only the most pressing tasks for the next sprint. These shorter sessions were preceded by team-lead reviews to address any pressing technical concerns or dependencies before larger team reviews. This change allowed the team to quickly refine the top priority items and adjust as new information emerged. As a result, the team maintained a more streamlined workflow, enabling quicker decision-making and more efficient delivery.


2. Adapt Processes to Team Dynamics & Work Types

Think about the types of work your team handles. If you’re working on long-term projects with complex deliverables, a more structured approach with detailed sprint planning (like Scrum) may be beneficial. But if your team deals with incoming requests that vary in size and urgency, you might need a more flexible approach, like Kanban, or even a custom workflow that mixes elements of both.


Example:

A financial services company with both DevOps and development teams adopted a mixed approach. DevOps ran Kanban to handle unpredictable support work, while the development team ran Scrum to iterate on new product features. Both teams shared a weekly retrospective to surface any interdependencies and align on common goals. This blended approach allowed each team to work efficiently while maintaining cross-team collaboration.


3. Eliminate Unnecessary Overhead

Your process should always strive to remove unnecessary steps, documentation, and bureaucracy that don’t add value. If a particular ceremony, tool, or report isn’t driving progress or improving communication, consider cutting it or simplifying it.


A word on automation: Automation and technology can significantly reduce overhead by handling repetitive, manual tasks that otherwise slow down processes. By integrating tools for continuous integration and deployment (CI/CD), automated testing, or workflow automation (like Jira automations or ServiceNow), teams can eliminate time-consuming handoffs, reduce errors, and ensure that tasks move seamlessly through each phase of development. This allows teams to focus on high-value activities, such as coding, problem-solving, and collaboration, rather than on status updates, manual data entry, or administrative work, ultimately increasing efficiency and accelerating delivery.



Example:

A healthcare tech startup realized they were spending too much time on user story refinement and backlog grooming, while the team’s needs were fairly straightforward. By shifting from story points to simpler t-shirt sizing and scheduling shorter grooming sessions, they freed up more time for actual development and testing, without sacrificing product quality.


Keep Agile Manifesto Principles at the Core

Though the Agile Manifesto may feel a bit dated, its principles are timeless: deliver valuable software quickly, embrace change, and prioritize customer collaboration. These principles, paired with a reduction in overhead, increased communication, and process simplification, should drive how you design your Agile process.


The Agile Manifesto doesn’t just lay out values — it also outlines 12 guiding principles that can shape how you design and refine your Agile process. Here are a few of those principles, and how they can inspire you to build an effective process for your team:


  • “Welcome changing requirements, even late in development.”

    Embrace flexibility in your process. Agile thrives on being able to adapt quickly when new priorities or information emerge, even mid-sprint. Designing a process that allows for change, rather than rigidly sticking to a predetermined plan, is key to staying responsive and keeping stakeholders happy.


  • “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

    Frequent delivery ensures that you’re providing continuous value to your customers or stakeholders. Consider breaking down work into smaller increments that can be released and tested sooner. This way, you can gather feedback, iterate, and keep improving without waiting for lengthy release cycles.


  • “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

    Your Agile process should empower the team, not micromanage them. Trust your team members to be self-organizing, give them clear goals, and create a supportive environment. Minimizing unnecessary bureaucracy or overly detailed instructions will enable motivated teams to take ownership of their work.


  • “Continuous attention to technical excellence and good design enhances agility.”

    It’s not just about speed — it’s about quality. Building in processes for peer reviews, automated testing, or continuous integration can help improve technical excellence, making it easier for your team to respond to change and deliver high-quality software.


Your Agile approach should help you work smarter, not just fit a predefined mold. In practice, this means constantly evaluating your process, seeking feedback from your team, and adapting as needed. It’s not about “doing Agile right” according to a strict methodology — it’s about delivering value efficiently and effectively, in a way that works best for your unique context.


Team Composition: A Key Factor in Process Design

When considering how to design or customize your Agile process, it’s important to remember that the process doesn't just exist in a vacuum — it lives and breathes with the people on your team. The makeup of your team directly influences how your process should be designed, and adapting your Agile approach based on team composition can often make or break your effectiveness.


Skill Sets, Roles, and Responsibilities

One of the great strengths of Agile is the idea of cross-functional teams, where all the skills necessary to deliver value are present within the team. However, the exact roles and responsibilities within those teams can vary dramatically, and your Agile process needs to accommodate this.


For example, if you have a team composed largely of specialists (e.g., dedicated front-end developers, back-end developers, and QA engineers), you might need a process with clearer handoffs and more formal ceremonies to ensure that all work is well-coordinated. A more structured, step-by-step approach might be helpful to keep specialists aligned and prevent siloed work.


Conversely, if your team members are more generalized (e.g., full-stack engineers who can handle different aspects of the project), you might find that strict, role-based processes are less effective. A flatter structure with more flexible roles might allow everyone to better collaborate, swarm on tasks, and collectively own the outcome.


Example:

A global e-commerce platform found that their teams were highly specialized, with dedicated UI designers, front-end developers, back-end developers, and QA engineers. They initially tried a Scrum process but found that the rigid ceremonies often caused bottlenecks between handoffs. After experimenting, they adopted a flow-based approach similar to Kanban, where work was tracked more closely in each stage of development, and collaboration was fostered between specific roles as work moved through the process. This allowed for smoother transitions between specialists and shorter cycle times.


Adapting Team Size

The size of your team can also affect how your Agile process is structured. A smaller team (say 3-5 people) may thrive on a lightweight process with minimal ceremonies and documentation. A daily stand-up, a quick retro every week or two, and a clear backlog may be all you need to keep things moving. A larger team (more than 8 or 9 people), on the other hand, may struggle with such a lean approach. In larger teams, more formal communication patterns and ceremonies are often needed to keep everyone aligned and ensure that work doesn’t fall through the cracks.


Scaling frameworks like Scrum@Scale or SAFe try to address the challenges of larger teams by creating structures that break teams down into smaller sub-teams, with ceremonies that allow for cross-team alignment. However, these frameworks aren't always necessary. Sometimes simply splitting a large team into smaller, more autonomous sub-teams — each with its own specialized process — is a more practical solution. Each sub-team can then tailor its Agile approach based on its specific work, and you can establish minimal touchpoints for cross-team collaboration.


Real-world example:

A cloud services provider initially had teams of 10-12 developers all working on a single large product using a standard Scrum approach. The daily stand-ups became unwieldy, and it was difficult to keep everyone on the same page. They decided to split the large team into two smaller, autonomous squads — one focused on customer-facing features, the other on backend systems and infrastructure. The two squads operated independently with their own tailored Agile processes (one Scrum-based, one Kanban-based), and only met weekly to align on shared goals. This change allowed both teams to work more efficiently and with greater focus.


Changing Team Dynamics Over Time

Teams are dynamic; people come and go, projects change, and skill sets evolve. Your Agile process needs to be just as dynamic, adjusting to meet the current state of the team. Perhaps you have a newly formed team with limited Agile experience — starting with a more prescriptive framework like Scrum can help them learn the basics of Agile ceremonies and iterative development. Over time, as the team matures, you can introduce more flexibility and begin to customize the process to match their working style.


Alternatively, if your team is made up of seasoned Agile practitioners, enforcing a rigid framework might stifle creativity and reduce productivity. Instead, an experienced team may benefit from the freedom to define their own ceremonies and workflows, experiment with new approaches, and find what works best for them.


Real-world example:

An insurance technology company had a team that was very new to Agile. Initially, they followed Scrum by the book, with strict adherence to all ceremonies, roles, and time-boxes. After a few months, the team grew comfortable with the basics of Agile and started to self-organize. They found that reducing the sprint planning meetings and instead using a continuous backlog grooming approach worked better for them. They also shortened retrospectives to focus on quick wins rather than in-depth analysis. This evolution allowed the team to become more efficient and engaged, using just the right amount of process to get the job done.


Building Processes to Support Team Composition

Ultimately, your Agile process should support your team, not the other way around. If your team composition changes — whether through new hires, evolving skill sets, or changing work dynamics — then your process needs to change too. By focusing on principles over prescriptions, you give your team the flexibility to tailor their process in a way that leverages their strengths, meets their needs, and aligns with the type of work they’re doing.


Designing your Agile process around your team is an ongoing effort. It requires regular reflection, open communication, and a willingness to adapt. Remember, the goal is to enable your team to deliver value, efficiently and effectively, and sometimes that means evolving your process alongside your team composition. That’s what true agility is all about.



Rolling Your Own Process: Building an Agile Approach That Actually Works

So, if following a pre-packaged Agile framework doesn’t always deliver the results you need, how do you go about designing your own Agile process? This concept of “rolling your own” process is about cherry-picking elements that work for your team, discarding those that don’t, and continuously refining your approach as you learn what’s most effective. It’s an iterative journey, much like Agile itself. And it’s the key to unleashing a truly efficient and effective delivery process.



Here’s a guide on how to build a custom Agile approach for your team and some insights into why this approach can significantly boost your team's efficiency and effectiveness.


Step 1: Understand Your Team and Work Environment

The first step in designing your own process is to deeply understand your team’s needs, strengths, and context. Here are some questions to get started:


What type of work do you do? Is it project-based, support-based, or a blend of both?

How experienced is your team with Agile principles and practices?


Are there external stakeholders or departments you need to align with regularly?

What’s your current pain point? Where do you see inefficiencies or bottlenecks?

Understanding your team’s dynamics, the nature of your work, and the needs of your stakeholders is critical for building a process that supports your specific goals. There’s no universal answer here — a process that works for a DevOps team might not work for a product development team, and vice versa.


Tip:

A B2B SaaS company dealing with product releases and ongoing bug fixes used to follow Scrum but struggled with continuous interruptions from customer requests. They identified the need for more flexibility and transitioned to a process that blended Scrum for feature development and Kanban for addressing support requests. This hybrid model allowed them to respond quickly to issues while maintaining structured progress on new product features.



Step 2: Pick and Choose Elements That Work

Once you understand your team's context, start by adopting practices from various Agile frameworks that fit your needs. You don’t have to be a Scrum team or a Kanban team — you can be your own kind of team. Here’s how:


Experiment with Ceremonies:

Start with basic ceremonies like stand-ups, retrospectives, and sprint planning. Then evaluate their effectiveness. Are daily stand-ups helping your team stay aligned, or do they feel like a chore? If your team works better asynchronously, consider cutting back on the stand-ups or making them more focused.


Workflows and Tools:

Use whatever workflow supports the way your team works best. A Kanban board might be better for a team with lots of ad-hoc requests, while a more structured backlog might work for a team delivering specific product increments. Utilize simple tools like Jira, Trello, or even a physical board to track work visually.


Prioritization Frameworks:

Figure out what approach to prioritization aligns best with your team’s goals. You can use MoSCoW (Must-have, Should-have, Could-have, Won’t-have), a Value vs. Effort matrix, or even just a simple conversation about what needs to be done first. The key is to find a method that helps the team focus on delivering value continuously.


Example:

A design and innovation team within a large retail corporation mixed practices from Agile, Lean, and Design Thinking. They adopted Agile’s short iterations for development work, Lean’s focus on continuous improvement, and Design Thinking’s emphasis on user-centered ideation. This blend allowed them to be nimble and user-focused while still moving quickly through prototyping and iteration.


Step 3: Define Key Metrics, but Don't Overdo It

Measuring the success of your custom Agile process is crucial, but it’s easy to fall into the trap of metric overload. Choose 2-3 key performance indicators (KPIs) that are meaningful to your team and align with your business goals. Common Agile metrics include:


  • Cycle time:

    How quickly does work move through your process?

  • Lead time:

    How long does it take from the moment a task is requested until it’s delivered?

  • Throughput:

    How many tasks are you completing over a given period?

It’s vital to continuously review these metrics to identify areas for improvement.

However, avoid tracking too many metrics, as this can create unnecessary overhead and distract from what really matters — delivering value.


Example:

A startup building a mobile health app focused solely on two metrics: cycle time and customer feedback scores. By keeping their metrics simple and aligned with their ultimate goal (delivering a smooth, valuable app experience), they were able to quickly iterate and improve their product without getting bogged down in metrics that didn’t add value.


Step 4: Continuously Improve and Iterate

One of the core tenets of Agile is the principle of continuous improvement. As you roll out your custom process, treat it like a living organism. Regularly gather feedback from the team through retrospectives, surveys, and direct conversations. Ask questions like:


  • What's working well?

  • What feels like a waste of time or effort?

  • Where are the blockers or bottlenecks?

  • After identifying areas for improvement, test small changes, and measure the impact.

Maybe that means cutting a stand-up from daily to three times a week, experimenting with “silent” sprint planning to save time, or introducing a new tool to streamline collaboration. Whatever the case, aim to continuously refine your process to match the evolving needs of your team and your work.


Example:

An AI and data analytics firm found that their retrospectives were filled with the same old feedback week after week, leading to a sense of stagnation. They decided to change the format of retrospectives every month to keep the conversation fresh and focus on new angles of improvement. Some months, they held retros as “celebration retros,” focusing only on wins. Other months, they tried "silent" retrospectives where feedback was written down first, then discussed. This constant iteration helped keep the team engaged and led to actionable improvements over time.


Why “Rolling Your Own” Works Better

The flexibility to create and continuously refine your process is what makes Agile genuinely agile. Here’s why designing your own process can be more effective than following a prescriptive method:


Responsive to Change:

You’re free to respond to the unique needs of your team and project as they evolve, rather than being stuck to a rigid framework.

Empowers Your Team:

Your team feels ownership over the process, which increases buy-in, boosts morale, and encourages a sense of collective responsibility for outcomes.

Maximizes Efficiency:

By eliminating unnecessary steps and focusing on what truly works for your team, you streamline delivery and focus more on what matters — shipping value to your customers.

Encourages Continuous Learning:

The process of refinement fosters a culture of continuous improvement, where every team member is empowered to find ways to enhance collaboration, efficiency, and effectiveness.


Ultimately, “rolling your own” process is a commitment to efficiency and value. It requires more active management and regular reflection than simply following a predefined Agile methodology, but the payoff is huge: a process designed around your team’s unique needs, capable of adapting to any challenges or changes that come your way. And that’s the real spirit of Agile.


Tools and Mechanisms for Analyzing and Designing Agile Processes

Crafting a custom Agile process requires a deep understanding of how your team works, but how do you go about analyzing your current state and designing something new? Thankfully, there are several tools and mechanisms that can help facilitate this process. Each tool has a specific use case, and choosing the right combination can make all the difference in tailoring an Agile workflow that’s both efficient and effective for your team.


Here’s a breakdown of some of the most impactful tools and mechanisms, along with insights into how they can help analyze and improve your Agile process.


1. Value Stream Mapping

What it is:

A Lean management technique for analyzing the flow of information, materials, or work through a process.

How to use it:

Value stream mapping helps visualize all the steps (value-added and non-value-added) needed to deliver a product or service. The goal is to identify waste and bottlenecks to shorten cycle times and improve flow.

Use case:

A software development team could use a value stream map to track a user story from the backlog to delivery. By mapping each step (e.g., refinement, development, testing), the team can identify delays and smooth the workflow for quicker delivery.


2. Process Flow Diagrams

What it is:

A visual representation of each step involved in a process.

How to use it:

Use flow diagrams to model current workflows or future states. They provide a clear overview of how work progresses and make it easy to identify bottlenecks or unnecessary steps.

Use case:

A design team can create a flow diagram to outline how concepts evolve from idea to prototype to production. This allows for a review of each step and fosters discussion about how to make transitions smoother or approvals quicker.


3. Kanban Boards

What it is:

A visual tool for managing workflows and tracking the status of work in progress (WIP).

How to use it:

Create columns that represent different stages of your process (e.g., To-Do, In Progress, Review, Done) and use cards for individual tasks. Teams can easily see where work is, identify bottlenecks, and limit WIP to avoid overloading any stage.

Use case:

A customer support team can use a Kanban board to track tickets from "New" to "Resolved." Visualizing the flow helps the team balance their workload and prevents tasks from slipping through the cracks.


4. SWOT Analysis (Strengths, Weaknesses, Opportunities, Threats)

What it is:

A framework for analyzing internal and external factors affecting your process and team performance.

How to use it:

Use a SWOT analysis to evaluate your process. Identify what works well (strengths), areas needing improvement (weaknesses), upcoming efficiency opportunities (opportunities), and potential risks (threats). This insight can drive actionable process improvements.

Use case:

A cross-functional product team may perform a SWOT analysis during their quarterly review to understand why they aren’t consistently meeting sprint goals. Discovering that poor communication is a weakness could lead to implementing weekly syncs between different team roles.


5. Metrics Dashboards

What it is:

Dashboards that track key performance indicators (KPIs) related to the team’s processes.

How to use it:

Use tools like Jira, Trello, or custom reporting to track Agile metrics such as cycle time, sprint burndown, and team velocity. Visualizing these metrics helps identify trends, areas for improvement, and progress toward goals.

Use case:

An engineering team can create a Jira dashboard that tracks how long tasks stay in different stages of the development process. Identifying that code reviews take longer than anticipated may lead to additional training or resource allocation.


6. Retrospective Tools (Digital and Physical)

What it is:

Tools or techniques for conducting retrospectives, where teams reflect on processes to identify what’s working and what can be improved.

How to use it:

There are numerous online tools for running retrospectives (e.g., FunRetro, Retrium, Miro), as well as traditional in-person methods like sticky notes and whiteboards. Retrospectives create a safe space for feedback and foster continuous improvement.

Use case:

A marketing team can conduct bi-weekly retrospectives to review campaign planning. They might use a tool like Miro to perform a “Start, Stop, Continue” exercise, quickly identifying practices they want to start doing, stop doing, and continue doing.


7. RACI Matrix (Responsible, Accountable, Consulted, Informed)

What it is:

A mechanism for defining team roles and responsibilities within a process.

How to use it:

Create a RACI matrix to map out who is responsible for each task in your process, who is accountable for decisions, who should be consulted, and who needs to be informed. This prevents miscommunication and clarifies ownership.

Use case:

A project management team can use a RACI matrix for a product launch to ensure that all roles are well-defined, preventing confusion during the approval and rollout stages.


8. Journey Mapping or Customer Story Mapping

What it is:

A visual exercise to map out the user experience as they interact with a product or service.

How to use it:

Journey mapping helps you understand user touchpoints and pain points, which can then translate into process improvements that better serve customer needs.

Use case:

A product team developing a new app feature can use customer story mapping to visualize how users will interact with the feature, building a backlog and prioritizing based on value delivery.


9. Experimentation & Hypothesis-Driven Development

What it is:

An approach using small, incremental experiments to validate process improvements before fully implementing them.

How to use it:

Treat changes to your process as hypotheses, such as "If we reduce stand-ups to twice a week, then the team will have more focus time." Run an experiment and measure results before fully adopting the change.

Use case:

A game development team struggling with QA delays could experiment by involving QA earlier in the process. If testing this new process decreases cycle times, it can become a standard part of their workflow.


10. Feedback Loops with Stakeholders

What it is:

Engaging with internal and external stakeholders to gather feedback on processes and product outcomes.

How to use it:

Engage stakeholders regularly to collect feedback on how your Agile process is affecting delivery and outcomes. This provides fresh perspectives on what’s working and what could be improved.

Use case:

A software company working on a B2B platform could hold monthly check-ins with customers to review progress and gather feedback, ensuring that the process for defining and prioritizing user stories aligns with customer needs.


Using These Tools for Continuous Improvement

These tools provide a framework to evaluate, design, and refine your Agile process continually. The key is to use them as mechanisms for reflection, experimentation, and improvement. With a combination of these tools and practices, you can create an Agile process that evolves alongside your team’s needs, ensuring that every change is rooted in value and efficiency.



Ultimately, these tools enable teams to build a process that delivers value efficiently, eliminates waste, and drives continuous improvement — all key pillars of Agile. By regularly analyzing and refining your processes with these mechanisms, you’ll ensure that your Agile practice stays aligned with the evolving needs of your team and your customers.


Conclusion: Tailor Agile to Your Needs

Agile is a mindset, not a recipe. There are dozens of frameworks out there, but the best process is one that fits your team’s unique challenges and goals. Remember that being Agile is about adaptability, simplicity, and collaboration — not rigidly following a prescribed methodology. The Agile Manifesto laid down some timeless principles, but it didn’t dictate how to apply them. That’s up to you and your team.


So go ahead: break the rules, experiment, and find what works. You’ll be more Agile for it.


Further Reading

7 views

Recent Posts

See All

Comments


bottom of page