“Agile” has become a buzzword—an adjective over a mindset.
In the 2020s, every company wants to say they’re Agile or even “highly Agile.” In fact, 71% of U.S. companies claim they use the project management and software development philosophy – up 88% since 2002.
It makes sense. Top-down bureaucratic leadership is outmoded. And, Agile’s low-risk promise, a focus on delivering value for customers, in short, organized cycles make the iterative approach an attractive remedy to all of work’s issues.
But Agile’s popularity and widespread adoption have led to a watering down of the true meaning of Agile. “Fake Agile” has emerged as a random label slapped on unremarkable management. A cottage industry of for-profit Agile courses, conferences, and certifications has cropped up. And, a desire to “do” Agile seems to have superseded “being” Agile.
Where is the disconnect? What’s “fake Agile?” What does “doing Agile” look like? And why doesn’t Connamara have an Agile sticker on its Accolades page?
The Declaration of Independence For Software Development
A quick history lesson is in order. The 1980s and 90s were all about trying to codify software engineering practices in the workplace. Computer programming was no longer a hobby for nerds but a legitimate corporate tool. Methodologies, blogs, seminars, and books-on-tape appeared, all trying to systemize an effective software development process.
In 2001, at a ski resort in Utah, seventeen thought leaders met for a sort of Signing of the Declaration of Independence for geeks. They wanted to assemble varying frameworks and agree upon what makes successful documentation-driven software development. Reps from different perspectives were present, including Scrum, Crystal, and Adaptive Software Development. Martin Fowler, Chief Scientist at Thoughtworks, was also in attendance – more on him in a moment. The group called themselves The Agile Alliance and, in three days, built the Manifesto for Software Development.
Let’s back up a bit. In 1999, just before the famous ski resort summit, Jim Downs founded Connamara. And he had landed one of his first gigs: a subcontracting software development job working with Thoughtworks. Jim worked alongside the experts from Thoughtworks, who imparted their pre-Agile development methodologies on Jim Downs as he worked on the project.
Connamara’s website does not carry an Agile Certification because Jim Downs learned Agile from one of the most intelligent thinkers of Agile philosophy. Downs took all he learned from Thoughtworks; as Connamara grew, he utilized the ideology fully and shared his insights with the first Connamara team members.
Connamara Agile
Today, we employ Connamara Agile, which maintains the true spirit of Agile. We write the requirements as user stories that add value and solve business problems, captured as executable specifications using tools like Cucumber.
The topic of Cucumber brings up a further example of Connamara Agile. Connamara’s dedication to behavior-driven development (BDD) predates the software tool’s invention. Before 2008, our engineers flexed their Agility and wrote tools that do what Cucumber does: define, automate, and execute test cases in a human-readable format. When Cucumber became available, we ported some of our tools into it as plugins and abandoned the parts of the program that didn’t suit our needs – thus practicing our Agile values!
Connamara Agile allows the client to prioritize the highest-value system functions to develop first. A common tenet of BDD tools like Cucumber is to “build the thing right and build the right thing.” At Connamara, we stand by this saying.
Beware of “Fake Agile”
The Agile Manifesto laid out four values and twelve principles (reaffirmed by creators in 2011), but all are very specific to software development. Thus, the grunt work of expounding upon the Manifesto has been left to the masses. I recall the famous Nietzsche quote: “Whichever interpretation prevails at a given time is a function of power and not truth.” Some of the loudest voices in the methodology space have misunderstood and misapplied Agile, which can cause core values to lose meaning.
To that end, “agile” has become a buzzword—an adjective over a mindset. An organization might brag about being Agile on its website but, upon further investigation, employs a Michael Scott-style management approach and is Agile in name only.
Alternatively, branded Agile off-shoots, promoted by the hundreds of consultants and commercial trainers on the marketplace, have brought confusion to the corporate world.
The ski resort summit was about agreement. But in the years since some brands just couldn’t help but distinguish themselves in the name of capital. Beware of these profiteers. They may be training employees to micromanage or inherit ineffective habits – something the Agile Manifesto is vehemently against.
Simply plucking one of these Agile remixes off the marketplace does not necessarily ensure an Agile work environment. Scrum (an Agile predecessor) is the most widely used Agile scion but remains one of the most polarizing methodologies. Agile is descriptive, not prescriptive. These supposed panaceas can’t cure every issue; only taking the methodologies and applying them in a way that adds value to your specific company can.
Agile Principles, Practices, and Values: What’s the Difference?
- Agile Principles influence and guide positive behavior.
- Agile Values (such as honesty, integrity, and respect) ground the principles and create a work culture that allows Agile to flourish sustainably.
- Agile Practices sit on the foundation of Principles and Values. Different methodologies (Scrum, Kanban, etc.) switch out the practices. But without a strong bedrock of Principles and Values, these Practices become meaningless ceremonial exercises.
Do This, Not That, to Be Agile
For some, the quest to be Agile is not for lack of trying. Yet, breakdowns occur with feedback, journeys get stalled, hiring gaps exist, and some teams lose the forest for the trees. Here are some quick, actionable recommendations on how to “be” Agile and shift your mindset for effectiveness. This is by no means an exhaustive list.
Do This: Prioritize Adaptability and Flexibility
- Embrace change as a natural part of the Agile process
- Be open to adjusting plans and strategies based on new information or customer feedback.
- Foster a mindset that values agility and the ability to pivot quickly when necessary.
Not That: Rigidly Adhering to Agile Practices Because You’re “Supposed to”
- Avoid sticking to initial plans and Agile practices when they no longer align with the current context.
- Discourage resistance to change or a “we’ve always done it this way” mindset.
- Be willing to re-evaluate and adapt plans to maximize value delivery.
Do This: Encourage Cross-functional Collaboration
- Foster collaboration between different roles and disciplines within the team.
- Break down silos and promote shared ownership of goals and outcomes.
- Emphasize the importance of open communication and knowledge sharing.
Not That: Working in Isolation or Departmental Silos
- Avoid isolating team members or segregating work based on departments.
- Discourage a mentality of “that’s not my responsibility” or “that’s someone else’s job.”
- Encourage collaboration across functions to improve efficiency and deliver better results.
Do this: Stick to the Point of Daily Standup Meetings
- Daily Standup Meetings, also known as Daily Scrums, Coordinations, or Huddles, are team-centric gatherings.
- Use this time to facilitate self-organization, get unblocked, and foster collaboration… in single-digit minutes.
- Keep the focus on sharing updates efficiently rather than repeating information or attempting to solve complex problems during the meeting.
Not That: Treating Daily Standup Meetings as Manager Meetings
- Avoid turning Standups into a platform for managers to gather status reports. Managers and stakeholders are welcome to attend, but a Standup is the team’s meeting.
- Don’t let the meetings become lengthy or off-topic.
- Reserve problem-solving for separate sessions, allowing the team to focus on quick updates and unblocking obstacles within minutes.
Do This: Focus on Important Decisions
- Allocate more time and effort to critical decisions that significantly impact project outcomes.
- Prioritize discussions and attention to complex or high-risk areas of the project.
- Involve relevant stakeholders with expertise in the specific decision-making process.
Not That: Don’t Lose the Forest for the Trees
- Avoid excessive debates and prolonged discussions on trivial or minor aspects of the project.
- Refrain from spending disproportionate time on less critical decisions. (see: Bikeshedding) For example: when it comes to GitHub Pull Request reviews, it’s better to get code committed and in front of users, potential users, and/or stakeholders quickly versus agonizing over a pull request for days.
- Keep the project’s overall goals and objectives in mind when deciding where to allocate time and resources.
Do This: Encourage Efficient and Timely Decision-Making
- Our founder and CEO, Jim Downs, likes to paraphrase a Teddy Roosevelt quote, “The only thing worse than a bad decision is no decision.” Connamara’s culture is all about decision-making.
- Promote an environment where decisions are made based on available information within reasonable timeframes.
- Empower team members to make decisions within their areas of responsibility to avoid unnecessary delays.
Not That: Get Trapped in Decision Paralysis
- Avoid getting trapped in analysis paralysis, where decisions are delayed or never made due to excessive deliberation.
- Discourage a culture of seeking consensus on every small decision, which can lead to unnecessary delays and frustration.
- Not all decisions require unanimous agreement. Decisive action is often more important than achieving absolute consensus.
Do this: Estimate Stories with Story Points and Track that Velocity Over Time
- When estimating the work to be done, utilize story points rather than trying to estimate in terms of time. Story points represent a task’s relative effort or complexity, allowing for a more accurate estimation.
- Monitor the team’s velocity and the number of story points completed in each iteration (sprint). By tracking velocity consistently over time, you can gain insights into the team’s productivity and capacity for future work.
- Based on the team’s historical velocity, predict the number of story points that can be completed in the next iteration (sprint). This estimation provides a better understanding of the team’s capacity and helps with prioritization.
Not that: Estimate Engineering tasks or Treat Story Points as a Measure of Time
- Avoid assuming that a specific number of story points corresponds to a fixed duration. Story points only measure complexity, effort, and use case.
- Users and stakeholders don’t care if we migrate the database; they care if the Story is done and can now use it.
- If you make this mistake, you can show great velocity iteration over iteration and yet end up with 100% of the Stories 80% done, so you can’t demo a single one, can’t get user feedback, and can’t predict when you will be done.
Do This: Manage Scope and Prioritize Deliverables
- Clearly define project scope via User Stories (Features) and prioritize deliverables based on their value and impact.
- Regularly review and adjust priorities based on stakeholder feedback and changing requirements.
- Focus on delivering the most critical features and functionalities first, considering the time and resources available.
Not That: Succumb to Scope Creep or Uncontrolled Expansion
- Avoid allowing the project scope to expand without proper evaluation and control continuously.
- Discourage the addition of unnecessary features or functionalities that do not align with the project’s goals.
- Maintain a disciplined approach to scope management and be mindful of the project’s constraints and objectives.
Takeaway
When choosing a software development company to build your custom solutions, do your research. Ask questions to understand how they came to claim their Agile status. In the case of Connamara, you will be pleasantly surprised.
