Agile, Microservices and Buzzword Bingo
I know folks that go bananas every time someone says something like “you cannot set a date, that’s not how Agile works”, “we have a microservice architecture.” or “you have to have a good CICD pipeline!” The Agile comments seem to be particularly frustrating to folks that have been in the IT business for years but never have seen software continuously delivered. I’ve often heard things like “Agile is the same thing we introduced 20 years ago and we just called it this-or-that.” On both accounts, it is my suspicion that these folks have never seen a microservices architecture successfully deployed or an agile practice properly executed. Buzzwords are mildly annoying in general, I get it, but these are important concepts that should be very familiar to every software director.
Agile:
Agile is not the same thing that was practiced 20 years ago. Waterfall and traditional project planning simply don’t take in account the unique qualities inherent to software development. Software doesn’t have the same constraints and limitations as the construction industry and we shouldn’t treat them the same. Software is mutable and flexible; it can change as quickly as business needs change. Agile and its iterative properties embrace software’s flexible nature and encourages reprioritization and change.
That said, Agile cannot fix a broken software development department simply by having teams utter Agile buzzwords and having standup meetings every morning. Teams need to practice good habits and most importantly focus on what their business partners have declared as priorities. If you’ve been on a team or led a department that Agile-washes things but doesn’t deliver, blame the leadership or the lack of it, don’t blame Agile. Doing Agile halfway creates a situation that’s frAgile 😉
Microservices:
The best thing since sliced bread, microservices limit the scope of any piece of software and increases the testable surface area to nearly 100%. A lot of teams have attempted and got stuck in the middle of a migration to microservice architecture – c’mon finish that! But, the beauty of microservices are that they can happily live side-by-side with the glorious legacy monolith. Often times my teams have successfully implemented microservices to affect a strangulation strategy of a large chunk of legacy code: offloading more and more functionality to the microservices until the legacy code simply ceases to exist. Other times a microservice will grow larger and larger with responsibilities until there becomes a clear distinction of what the overall system actually needs and then we refactor the bloated macroservice into several constituent microservices. #expansionandcontraction #emergentarchitecture
On the flip side, I’ve known teams that love their monolith and some teams that have done wonderful things with a large chunk of code. The key here is that the code needs to be runnable on your local computer, thoroughly testable and easily deployed to PROD. Microservices simply lend themselves to these goals but if your code, regardless of size, accomplish these things you are on the right track.
Bingo-Bongo:
If your team is underperforming or not meeting business goals you have an obligation to understand these new paradigms and find out what the buzz is all about before dismissing them as fads or reincarnations of something old.
More Reading: 12 Factor Development, First Break IT, Agile Manifesto, Scrum, CICD pipeline