Like many people, I use my phone to conduct business, but lately, the apps I depend on are not working. Links from emails lead to dead pages, critical notifications do not arrive on time, circular pages force me to log in continuously, and I am deleting and reinstalling apps more than ever. I don’t blame Agile, but I do blame the culture it is creating in the developer community.
What is Agile?
Agile is a process or even way of life for most software developers. The single most important aspect of Agile is it lets developers get to work and develop software without necessarily knowing all the detailed requirements for the app up front.
Developers run little mini-releases, called Sprints, where they work diligently on the code for one or two weeks, and then release it. The release may be internal or published out to the end users right away.
Here is the basic approach: The business owners (people with requirements) create a list of user stories (“A user wants to print the page”). This user story becomes one or more work items. The work items are now on a backlog.
The developers meet for very targeted daily standup meetings where they discuss the backlog and issues. It is in these standup meetings where people may accept new work from the backlog. Every day, developers work on their small chunks of code (those work items). Within days or weeks, a developer will commit their changes and then push the code up for review by a senior engineer to review.
As you can see, the developers are always creating new code, fixing existing code, and pushing it out in a never-ending circle. That is why Facebook, Yelp, Lyft, and other app developers are always asking you to update to the latest version. This innovation cycle is exciting and is certainly the way of the future, but as you can imagine, the more code a developer releases, the higher the risk of new bugs.
The age of the full stack developer
Head over to any job site right now and search for the term developer. I guarantee you will see at least one — if not many — jobs for Full Stack Developers. These developers have the background and experience to do things such as write user interfaces, create databases, build business logic, and much more.
App developers love hiring full stack developers because Agile is fluid. One day, a developer may create a new user interface window and two weeks later, that same developer can work on the database. Of course, the challenge with a full stack developer role is you run the risk of the developer being a Jack of all trades, and master of none.
So is Agile a bad thing?
Let me be clear: There is nothing wrong with Agile, and there is nothing inherently wrong with full stack developers. As a matter of fact, I am an Agile practitioner and use the same processes I mention in this article for my software products. As a developer, I can be seen working on anything from C# code to JSON or user translations. Granted, Agile is not for everyone or every software product, but the approach is valuable and keeps developers fully engaged in their craft.
Agile is also useful because you do not want a staff of developers sitting in meetings, discussing new features, and waiting for long, drawn-out specifications to be complete before they can get to work.
Developers get the idea of what a business wants and can start building functionality while other people figure out exactly what they need. I doubt any modern app or game you use on your phone would be as fresh and new if it weren’t for developers constantly tweaking and improving the code using Agile.
The challenge with Agile
In some recent client visits, I noticed a significant lack in quality assurance testers. As a matter of fact, at one popular software company, they have nearly removed the QA role from the regular cadence of software commits. Instead, product managers and general employees are expected to test the software in hopes of catching bugs.
Before releasing my latest app, I was walking down the hallway and was excited about the release, and told a colleague (maybe bragging) about the small list of bugs and how I knew they had no impact on launch. He turned to me, smiled, and said, “Right, but the fun part begins when your users catch bugs you never knew existed.” His message was a sobering reminder that sent chills down my spine.
As a software developer, I am pretty in tune with the code I am writing and how it might affect other people’s code in the process. Unfortunately, it is the unknown that causes some of the most significant bugs or security flaws in a product. Quality assurance teams make sure certain features work, but they look for broken user scenarios, and they do things many developers would not do.
Some of the issues quality assurance teams find are simple to fix, but their real value is in finding endemic problems with the code. That’s right; there is value in finding these serious problems. This has nothing to do with the developer’s capabilities but has everything to do with the fact that a lot of people are adding a lot of new code in very short time windows, so things happen and those things can have a direct and negative impact on your users.
But we will fix things, eventually!
Maybe you will; maybe you won’t. At the top of this article, I mentioned some issues I have had with name-brand apps. These issues have been around for months. As a matter of fact, I have a few apps where the companies tell me they are fully aware of the problem and they even tell me my issue is in the backlog. Meanwhile, I can go to app stores to see the dwindling star reviews and ALL CAPS yelling from customers having the same issues I complain about.
Why aren’t those issues being fixed? Maybe someone is asleep at the wheel, maybe someone feels the bugs aren’t important enough, maybe developers aren’t using their product, maybe quality assurance is not part of the culture. Or maybe the company cares, but what seem like simple fixes might be months and months of work. Who knows the answer, but what I do know is it puts users off, and they will find other solutions if need be.
So what do we do?
In an Agile environment, you need to bring quality assurance — as a practice — to your development teams. These QA teams need to be part of the commit process where not only a senior engineer approves the code, but so do the QA engineers.
I do not suggest every single last bit of code requires a human being to test, but there must be a reasonable QA staff in place. That QA staff must have authority to act as a voice for the user, peel back the onion looking for trouble spots, and have escalation authority.
Innovation is great, but even breakthrough technologies have to work properly. We cannot leave major bugs sitting at the bottom of the backlog waste bucket because there is shiny new code to write first. We need to take pride in the quality of our products and reinforce that with our teams.
