Software Development: Delivering on the Promise of the Agile Manifesto
It started out with the best of intentions and a clear set of principles. But what began as a movement whose highest priority was to “satisfy the customer through early and continuous delivery of valuable software” has degenerated into actual practices that no longer support that goal.
We’re talking about the now widespread concept of “Agile” software development, and most companies who think they’re using it are kidding themselves. In too many cases, it has become simply a “no-plan” approach.
The Roots of Agile
It started back in 2001 at Snowbird Ski Resort in Utah. A group of 17 people experienced in software development and entrepreneurship met to discuss “an alternative to existing software development processes that they saw as complicated, unresponsive and too focused on documentation requirements.”
The group dubbed themselves the “Agile Alliance,” and what brought them together was a feeling that the process of building software was broken, bogged down in complex, long-term planning and focused too much on infrequent giant releases that tried to do it all. Making software had come to resemble the traditional “waterfall” approach used in construction and manufacturing, where everything had to be planned in advance before subsequent phases of the work could proceed.
The group’s Agile Manifesto proposed a different way of evolving software through continuous incremental improvements and frequent releases, driven by brief work periods they called “sprints.”
Their big focus was on meeting customer needs, creating software that works, building a supportive environment for developers, and remaining responsive to changing market conditions—not getting hung up on rigid plans and excessive documentation.
For some time now, it seems we’ve overemphasized a few roles in software development project management and returned to the bogged-down state that inflates budgets and reduces speed to market—two big no-nos at Modularis.
Those roles are full-time quality assurance specialists and full-time project managers. Let’s see how that got out of whack, and ensure you’re truly implementing agile manifesto principles with the right people in the right seats to minimize risk and maximize ROI.
QA: Quality Assurance or Quietly Avoid?
Nobody’s supposed to talk about it, but a couple of roles that have come to be common in software development today actually work at cross-purposes with Agile methodology.
Consider quality assurance (QA). It used to be—and still is at Modularis—that QA simply ensured software was ready for market. But over time, QA evolved into the sole function of finding bugs, creating delays in product development that directly contradict the Agile methodology.
QA specialists have a strong incentive to find bugs—whether generating those lists of bugs will help the team get a viable product to market or not. But their presence in the software development process has an unfortunate side effect: knowing it’s someone else’s job to find bugs and the high pressure to finish everything fast to meet unrealistic deadlines gives engineers less incentive to produce quality code.
At Modularis, we think QA should simply provide a final “sanity check” on the quality and usefulness of the software—not continuously focus on finding problems that send engineers back to the drawing board instead of innovating.
And in fact, we’ve found that rethinking traditional QA from the perspective of Agile’s original intent actually has several beneficial effects like:
Giving engineers more time to produce quality code than fix a backlog of bugs. Therefore reducing maintenance costs, having more resources to innovate.
Encouraging engineers to check their own code quality, knowing it’s on them. The accountability remains with the developer, which will encourage another of the Agile Manifesto’s principles: self-management.
Facilitating communication between more senior engineers and mentoring those with less experience. The risk of losing your IP with departing key personnel is reduced because the knowledge is in more than one brain.
The whole assumption of QA—which has become mainly interested in self-perpetuation—ignores the reality that engineers are by nature very detail-oriented and will find a way to produce higher-quality software without someone else constantly identifying and logging defects that should never impact the go-to-market timeline.
AQ: Automating for Quickness
On the other hand, engineers have their own instinct that unnecessarily consumes resources and slows down software development: the desire to build everything from scratch.
There is in most software shops a strong “not invented here” (NIH) syndrome because developers and engineers don’t like using code that they themselves didn’t create. In fact, they would rather spend long hours writing their own code than use someone else’s.
The software industry is built around the billable hour. There is a conflict of interest built into the value proposition of an outsourcing and/or staff augmentation company. The industry is not incentivized to become more effective because it cuts into their revenue. Therefore, developers are not encouraged to optimize software construction by reusing code and/or not given the time to automate repeatable functionality. We must stop perpetuating and rewarding that, and at Modularis we’ve developed a better way.
Our unique mastery of automation helps developers actually realize the original promise of Agile through rapid application development—leading to quicker testing and deployment, while boosting productivity across the entire process.
Project Management or Problems Magnified?
In an odd partnership with QA specialists, project managers (PM) got inserted into software development because someone had to try to keep engineers on schedule based on all the bugs QA was finding.
But project managers aren’t technically minded, and lack the data they actually need to manage projects. When they ask engineers how long a list of problems will take to fix, engineers typically just throw out a random estimate and tell the PM what they want to hear—even though they both know it’s not gonna happen.
Another classic interaction between PMs and developers involves estimating how much of the promised software fix has gotten done—as a percentage. And it’s become a joke, with this periodic question devolving into a number that starts at “99.9%” and eventually reaches “99” with a virtually uncountable number of nines behind the decimal as the PM just keeps asking.
Engineers just want to get project managers off their back and get back to work, but that leaves PMs with very little data to actually go on, rendering them ineffectual at actually controlling the project. It’s a lose-lose situation all around that, in the end, reduces ROI by mismanaging time and resources.
In fairness, developers often make technology decisions based on what they want to learn more about, not on what the business needs—leaving PMs completely in the dark about risky tech decisions that put the whole project in peril.
Scrum is one well-known tool in the Agile framework, but ultimately it’s just a tool, and project management now exists as a virtual sub-industry within software development because of a failure to follow true Agile principles.
A Modularis Manifesto
The Agile Manifesto encompasses 12 principles, starting with the very highest priority of creating value for companies. What’s not on the list: “assuring” and “managing” full-time employment for roles that don’t actually support the product goals you’ve set.
We see custom software as an engineering problem for the engineering team—something that only they can truly keep on track. Our methodology starts with automation and standardization, bringing predictability of performance to your code so you don’t need armies of QA specialists and PMs.
A Modularis product roadmap ensures your software R&D efforts align with where your business is going. It keeps everyone aware of what’s done or needs to be done. We call it agile with discipline.
With a custom Modularis-driven roadmap, software development becomes a collaborative effort, with stakeholders and engineers coming together to figure out what the business needs, when you need it.
Learn how to create a development process that’s self-regulating, with an engineering team that manages itself—free of busywork-generating QA or nagging project managers. Sign up now for our two-day project roadmap workshop.