Should a project team be organized based on the architecture of the system? (A manifestation of Conway’s Law). Many practitioners and commentators argue that teams should be organized around delivering a complete ‘vertical slice’ of the architecture. That is, a scrum team, which is typically 5-8 people, should have all of the skills necessary to deliver a complete customer-facing feature of the system. Many go further and argue that the skills within the team should be interchangeable, and that all of the code should be shared so that anyone of the team can maintain anyone else’s code. I’m not sure the answer is so simple. Would it be OK with you if the plumber did the electrical work on your new home construction, or if your orthopedic surgeon volunteered to do that little bypass job while the cardiac surgeon was on vacation?
I guess the decision might be driven by the complexity of the system, and the need for specialists, or perhaps also influenced by the application domain. At some point the skills are not interchangeable. Say your company supplies network infrastructure equipment (routers, CMTS’s, video streamers) to network or cable service providers. Your network management platform is based on java enterprise architecture. Your database stored procedure guru may not be at all qualified to make changes to a user interface, especially when overall system usability is a critical factor for the customer. And within your team that does embedded development, for say the core network router, you hardly want the hardware device driver guys to be tinkering with Djikstra routing algorithms, no matter how talented they are.
I think I’ve belabored the point enough. The answer to the original questions is: there is no single right answer. However I think the question itself is a little misleading. A better question is: should the output of a sprint be a set of user-facing demonstrable features? Answer: Absolutely! The next question is about what is the best way to organize the team to meet that goal, and the answer is that it depends. For a large complex system, is it sometimes necessary to organize around components of the system architecture? Answer: definitely yes!
Let’s look at a simple application to illustrate some of the issues. We have been asked to build an on-line diary application. The application is to be used as an on-line diary, event organizer and contact manager.
- User Registration, Login functions
- Interactive calendar interface for entering diary entries and scheduling events
- Contacts manager
These high-level requirements (Epics) could be broken down into more detailed User Stories as follows:
Let’s say we design this as a typical 3-tier architecture:
- Presentation layer comprising a set of forms and navigational elements
- Business layer comprising several classes (Diary Class, Contact Class, DiaryEntry Class, and DiaryEvent Class). These classes abstract the underlying data layer, and provide a set of methods for storing and retrieving data associated with these objects.
- Data Access Layer. Basically a set of stored procedures that both the business layer and presentation layer can use to interact with the database.
Let’s also assume we have specialists responsible for constructing each tier of the application. Sprint planning involves taking each User Story and breaking it down into tasks, which are typically estimated in hours of effort. Work may be required on each ‘layer’ or ‘component’ of the system to deliver each user story, As we plan out the work in detail for a sprint, we may need a breakdown like the following:
When we get through all that, we may end up with a view of the sprint plan that looks like:
In a large project we may have entire teams of UI designers, database designers and so on, and the organization may be based on these skills-based teams. Furthermore, these teams may be located at different sites, which may be in different countries and time-zones. In part 2 of this article we discuss how scrum can be effectively applied with distributed, component-based teams.