Business-Driven Engineering

Burn down charts are a common feature of SCRUM and Agile. This particular chart is an ideal that is never reached as technical debt piles higher and higher.

The idea of business driving the software engineering tasks that one undertakes is common in Agile/SCRUM companies. Unfortunately it isn’t always a wise idea to let the least technical people drive the decisions that go into designing and implementing a piece of software such as a web application.

The flaws of SCRUM and Agile are explored in this article.

Scrum in its purest form puts all of engineering at the same low level: not a clearly spelled-out one, but clearly below all the business people who are given full authority to decide what gets worked on.

This is a common complaint that we hear from software and web developers: they aren’t given a choice in what they work on, no matter how much experience or seniority they have. They’re expected only to work on what the marketers or managers expect them to work on. This is especially true if you are a developer working in an agency environment or as a freelancer where the client expects you to only work on things that they want and understand. Unit testing, a reliable build and deployment process, documentation, a better design, research: all of these things will be downplayed and ignored by managers and clients and software developers are routinely denied permission to work on those things.

In contrast, no one questions whether certain tasks that a lawyer, doctor or engineer does are worthwhile. A lawyer’s clients don’t tell the lawyer to avoid doing certain research because it costs too much money. An engineer’s manager can’t tell the engineer to skip over a bunch of safety inspections to save money. In the IT industry, software developers are routinely told what to do and what to avoid in order to minimize costs.

Business-driven engineering is also very short term and planned out in short sprints in the SCRUM methodology:

Architecture and R&D and product development aren’t part of the programmer’s job, because those things don’t fit into atomized “user stories” or two-week sprints. So, the sorts of projects that programmers want to take on, once they master the basics of the field, are often ignored, because it’s either impossible to atomize them or it’s far more difficult to do so than just to do the work.

Any developer that has a few years of experience will want to spend a bit of time researching new libraries, frameworks, techniques, etc. and they shouldn’t have to justify that sort of skill development time. They shouldn’t have to try and break down the research into little bits and pieces to fit into an arbitrary 2-week schedule.

One other common complaint we’ve heard from software developers is that they don’t feel any progress is really made on projects. That it’s an endless slog of working on features that no one really cares about and never getting time to fix technical debt:

Under Agile, technical debt piles up and is not addressed because the business people calling the shots will not see a problem until it’s far too late or, at least, too expensive to fix it. Moreover, individual engineers are rewarded or punished solely based on the completion, or not, of the current two-week “sprint”, meaning that no one looks out five “sprints” ahead. Agile is just one mindless, near-sighted “sprint” after another: no progress, no improvement, just ticket after ticket.

Read more here.

Be the first to comment on "Business-Driven Engineering"

Leave a comment

Your email address will not be published.