I have been thinking a lot about implementations of Scrum in several past clients and how proper software architecture has been incorporated. In many of those implementations, software architecture had been left to the team without much discussion amongst the team about approach or vision. Many teams lacked an architect role.
I ran across an old debate on LinkedIn while doing some research on proven ways to bring a better approach to software design in Scrum. The post was titled “Is SCRUM good or bad for Software Architecture?”.
There are some great comments in this thread that stuck with me:
“Architects and Product owner should work in tandem before moving items to backlog.”
I often recommend to clients who are having difficulties with their software development life-cycle and increased technical debt because of design process issues is to begin to “groom” their backlog. This aligns with the comment above.
In the pre-planning phases of stories, an architect can initially set the technical vision. During sprint planning the developers should challenge that vision. This isn’t to create adversaries in developer versus architect, instead it encourages collaboration to provide the best solution for the story and for the overall system. Communication is vital among team members on a Scrum team, and for architecture discussions this would be no exception.
“If you’re finding that system architecture isn’t a concern, then there’s a problem with the interaction side”
Agile methodologies stress the importance of transparency and communication. If discussions are not taking place about proposed architecture at some level then in most cases architecture consists of mismatched patterns (and lack thereof) as developers contribute to the overall work amongst many different styles.
While all this code may be well written and functional, the overall vision is lacking and not communicated. This type of communication can be difficult as pride of contributions for work becomes a factor. It helps to set guidelines around these discussions. The role of architect on the team can minimally facilitate these discussions of guidelines and the difficult conversations related to the solution architectures.
“Many stories are so simple that developers can attack it straight, following patterns already known. Others, presents concepts breaking abilities. The most important is having your auto managed multi-functional team prepared to identify these gaps and take care of them without escaping the methodology.”
I found this to be true in regards to a majority of stories. These stories need little to no discussion as the patterns and processes to apply are relatively straightforward. Those story points of ½ or 1 point seldom need exhaustive discussions about proposed implementation.
However, again to not have these discussions can create gaps as indicated in the quote. I found that either pre-planning or providing enough time during planning for the development team allows all assumptions to be communicated in the open for eventual consensus.
In working on many Sitecore efforts with agile teams, I learned it is important to determine to talk through story implementation as it not only affects the website outcome, but the outcome for the content editor as well.
“Architecture, design and documentation should be required deliverables or every project, regardless of how they are managed.”
Architecture and design always are created – regardless if they are discussed or not. One principle of the Agile Manifesto is “Working software over comprehensive documentation”. But each implementation of Scrum I’ve come across has a different definition of done. Most do include some type of documentation, either customer user guides, technical definitions or both.
I am a believer of documentation. It seems to work best when there is a process and discipline to keep the documentation constantly maintained and reviewed. It is easy to focus on delivery of features and bypass the proper recording of system history for others to refer to.
“In my opinion, not enough architectural knowledge (e.g., diagrams) was allowed into the Scrum process to help the team adapt over time. Spike deliverables were simply not enough to drive architecture change that was needed.”
I have come across this problem as well. Depending on the organization and its culture, those spikes would benefit to have their acceptance criteria modified to include basic UML diagrams as part of the delivery followed by a discussion with the team. The team should decide how much architectural knowledge is enough. The role of architect on the team provides the appropriate representation.
“My opinion is that Scrum accelerates inevitable and eventual architectural decay.”
I disagree. The team accelerates architectural decay more than Scrum itself will. When the appropriate architecture role is included and is engaged with the rest of the team, architecture should not decay and should adjust to change like every other facet in an agile practice.
What are your thought in regards to software design and Scrum?
