How can we ensure the development of a good software which is able to evolve and change alongside with short delivery times?

Submitted by Andreas Schliep on 05/21/2013

"As you usually work with User Stories in Scrum and the Product Owner is actually not interested on the technical part of the implementation, you would think that the focus of the implementation is always on the Sprint content and the reusability aspekt is often ignored, especially if it means additional work. How do you see that? How can you develop products with a good architecture which is able to evolve and change if you should deliver shippable products or product parts in short periods of time? ..."

My experience comes mainly from the company's internal web development. In my last team they sometimes had 2 different story point estimates which were presented to the PO: one for a generic, reusable solution and one for a function-oriented low priced implementation. Usually this information came with a remark that the low priced implementation would mean additional investment for the future implementation of one of the User Stories in the uncommitted Product Backlog. The PO had to decide in favor of one of the possible implementations. As we usually had a release of a new product version at the end of each sprint, the decision of the PO was from case to case different. From time to time he chose a low priced implementation so that he soon could test, if the planned feature was used and accepted by the user at all."

It's typical for the web development. I know this kind of discussions very well from various coaching cases. Actually the team and the PO should work together on the definition of the quality requirements they want to follow. Thus, for example, is the continuous refactoring never up for debate. A splitting into generic components and functional implementations always has a non-Agile aftertaste. I would reserve such a splitting only for the cases when the generic compontent itself is of a high value – for example, it should be the basis for a variety of functions.

Reusability, conceptual integrity, and other non-functional requirements are quality characteristics (constraints or acceptance criteria) to define, as well as many others. A good team implements these requirements again and again through repeated and consistent refactoring within their test-driven development cycle. Besides KISS and YAGNI already known factores are to be considered if they can not be rebuilt again later without much effort. The creation of quality always causes the constant improvement of the code base. In a classical approach once written code may be considered as finished - the above Core fulfills its tasks perfectly and does not need to be adjusted. In iterative and incremental development only so much of the core is developed in the first sprint, that a certain simple functionality is realized across all layers. The core is adjusted in the 2nd sprint, maybe even functionalities from other modules are moved to the core, because they make more sense there. Thus no long initial "architecture sprint" is needed. Too much investment into extensibility destractst from the user stories, too little refactoring, and a lack of architectural vision, however, lead to not maintainable code. The task of the architect is to accompany, facilitate and moderate the balance between function-driven development and solid software architecture.

Andreas Schliep

About the author

Andreas Schliep

Andreas Schliep is a founding member and executive partner of DasScrumTeam. He is a Scrum coach and trainer. He studied at the technical university of Bremerhaven, and worked as a software developer, project manager, team lead and group lead. Andreas has worked with Scrum since 2003. He became a full-time Scrummer in 2006.

Since then, he has helped to introduce and improve Scrum and agile practices in numerous companies all over the world. His favorite topics are quality management and scaling.

  • Experienced ScrumMaster, Product Owner, Coach and Trainer
  • Introduced Scrum at WEB.DE
  • Coaching of internationally distributed teams
  • Transition from RUP to Scrum at UOL Brazil
  • Scrum Trainings and Coaching in Germany, Switzerland and Austria
Tags