Chapter 6. The Influence of Architecture Vision on Team Velocity and Software Quality (*)
The title of this chapter may sound technical, but we hope we have presented the information in such a way that even the nontechnical person can understand the concepts covered in this chapter.
Because it is very important for everyone on the Scrum team to understand what is meant by architecture and architecture vision, let’s take a few minutes to define what we mean by these two terms before we move forward.
Imagine for a moment that you are trying to pay for the construction of your dream house (your new software product). Of course, you would not want the construction crew to just show up one day in front of your empty lot and start their building work (coding).
You would first want to meet with the builder team members to tell them what your vision and needs are for the house (the software product). You would tell them, for instance, that your vision is to have a two-story house with as many glass windows as possible (user stories or requirements).
You might also tell them that you plan on having one more child in addition to the two children you already have (another requirement). As for your other requirements (software product requirements), you might also say that you want the children to live downstairs (a constraint) because you cannot bear the noise made by children running and jumping around over your head.
What the builder team will do upon hearing these expressions of your needs or requirements is to create some kind of drawing (architecture vision), at a high level, of how the house should look and how the main elements will be arranged.
This is how the builder (software developer) is going to get some idea of what they should do and where they should do it (architecture built over time).
The high level drawing resulting from this vision of needs is what we call an architecture vision, or high level architecture blueprint, while the end result of the team’s construction work will be the house architecture (software architecture), some sort of main frame supporting the house as a whole.
Now, going back to what we were discussing at the beginning of this chapter, one of the most interesting things we have observed on different Scrum projects is that team velocity (the number of user stories the project team can deliver per sprint) often fluctuates for quite a while. And the more complex the project, the more team velocity is going to fluctuate, resulting very often in the reduction of the team velocity and, therefore, their ability to deliver.
There may be many reasons for this but one of the main causes, from an architecture perspective, is that teams are often busy trying to figure out or fix their software architecture on the go. Because of this, their velocity often fluctuates as seen in Figure 6.1.
If you were to build a small website or trivial application (a dog house to continue with the construction metaphor), this fixing may not be too time consuming, but if you are building a large application, these fixes on the go can take a lot of effort and time. They might also cause some of the functionalities previously delivered to need to be redesigned and all the tests to be rerun. The tests themselves might also need to be modified prior to being run again.
Just a few years ago many software teams were excited about drawing architecture and design diagrams using all state-of-the-art tools and UML for Object-Oriented Analysis and Design (OOAD). UML for OOAD is a good technique, but sometimes, too much is too much, especially when all of that hard work only results in beautiful paper documentation and not enough working software.
But having no design at all, even in intent, will be just as harmful to the team productivity and effectiveness, possibly more so.
Scrum or not, you should have guessed by now that a good architecture vision is a key element in software development, even if you have to build it as you go.
With a clear architecture vision, something similar to what others call architecture intent, what happens is that the team may be somewhat slow at the start of the release or sprint. However, their velocity usually goes back up quite quickly and stays at a pretty good level as seen in Figure 6.2. This increases the team confidence and ability to perform over the long run.
From a technical perspective, where there is no architectural vision, what the developers normally get from the Product Owner is a big chunk of user stories (Figure 6.3) to work with without any idea of what the final product will look like or even how the different components will fit together.
From there, the reason team velocity fluctuates so much is because the team will be tempted to try to move all the small rectangles (representing the user stories), very often one by one, into their proper locations. Figures 6.4, 6.5, 6.6, and 6.7 illustrate the time and effort it will take the team to work without architecture vision.
What is interesting to observe is that their effort will ultimately lead them to an architecture (Figure 6.7) that is the same as the architecture which the team could have laid down had they decided to spend a little time at the beginning, figuring out the architecture vision first and not hurrying to get into the sprints with all their detailed stories.
In order to arrive at this architecture vision, there are two things the team can do. One is to look at the product vision and goal to identify the main business data that would support that product vision, or pertain to that business domain, as some experts put it.
An alternative would be to use the visual high-level requirements gathering technique presented in Chapter 4, “A Visual Requirements Gathering for the Product Backlog,” to see which core user-visible stories share the same common business data grouping. For example, all book reservation stories should have some common data related to the book and its characteristics.
This does not mean that all the user stories with the same data should not necessarily be built together, but they should at least be candidates for being built together.
Following this strategy, the team should be able to identify user stories that can be clustered based on common business, therefore stable, data elements as shown in Figure 6.8, with the core elements being in the middle ring.
After this first grouping, the team will want to split up the stories even more, to separate the ones that are to be created from the ones that are to be updated, read, or deleted. This is illustrated in Figure 6.9.
If they wanted to, the team could next split up the user stories one step further, as shown in Figure 6.10.
The advantage of all of this additional effort is that the team can eventually organize the development in parallel or concurrently, as shown in Figure 6.11. This is similar to the way teams organize their work in kanban, a lean technique, famous for its contribution to Toyota Production System (TPS), and which has attracted quite a bit of interest in software development, especially in software maintenance and support.
In addition to this benefit, another advantage of organizing the work by common data elements is that as long as the core data elements are identified and worked on first, the product owner can re-prioritize, switching between detailed user stories as shown in Figures 6.12 and 6.13, without this reprioritization having an impact on the team velocity. This is true as long as the team had laid down the data foundation by doing all the creations for all the base data entities first.
In addition to the previous benefits, identifying common business data early on can also bring in an additional benefit to the team in that it will likely help the team lay down some kind of good and stable data architecture. This is essential for good data warehouse reporting. Unless your application is the only one that your company has, this will help your application easily fit into the enterprise data architecture along with the rest of the company’s applications.
As before, you have here two possible ways to create the data architecture for your library application. The first is to do it horizontally as shown in Figures 6.14 and especially 6.15. In Figure 6.15, an extension has been made to the first data architecture layer by adding “Teen Book” and “Toddler Book” sub-types to the Book type and by adding the “Woman” and “Girl” sub-types to the Patron type, which already exists in the current data model.
Another way is to work vertically, as shown in Figures 6.16 and 6.17, by working on a new data entity type at every sprint. You would first add the Book concept during the first sprint, then add the Patron concept during the second sprint, and then add the Day (Calendar) concept during the third sprint, and so on.
Both strategies will evolve into the final data model shown in Figure 6.18.
When closely examined, we can assume that the data model in Figure 6.18 will have all the relationships and cardinalities as the data model in Figure 6.19.
Figure 6.20 is an extension of the previous transactional data model with two new entity sub-types, Teenager and Adult, added to the Patron type.
Figure 6.21 shows how you could construct the star schema for this application. You first add a Fact table, called Visit, to the middle of the model. You then surround it by the Quarter, the Patron, and the Library Location, called Dimensions, and which came from the transactional data model in Figure 6.20.
Figure 6.22 shows how your application will ultimately fit into the overall enterprise data architecture of the company. Rather than building applications in such a way that you can only hope they will fit into the enterprise architecture, your effort to lay down some kind of architecture vision could help ensure that your system will fit seamlessly into your company’s IT enterprise architecture.
As software professionals, many of us are accustomed to doing a lot of architectural design using all kinds of tools. Then along came eXtreme Programming, which dictated that we should only design as we go. The success of Scrum seems to have amplified this phenomenon.
Suddenly, no one seems to want to use the term architecture or design any more, lest they be considered to be living in the past.
But as lessons start to emerge from Scrum projects, it has become clear that without an architecture vision, the chunk of user stories the teams get from the product owner will look like a stack of cards, without any clear idea of what the final product will look like.
As a result, the team will have to spend time and effort trying to get the different stories to fit into some kind of blurred image of an ever-changing architecture.
With a clear architecture vision laid down at the beginning, one observes that team velocity does not fluctuate much, but instead increases over time. The team members feel more confident in their ability to deliver.
To arrive at this architecture vision, we must first identify user stories that share common business data and consider building them together. By splitting the user stories along common business data elements, the team will be able to organize their work and develop in parallel. This is something many software managers have dreamt of because they see the potential benefit it can be to team performance.
Working with common business data also allows the team to lay down some sort of stable data architecture, a key ingredient to good data reporting and analytics. Another benefit of this is to allow the product owner to change the project’s sequencing without negatively affecting the team’s velocity.