This is the first in a series of articles discussing problems with Agile, a new methodology to replace it and how to transition your Government contracting team. Some definitions and constraints for these articles:

• I use the term “Agile” to mean the whole ecosystem and manifesto, and more specifically, it’s most adopted practice, Scrum. I will generally use the terms Agile and Scrum interchangeably. Why? Because everyone else does and that’s kind of my point.
• While some of these points may apply outside of Government contracting, this is the area that I’ve worked in my whole professional career and where I see the most problems with Agile.
• In general, I’m referring to Agile software development for web applications and operational systems, NOT products. This is an important distinction because I can see why Agile would work well for product teams.
• TL/DR: the only thing I would keep about Agile is iterative development. This isn’t exclusive to Agile, but nearly everyone who talks about Agile means iterative development.

A (Very) Brief History of Agile

The following timeline shows an abbreviated history of software development as it relates to Agile:

The providence of Agile can be traced all the way back to the 50s. However, the focus of this article is on Scrum, introduced in the mid-90s, and the Agile Manifesto in 2001. Highlighted in blue are some important tools that have come out since Agile. (The list is not exhaustive) Those, along with other paradigm changing tools and methodologies that have come out since:

• Decentralized version control (Git)
• The first MacBook
• Real-time collaborative documents (Google Docs)
• Cloud services, SaaS and PaaS (AWS)
• Containers (Docker)
• Wide-spread adoption of persistent chat (Slack)
• Continuous integration tools (Jenkins)
• Configuration as code (Puppet, Chef)
• Javascript-everywhere (Node, React, Angular, NPM and thousands of others)
• The idea of continuous delivery and deployment
• Service Oriented / Microservice Architecture
• Self-healing applications and insane levels of abstraction (DC/OS, Mesos)

Over the past 15 plus years, software development has changed dramatically. This is easily explained away by Moore’s Law and the idea of Accelerating Change. Agile has also changed – by adding more terms, processes and “rituals”:

While the software landscape has expanded and significantly simplified (I can deploy a full application in seconds using Docker), Agile has tried to keep up with false complexity and more rituals meetings.

What makes it time to ditch the sticky-note wall?

Advanced collaboration tools.

Persistent chat tools like Slack and my personal favorite, Rocket.chat, are game-changers. I can be in constant real-time communication with my whole team. We can integrate our build tools, version control and issue tracking software. I can update my team, and customers, from my cell phone while stuck on the Metro. There’s Google Docs and Office 365 for working on documentation. There’s web applications like codeshare.io, codepen.io, and jsfiddle.net to work on problems with your colleagues. And let’s not forget to mention Stack Overflow.

Why abide by the constraints and processes of Agile when real agility lies in using these real-time tools?

Too. Many. Meetings.

Scrum is supposed to have four rituals – Sprint Planning, Review, Retrospective and the daily Stand up. Nowadays I’ve seen and been part of pre-Sprint planning and prioritization meetings; or as I like to call them, Sprint-planning planning meetings. There are Story Pitch meetings each week, which are somehow the same but different from Sprint planning. We break up the Sprint Review into an internal demo meeting and then another with the Product Owner. And why not have some “team lead” meetings and customer meetings on top of the ones you need to get your job done.

Meetings are not work. They produce nothing tangible. An hour-long meeting doesn’t simply mean an hour less work. Work doesn’t get done before or after due to transitions and task-shifting. If a team has only 6 hours of meetings scheduled each week, I would estimate the real impact is about 10 hours, or 50% more. That’s an insane 25% overhead each week!

Most importantly, they interrupt the flow of development.

A developer writing code for 4 straight hours is much more productive then one who writes code in hour-long chunks separated by meetings. Even if the total time spent coding is the same, developing, like nearly everything else determined by the economies of scale. Each consecutive hour of uninterrupted development time builds momentum exponentially.

T&M contracts.

The whole point of Scrum is to deliver all planned work at the end of each Sprint. On your T&M contract, the team is expected to be productive every hour of their 40-hour work week. One of the better ideas behind Scrum is flexibility for developers; sometimes they get work done early and can spend time on side-projects, other times they need to crash to meet the deliverables. This ebb-and-flow doesn’t fit with your standard T&M contract.

The result is adding and removing items from the Sprint, or having work carry over. Neither is ideal. The key benefit of Scrum (from a customer’s perspective) is knowing what will be delivered.

Labor Categories.

Contract defined labor categories make your team rigid. It’s hard to be flexible when the structure of your team is pre-defined. Depending on where you are in the project lifecycle, you need different skillsets. Even the categories themselves are dated. The last proposal I worked on had everything from Technical Writers to Electronic Data Interchange Specialists. There were three LCATs dealing with databases: Database Administrator, Database Management Specialist and Database Specialist. The cherry on top was the Graphical User Interface Designer. Not only are these categories confusing, they don’t reflect modern software development.

Agile was developed by and for developers.

NOTE: This isn’t meant to put down non-developers or specialist. They should be brought in and out as necessary, which is very difficult in contracting.

Operational applications.

Scrum doesn’t work with operational systems. Full stop. Problems come up with every operational system, every single day. The team needs to help end users and keep the application running. Moving work in and out of a Sprint is a waste of all that planning. Or in worse cases, your Scrum Master hunts you down to make sure the hotfix “user story” was approved before you started working on it.

Sorry end user, I’ll be back in 20 minutes because I need to go to my stand up.

Waterfall won’t go gently into the night.

Weekly reports, Gantt charts, scheduled status meeting…*screaming intensifies*

I have a disdain for meetings. Let me clarify, a disdain for weekly meetings that generally only serve a purpose as long status updates. So many different projects keep all the old meetings and just add the Agile rituals on top. And so much paper-work; user stories need to be constantly updated in JIRA or TFS, yet we still create a Weekly Action Report (contract mandated of course).

Agile institutionalizes micro-management. “Can I get a status update on User Story X?” said every manager ever. And I don’t want to get started on managing by metrics. Some teams cannot move beyond this, to their detriment.

Additionally, teams still have dedicated Business Analysts gathering requirements. This is quintessential Waterfall. Having the BA’s be the go-between the customer and developers is a bad game of telephone. Time is wasted, developers are constantly interrupted and the user stories are almost always incomplete.

Agile is supposed to put the Product Owners directly in touch with the developers. You can’t keep the staff and contract the same, slap Agile on top, and expect different results.

ANOTHER NOTE: Business Analysts and functional staff in general are critical to a well-rounded, cross-functional and I might add, exceptional team. This point is about how they don’t fit into Scrum, not saying they aren’t important.

Matrix organizations.

I’ve seen a recent shift from project-based work to more staff augmentation. This doesn’t inherently go against Agile, it just complicates issues. Who do you report to as a team member? Your contractor PM? The Government PM? Your stakeholders? Your Functional Manager? Your Scrum Master, team leads or end users?

Scrum aims to flatten teams with no one person being more important than the other. Everyone is in it together. The real world will never be like that, but we can get a little closer by allowing the project teams the latitude and flexibility to be self-forming.

What’s next?

Agile has become over-used and poorly implemented. It hasn’t adopted to the realities of modern software development. Government contracting hasn’t changed enough to allow for successful implementation of Scrum. And the answer isn’t to do Scrum “harder.” It’s time for a change.