A common issue development teams face when first transitioning to using Scrum is holding onto parts of their old processes. This is especially difficult for teams that are used to a waterfall model, where technical design and architectural implementation are the very first steps after the specification is written. People who are new to Scrum have an instinct to keep the technical design and architecture phase up front and then move to a Scrum process for the remainder of the project, but this leads to not taking advantage of all that Scrum offers.
This doesn’t mean you should go from doing the whole design upfront to no design upfront, but that you should do something in between. Doing so allows for design changes later on that are typically challenging to execute to become far easier and helps everyone remain on the same page. It sets your team up for success and helps to reduce risks along the way, just like a walking skeleton.
A walking skeleton is a basic set of code that acts as a “starter pack” for the development team. It’s a lightweight application framework without any product-specific functionality but that is still runnable and can exemplify the fundamental architectural patterns. It is essentially the simplest thing that could possibly work.
Completing a walking skeleton before the first sprint provides development teams with several important advantages:
- It puts some architectural building blocks together, exhibiting structure and patterns.
- It establishes the fundamental technologies and proves the basics work.
- It provides fodder for continuous integration and automated deployment.
- It can establish a common framework.