Down the rabbit hole of choosing a software development process

When developing software, do you start with methodology, framework, practices, models, activities? There are so many variations on how to orchestrate a software development process. How do you decide which one is best for you, and once you figure it out, how do you implement it?

The are many white papers, posts, books, and Wikipedia articles on the various software development processes and this is not going to be another one of those. This is rather my account for the landscape we currently reside in and what history is applicable to make decisions on what processes to implement. Here are my answers to questions you have often thought about but didn’t know what to do next.

How do I choose between traditional Waterfall or one of the many contemporary variations of Agile?

Myself, like many, got a start in the software development world not knowing any token words for processes or methodologies. However, somewhere along the way, I started hearing about something called Agile. From that point forward I began learning about the Agile process. The more I learned the more questions I had. What are alternatives to Agile? What is what I'm doing right now called? Another token term you may be familiar with is Waterfall. Or perhaps you’ve been in the industry long enough to start with extreme programming or other methodologies that have existed for a long time, but with the latest Agile trends have been resurrected. This is the junction where many reading this post are asking, how do I choose? Waterfall and “Agile” are very different paradigms with various methodologies within each so start by choosing your high level paradigm based on which one address your challenges and fits with your organization's culture the most. Based on the challenges I was trying to address I chose the Agile path and down the rabbit hole I found things like SAFe, DevOps, XP, Scrum, Kanban, TDD, and CI. Before I go on I want to share with you how I’ve seen this landscape organized in which there are many publications and Wikipedia articles, but these categories have resonated with my experience.

How do you define what to use for an organization and how do implement the change? I found choosing a software development process is like choosing a religion or a political party. There is often more overlap than there are differences. Start with what they all have in common. Who has been to a SAFe talk without hearing about Scrum or a DevOps talk without hearing about XP? What did they all have in common? Aspects of agility to manage changing requirements, faster time to market, automation, and enhanced development practices. If any of these resonated with your organizations challenges then perhaps agile is worth exploring.

Can you truly just pick one? Only at first but in the end the answer is no. The reality is, all the contemporary processes are similar to each other. However, they have one common denominator...their clear polarity to Waterfall. While Waterfall is sequential in nature the modern processes are not sequential and they can't even be rolled out in a sequential fashion. You must choose a paradigm, but once you do the methodologies, supporting disciplines and practices you implement will organically fall into place. Choosing where to start is as simple as deciding where your greatest weakness or obstacle lies. Once you arrive at this point, you don’t worry about choosing one over the other, you begin to choose the pieces that they all share in common.

How you should you implement multiple strategies? Follow Shuhari. Shu-ha-ri is a Japanese martial art concept which describes the stages of learning to mastery. “Shu” is about following, or obeying, and learning fundamentals and techniques. “Ha” is about detaching from tradition and finding new ways and techniques. “Ri” is where it all becomes fluent and you separate or transcend the fundamentals and form new complex integrated techniques.

• Shu. You must first start with knowing what Model seems to solve your biggest problems. Within that, you need to build on a foundation (Shu). To do this first pick a paradigm that fits your organization's culture and drives your objectives. Next pick a methodology within that paradigm that can give your team the basics.
• Ha. Once you have the basics it's time to start honing in on areas for improvement. At this point, you start to adopt practices that may be used on other methodologies within your paradigms like CI, ATDD and even tools for build automation or test automation.
• Ri. Once you have the foundation and you have broken away from that to adopt specific practices and tools you can begin to transcend into a full methodology that suits your organization. This may closely resemble SAFe, or Scrum, or DevOps but in the end, it will not be 100% of any defined methodology but one that is unique and mastered by your organization.

While this path is often more complex when choosing Agile over Waterfall that is simply because Agile is not really a model but rather a way to follow the “Manifesto for Agile software development”. As this manifesto is about values and not processes, in being agile you are free and I would even argue required to adopt bits and pieces of many frameworks, practices, and discipline. Either path you decide keep the Shuhari approach in mind to allow your organization to mature into your process rather than struggle to follow one to the letter.

Rather than make a short story long, if you are interested in how my trip down the rabbit hole has played out please comment on this post and I’ll be sure to notify you when the next post is up which includes an agile approach that uses Scrum, DevOps, XP, CI, and ATDD and while is is not SAFe it is certainly allows for complex release plans.