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?
Sprints
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
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.
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.
Debbie Madden
