Get certified - Transform your world of work today

Close

Would You Eat Your Hamburger Layer by Layer?

Business versus architectural orientation when setting sprint goals

27 April 2017


Every time I begin a new project, I face the dilemma of how business oriented I should be in my approach and strategy. I leave the architectural questions, such as data, information flow, and infrastructure, to be addressed in sprints or defined as acceptance criteria, as needed. Do you remember the quick-win age? We all know the trade-offs of such decisions.

Based on everything that we have learned so far about software development, the answer is trivial: Business is paramount. We all agree with this thinking, but we also know that the cost of rework (e.g., time and money) must be first understood and then shared with the stakeholders who finance the project and who must also be multidisciplinary.
 

Strategy

For the sake of this debate, let's assume that we have three prioritized user stories (among many others), which total enough points for three sprints. These stories are expected to build the following components:
  • Three front pages that sustain the business flow (e.g., search, detail, and sale), whose user experience must be determined and prototyped before coding
  • Services/APIs supporting the front pages
  • A series of database CRUD (create, read, update, and delete) cycles
It's debatable which of these approaches I should follow:
  • Vertical approach: Run through one business flow before starting the next.
  • Horizontal approach: Plan and build components separately and then merge them in the last sprint. This approach requires mock-ups and individual tests that would be unnecessary if the vertical approach were chosen.
A hybrid approach might be an alternative.
 

Considerations for determining a business or architectural orientation

Deciding between a vertical or horizontal approach is complicated. Here are a few important points to consider.
 

Effectiveness of sprint reviews

Formal approvals are a fundamental part of Agile/Scrum. The sprint (and also the planning) ritual will be much more attractive and real if we choose the vertical approach. Remember that we aim for gradual/verifiable business increments. This is a valid approach, even if we know that such approvals may be revised in the future if we find holes in the architecture when other flows are being coded.
 

Rework and risk of coding on top of an under-dimensioned or inappropriate architecture

When a business flow is finalized, how can you be sure it is ready for a rollout before touching the next flow — that is, will it work for many or all? It's very seldom that the stakeholder will understand and accurately estimate this risk, and the responsibility of managing the expectation cannot be exclusive to the product owner role. That's why stakeholders must also be multidisciplinary to the extent that they understand and deal with the consequences of the decision to roll out a business flow.
 

Teams positioned to deliver business results, without a horizontal view (i.e., more focused on quality and performance)

Despite what the framework says, a self-organized and multidisciplinary team is not what I've found in my experience. To get there, I'd have to invest a lot in education, team preparation, and shift in culture. A robust and efficient architecture cannot always be built on the basis of trial-and-error or start-small-grow-later. This works for adjustments. Watch out for barriers and limitations of your initial and quick designs.
 

Nature of test procedures

If you choose the vertical approach, you have one sprint to deliver something usable. How will you invest the time you have for testing? Chances are that you'll apply more effort on black-box tests, especially if your level of automation is not what you need.

By using the horizontal approach, you can afford to spend time on the individual testing of components, and, if done wisely, you will make your black-box tests more effective and less frustrating.
 

Know the creation process and culture of your company and team

Never forget the reason you started the journey.

There are companies that handle the sense of urgency much better than others, so they are used to the pitfalls listed above. Others do not, and are not. These companies understand failures as catastrophic, which they are not.

Stick your flag in unexplored territory. It may be just what you need, even if the flag is ripped and dirty.

Any comments?
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (1 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe