In our previous article, we emphasized that software architects working within an Agile framework need to be receptive to ongoing changes and continuous feedback. This necessity arises primarily from one central focus – the delivery of continuous value.
Delivering Value with Agile
Adopting an Agile approach means our primary objective is to deliver continuous value, which isn’t always in the form of a completed feature. For instance, suppose there’s uncertainty about the feasibility of a task. In that case, we can formulate and test a hypothesis to gain insights into the issue. This investigative process delivers value to stakeholders. The insights derived from the research inform us whether a task is achievable or not, thereby enabling us to make data-driven decisions and take informed actions.
Initiation and Conclusion of the Design
In order to answer the question of when to initiate and conclude our design phase for maximizing value delivery, let’s revisit the Software Development Life Cycle (SDLC). Typically, it’s segmented into six primary phases: planning, requirement analysis, design, development, testing, deployment, and maintenance. Within the Agile framework, we cycle through these stages repeatedly since we incrementally implement solutions. Consequently, we are continually engaged in the design process as we add new features. The design phase concludes when the solution is either complete (if such a point exists) or ceases to add value.
Divide and conquer
“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one.”
Mark Twain
Drawing from my experience, customer-expressed problems often carry an element of ambiguity, which may be attributed to the scale of the issue. Frequently, the identified problem is expansive. In such instances, it’s beneficial to break it down into smaller, more manageable sub-problems. This approach not only simplifies the resolution process but also ensures accuracy in our efforts. Moreover, it allows us to adopt an incremental problem-solving strategy, enabling us to gain feedback with each resolved sub-problem.
Designing involves not only resolving problems but often identifying them as well. My recommendation is to first accurately pinpoint the problem, which necessitates validating the identified requirements. Once done, select the crucial requirements that the design solution will address. These chosen requirements will guide your architectural decisions effectively. The elicited requirements should be chosen based on the scope of the current iteration, meaning different requirements will be addressed in each iteration. In upcoming posts, we will delve deeper into this process of identifying and selecting the correct architectural drivers for each iteration.
Join the Conversation: Share, Learn, and Grow
As we continue to explore the nuances of software design within an Agile framework, your insights and experiences can enrich the conversation. I invite you to share your thoughts, ideas, or questions in the comments section below. Have you faced similar challenges in your projects? How have you addressed them? What strategies have worked for you? I look forward to engaging with your responses and learning from your experiences.
Remember, a shared problem often leads to a shared solution. Together, we can continue to refine our understanding and enhance our practices. Let’s learn and grow together in this journey of continuous improvement.
Stay tuned for the upcoming posts where we’ll dive deeper into the process of identifying and choosing the correct architectural drivers for each iteration. Thank you for reading and contributing to this discussion.
-Carlos.G