The State of Agile – It's Our Fault Too

This article is for software developers who are frustrated with the state of agile, and I know that’s nearly all of us. We all need to take a look at what got us here, and what we can do about it. 

Have We Lost Our Way?

The majority of software developers I’ve worked with immediately resort to air quotes when saying the word “agile.” By now, we all probably have our own horror story to tell. It’s a shame because we were promised all of the pitfalls of waterfall would be solved – ambiguity in requirements, long delivery times, inability to pivot, etc. We even embraced the idea of agile at first, spearheading the first agile framework, Xtreme Programming. The original agile principles outlined in the Agile Manifesto, as well as Xtreme Programming, were grassroots movements born out of the experience of software developers in the 80s and 90s. They were not overly prescriptive in their approach and had a focus on technical excellence – calling for pair programming, test driven development, and continuous integration. By far though, the biggest change from waterfall was an iterative approach to software development, with a focus on team empowerment, small releases, and regularly integrating customer feedback into the development cycle. These were great ideas and I think most developers and organizations would agree, while not perfect, it is better than the alternative. 

Unfortunately, agile software development was hijacked by organizations and consulting firms trying to capitalize on the trend. New agile frameworks were pitched and “Digital Transformation” became the next big thing. Certifying bodies popped up, generating millions of dollars in revenue issuing digital certifications for 3 day classes. Almost overnight, it seemed that the loose values defined in the Agile Manifesto had been replaced with overly authoritative frameworks. Teams were bloated with roles that added little value, and some organizations even started trying to track how well a given team was ‘doing agile’. Comparing story points completed by one team to another, auditing a team’s stories to make sure they were written according to company standards (yes I’ve seen this), chastising the team for not planning well enough if work was pulled into the sprint that wasn’t originally defined during sprint planning. Hours and days wasted in large scale planning sessions under frameworks like SAFe, where the vast majority of what you planned becomes irrelevant after the first week of implementation. So what happened? 

I’ve seen a lot of finger pointing. 

• Organizations with bloated middle management unwilling to let go of their traditional measures of productivity 
• Large consulting firms pushing these ideas on their clients 
• Non-technical people being drawn into the field due to the rising compensation for developers 
• Inadequate training 
• Lack of leadership buy-in 

• Excessive focus on process manifesting in Goodhart's Law

One place I don’t typically see software developers pointing our fingers is back at ourselves. I think this is a mistake, and I’d argue we share a lot of the blame, maybe even the majority of it. 

Software Development is a Means to an End

As a software developer, we sometimes get lost in our craft, unable to see the forest for the trees. It is important for us to understand that if the business could get away with it, we wouldn’t be employed at all. The organizations we write code for exist to provide a product or service to their customer. So,the code we write is not of primary interest – it is a means to an end. 

Lucky for us, in this digital age, businesses cannot survive without software development talent. But a large portion of our industry has forgotten that we are here to serve the business first and foremost. What follows is a list of behaviors I’ve seen exhibited over the last decade from software developers. 

• When confronted with a user story that does not meet a product owner’s expectation, a developer will fire back with a line like, “That wasn’t in the Acceptance Criteria.” 
• Complaining about the number of meetings and ceremonies they have to attend, without understanding why they exist, or suggesting other ways of working. In many cases these are the same developers from the first point, who have proven they cannot be trusted with ambiguous requirements. The business tries to fix this by drowning the development team in process and adding additional roles. 
• Pawning off story creation and backlog refinement as a responsibility of Product, refusing to contribute to the conversation because they are ‘here to code.’ 
• A complete lack of understanding of the entire SDLC, living in the bubble of our IDE and version control system. Once the PR is created, our work is done, happy to allow others to make sure our work gets to production. 
• Treating QA as our personal insurance policy, consequently shirking the responsibility of testing the functionality of our code locally and/or in test environments. 
• Relying on scrum masters and product owners to schedule meetings for them to resolve dependencies. 
• Waiting until stand up the next day to raise a blocker instead of resolving it proactively. 
• Not contributing during refinements unless called upon directly. 
• Not showcasing our work during demos because it is ‘too technical’ and stakeholders wouldn’t be interested. 
• Managing expectations poorly, deciding to hide or downplay delays. 
• Poor communication, not responding to instant messages and emails in a timely manner, leading to questions about commitment and availability. 

At the heart of agile is team empowerment and trust. Trust must be earned, and constantly reinforced. It is no wonder that overly prescriptive frameworks have been adopted with some of the behavior our industry exhibits, and in some cases even celebrates. We have allowed ourselves to become code monkeys, taking orders from others that supposedly represent and understand the business better than we do. And if we continue to reinforce that stereotype that developers need to be managed, maybe we deserve the current state of agile. When the business cannot trust us to deliver value, and we cannot articulate our value clearly, the business will look for other ways to measure us. And that measurement often comes in the form of tracking our output through micromanagement. 

A Path Forward

If we want our teams to be empowered, then we must regularly show our value. At the end of the day, you will be left alone to work however you’d like to work, as long as you can produce positive outcomes. It may take some time to build that level of trust, but I’ve yet to work anywhere that doesn’t allow me to call my own shots once I’ve established that trust. You must demonstrate that you are more than a code monkey that needs to be managed, and that you understand the needs of the business. 

Stop letting scrum frameworks put you in a box. Just because our role on the team is developer doesn’t mean we can’t contribute beyond measuring our productivity only in the number of story points we complete each sprint. Some things I have done to build the level of trust I mentioned earlier are: 

• Contribute to conversations about the product you are building. Go to end user interviews, ask questions, and try to view things through their eyes. 
• When you pick up a new user story, test your understanding of the problem you are solving. Treat the user story like a conversation starter and strive to build consensus with your team and stakeholders about what ‘done’ looks like. 
• Proactively look for opportunities to improve the product and write user stories or defects to share with your team. As an example, with my last client, I noticed a lack of observability for the products at the organization. I spearheaded the adoption of an Application Performance Monitoring tool that led to significant visibility improvements into error rates. I then cataloged these errors and wrote defects to improve the user experience. I have similar stories noticing a user flow requires too many clicks and could be streamlined. 
• Always show your value. Any time you start on new work, think about how you can articulate the value of that work to the non-technical people in your business. And then present your work at your team’s sprint review! 
• If you think a refactor or change in technology is necessary, make your case in business terms. For example, the complexity of this code base has caused x amount of bugs when adding new features over the last 3 months, impacting y amount of users, likely costing the business z amount of money due to negative customer satisfaction and defect remediation time. 
• Over communicate and be available, especially in remote environments. Some people can multitask well, and some can’t. If you are one of those people that can, then respond quickly to instant messages and emails. Letting someone know that you saw a message but don’t have time to respond at the moment goes way further than leaving them on read, or just not looking at it at all. We live in an instant gratification world, like it or not, it has become an expectation. If you are someone who needs that heads down time and does not handle interruptions well, then schedule that time and put up a status so people know why you are not responding, and when they are likely to hear from you. 
• Manage expectations. Deliver what you are going to deliver when you said you were going to do it. If you are off track, let people know! And explain why in terms that can be understood by your entire audience, technical and non-technical.

If we don’t like agile frameworks, then let’s make the frameworks unnecessary. Let’s prove they are redundant and wasteful by taking initiative and showcasing our ability to bring value to the business without them.

To learn more about how Callibrity can help your organization, email us at contactus@callibrity.com to schedule a time to connect.