Fix Software Development by Solving Problems

I’m sure many of you subscribe to various “tech blog” type outlets – TLDR, Medium, Substack, etc. My current Medium algorithm has been pushing posts that generally bemoan various software development approaches, in particular, the Agile methodology. I’ll skim through them and walk away disappointed since many complain about the process, shortcomings, failures, etc. I’ve seen Agile (and SAFe Agile) attempted to follow the letter of the documented process and it is terrible – doing process for process’s sake is wasteful. But as an outside observer of these experiences, I really think that the problem the authors are sharing is their company/team’s implementation. One of the glaring items that these authors seem to complain about is, essentially, that all the process around Agile is worthless and developers should be able to just continually iterate on features. I’ve heard this on multiple projects as well.

That should cause all of us to pause.

First, the easy part – if you are trying to implement or use the Agile methodology and you haven’t tailored it for your specific project, you’re doing it wrong. I’d say the minimum is doing some sort of sprint planning, some sort of periodic checks on progress, and some sort of sprint demonstration/close out. I’m not hard over on daily scrums and I’ve led teams that have implemented “no meeting days” and our scrums those days were virtual where “What did I do? What am I going to do? What blockers do I have?” were just dropped in the team internal Slack channel and addressed asynchronously. Your implementation might (and probably should) feel slightly different.

Next, we need to channel good, core software engineering practices with a specific focus around when in the lifecycle of development does a problem or defect cause the least impact. Clearly it is in the design phase – not implementation. Even better practices are defining and understanding what the problem is that the team is solving to address the problem from the start. This is a direct poke at those that think “agile development” should just be developers banging away at feature after feature in an iterative fashion. Adding features isn’t solving a problem. Whatever software methodology you adopt, it should define the problem that you need to solve. Once that is achieved, development should stop. There should be no "continually iterating." That doesn't mean the development team goes away - the Product Owner and leadership should be lining up the next project, service, feature, etc. for the team to address.

As part of the inspiration for this post, I was reviewing my bookmarks (we all have a saved set of bookmarks that we carry with us, some of which dates way back, right?) – and I landed on this talk by Rich Hickey, the author of Clojure. As a side note, I might be biased here because one of my first programming languages was valForth which has aspects of Lisp and Clojure. I rewatched the video and it still is relevant and resonates. I highly recommend those in the software development field give it a watch. He distills down these issues and teases out, without quite using those words, the User Centered Design approach that we use at Iron EagleX, Inc. (a GDIT wholly owned subsidiary). Pay close attention around 7:18 into the presentation:

Programming and writing software is not about completing lists of features in particular features provided by users in spite of their best efforts to satisfy themselves are often really not good ideas. You’ve got to dig underneath it and figure out what problems they have and what’s the best solution to it.

I’m not going to rehash what Rich Hickey presents – go watch it. But I would challenge you to implement it. Be a “solutionist” and solve your customers problems…stop just iterating on features.