I posted the first two articles in a series of three this morning on the subject of “Complexity-Driven Development”. The titles of these pages are “Complexity-Driven #1” (https://charliealfred.wordpress.com/complexity-driven-1/) and “Complexity-Driven #2” (https://charliealfred.wordpress.com/complexity-driven-2/)
The inspiration for these articles was a meeting held at my company several weeks ago. One of the topics was: “Should we make SCRUM be the company standard development process?” Now, I am a huge fan of SCRUM and its focus on backlog, iterative development, and daily standup meetings, as well as its requirement for the Scrum Master and Product Owner roles.
But somehow, the question didn’t seem like the right question. Town meetings are a great idea, too, but I am glad that every municipal decision doesn’t require one. It was clear that SCRUM should be used where SCRUM fits, and so should written architectures, prototypes, design reviews, and performance benchmarks.
But the question that lingers, is “how do I know what fits?” I’m not sure that “use your best judgment” is the most effective response. Over 30 years, I have seen several development projects choose the wrong path, in the name of schedule pressure, religious zealotry, or just the desire to add a new technology to ones resume.
No, I felt that there had to be a more systematic way to answer this question. And thinking about this led me to the conclusion that complexity (and its first-cousin challenge) is the primary thing that makes software development projects different from each other, and forces them to tailor their approaches.
My hypothesis was that if we could come up with a systematic way to discover and assess sources of complexity in development projects, we would take a big step toward consistently choosing the right approaches.
Complexity-driven development is a meta process. It is a process of better understanding the complexities in the problem space, with the goal of choosing or constructing the right process for that problem.