Customized Agile: Increasing Fluidity of Agile Practices Across Teams

Feb 24, 2016

Happy 15th birthday Agile Manifesto! On February 13, 2001, the Agile Manifesto was born. Today, 15 years later, the main tenants of it still ring true:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I have personally been part of the Agile NYC tech scene for the entirety of these past 15 years. As such, I have had a front row seat at the ever evolving landscape of Agile implementation and adaptation.

Today, most companies either claim they are Agile, are trying to become Agile, or have tried Agile. In truth, what I see today is a lot of customized Agile. In fact, the term “Traditional Agile” has come to mean the pure, original implementation of Agile. And, most companies are not following “Traditional Agile”. Instead, teams are customizing Agile to fit their needs, making the fluidity of Agile more prominent now than ever before. Here’s what I’m seeing in 2016:

Pair Programming

Very few teams are pairing 100% of the time. Very few teams are pairing 0% of the time. Most teams are pairing 10% - 70% of the time. Teams that are pairing 10% - 25% of the time are finding it the efficient for:

  • Training a new developer on an existing code base
  • Mentoring a junior developer
  • Spiking out a difficult story
  • Solving an unknown and/or difficult problem
  • Transitioning from one tech stack to another

It’s also worth noting that in general, the smallest and newest teams are often pairing the least.

Teams that pair program 25%- 70% of the time are often tech teams with multiple squads, or multiple cross functional teams. The large majority of these teams empower each squad/team to identify the amount of pairing that is ideal for them. So for example, one of our clients has eight squads: Two of the squads pair most of the time, four pair about half the time, and two pair only occasionally. One big problem these types of teams run into that engineers find it challenging to rotate among teams because practices aren’t standardized and someone who’s used to pairing now has to join a team where pairing isn’t the norm.

Teams that pair 70% - 100% of the time often have full buy-in from the engineering teams and the leaders of the engineering team, and pair as the default practice. They’ll occasionally not pair on the simplest of stories or when there’s an odd number of people on the team.

Of interest is that it’s not always the case that the teams with the highest percentage of pairing have full buy-in from non-technical leaders of the organization. In fact, I am often called in to consult board members and CEOs of companies who’s teams pair 70%+ of the time to explain the virtues and benefits of pairing, for these stakeholders fear they don’t fully understand the cost/benefit model behind pairing.

Test Driven Development

TDD is the most commonly adopted Agile engineering practice. Teams consider themselves in good shape if they have 80% or more test coverage.

Some teams cut corners with TDD, either when deadlines get tight or the team grows really fast. But, the large majority of teams have the discipline to create tech debt around TDD and then go back and address the tech debt in future iterations.

Daily Standup

This is a split bag. Some teams have Daily Standups, some do not. Here, logistics plays a huge role. If team members are distributed, or arrive at work at varying times, the Daily Standup often falls by the wayside. The most typically used agenda for the standup is:

  • What did you do yesterday?
  • What are you doing today?
  • What roadblocks do you have?


Most teams use sprint lengths of 1 or 2 weeks. The daily activities inside Sprint varies greatly across companies. Some teams will conduct planning sessions and assign stories with acceptance criteria and measure story points complete at the end of each Sprint. Some teams hold planning sessions but don’t hold team members accountable for finishing all the stories put into the sprint. And some teams don’t have a formal planning sessions but use Sprints as a chance to demo products to stakeholders regardless of what was accomplished during the sprint.


Estimation practices vary wildly across companies. Over the years, various methods to estimate work have been devised. Some teams got fed up with the entire concept and launched the #NoEstimates movement a few years back. Today, many teams have found a healthy balance that works for them and that is not too cumbersome. Often, the goal of estimation is to answer the question “How much is this going to cost?” for a set of stakeholders. To read more about my theories on estimation, read Budgeting vs Estimating for Agile Projects.

There are of course, many other Agile practices. Agile Alliance does a good job of describing them all in detail here.

I’m interested to learn what you are seeing. Do you agree with what I’ve seen, or do have another viewpoint? Please leave comments below to share, or contact us to continue the conversation.

You May Also Like

These Stories On Process

It's the third week in a row that your team has given the same update: "We are almost done with the 'previous orders' feature." You are frustrated with the lack of progress and the inability to shift to more important work—like that feature you wish the ... read more

Josh Seiden, the fourth speaker in Stride's Leadership through adversity speaker series, spoke about the value of focusing on outcomes, defined as: "measurable changes in behavior that drive business results."   read more

To start his talk, psychiatrist and psychoanalyst Dr. Kerry Sulkowicz admitted to being at a bit of a loss when asked about best practices for leading through a pandemic. "The honest answer is I don't know," he stated, "because none of us has lived ... read more

Taking direct aim at the narrative of the "all in" entrepreneur who takes extreme risks and depletes their bank account before ultimately succeeding, noted NYC VC Charlie O'Donnell started his Stride Consulting “Leading through Adversity” talk on May ... read more

Get Email Updates