Charlie Alfred’s Weblog

SCRUM and Architecture – Partners or Adversaries?


This article considers the application of an agile method (SCRUM) and software architecture to the development of a new software system.  This software system provides courseware for language learning.  This article considers how SCRUM and software architecture exhibit positive synergy, and examines aspects of the courseware problem that contributed to the outcomes.  The specific focus was language learning, targeted principally at the U.S. Military.

Agile methods, like XP and SCRUM, are not typically linked with software architecture.  Software architecture has been associated with the complex deliberations of a problem and its alternative solutions.  By contrast, the agile methods approach is to embrace change and avoid BDUF (big design up front).  As a result, software architecture and agile methods proponents have historically been at odds.  However, in practice, the two approaches of software architecture and SCRUM seem to complement each other.  SCRUM is mainly an operational technique, with focus on product backlogs, sprints and daily meetings.  Software architecture has more of a strategic emphasis, focusing on contexts, value, challenges, and approaches.

Because this system is a diverse topic, crossing-over and integrating a variety of distant domains such as language learning, learning system standards, agile methods, and software architecture, it can be challenging for one to wrap their head around the nuances.  At the same time, each of these domains interacts significantly with the others, and forces which arise in one often have impacts that are felt in the others.  The paper is organized into the sections listed below:

Article Section



Relevance of Domains Cross Many subject matters can erode system comprehension
Overview of Language Learning Lang What are some issues and disciplines in 2nd language learning?
Overview of SCORM Learn SCORM is a world-wide standard for learning systems
Overview of SCRUM Agile SCRUM is a popular agile method.  How does it work?
Software Architecture and SCRUM Cross Conceptually, how can these two disciplines be integrated?
Big Design Up Front  vs. No Design Up Front Arch Waterfall wants completed design before coding.  Not Agile.
Is a Product Manager a Suitable Architect? Cross Does SCRUM give the right responsibility to the Product Manage?
How Many Questions are Too Many Questions? Agile Which questions should be asked up front before coding?
SCRUM and Architecture in TL CourseWare Cross Description of how we chose to combine these techniques
Summary and Conclusions Cross Which insights and lessons can we take away from this?

The codes in column two describe the primary topic for each section:

  • Agile         deals with agile methods and SCRUM, in particular
  • Arch          deals with software architecture strategy and approach (domain independent)
  • Cross        crosses over two or more topics and explores their interaction
  • Lang         deals with second language acquisition
  • Learn        deals with learning management systems and standards (cross-content)

 While this article is intended to be read serially, different readers may find it effective to jump around.  One likely case is where the reader is already expert in one or more of these domains, and wishes to skip the corresponding section.  Another case is where the reader is seeking to gather some insights, in say architecture or SCRUM, in order to assess their utility in their own problem domain.  In this situation, language learning and SCORM may be viewed as peripheral.

Relevance of Domains

Before examining the relationship between software architecture and SCRUM, we must first consider the impact of domains.  A domain is a body of knowledge with utility, a subject matter to be mastered.  It is multi-dimensional; it can be narrow or broad (cardiac arrhythmia vs. real estate); it can be low-level or composite (algebra vs. portfolio analysis).  Composite domains are a system of many child domains; some of which may be composite domains in their own right.

 Language learning software is a broadly focused, composite domain.  The broadness comes from varieties in communication mode (e.g. writing, speaking), the diversity of participants and in what context it occurs (teenagers on a playground, a CEO addressing industry analysts). 

 Three reasons why domains are so important and so relevant to SCRUM vs. Architecture are:

  1. The impedance mismatch between people communicating knowledge across domains is highly linked to the likelihood that something important will be misunderstood.
  2. The number and complexity of domains is tightly related to the overall difficulty of the system being built.
  3. Composite domains tend to strongly influence the general, low-level ones that surround them.  SCRUM and Architecture are low-level domains that are applied to composite domains that use them. 

 The importance of the first point in this list cannot be understated.  Language learning software, as a composite domain, includes and depends greatly on six child domains:

  • Pedagogy
  • Instructional Design
  • User Experience
  • Language Content Development
  • Software Development
  • Quality Assurance

 To visualize the importance of this set of domains, imagine six team members, each of whom are fluent in precisely one domain, and only have a vague grasp of the others.  In the following matrix the rows and columns both represent an individual with expertise in one of the domains.  The cells shaded blue eliminate the cases where a domain expert is paired with themselves.

conceptual distance matrix

 Next, imagine that each cell represents a conversation between two domain experts:

The $64,000 question is, “In what percentage of these 30 cases will the two conversation participants share common goals, common concepts/vocabulary, and a common understanding of the problem?  Of course, this is a difficult question to answer in the abstract.  The answer depends on:

  • How large is the communication gap between various domain pairs?
  • What fraction of participants is fluent or expert in many domains (translators)?
  • How challenging/complex is the topic of discussion?
  • To what extent do the domains collide (different values/constraints) for this topic?

Nonetheless, it should be evident that when a large percentage of the pairs suffer from communication challenges, it is very hard to have an effective team.  Management experts talk about the important of shared vision.  This usually refers to goals and team responsibilities.  However, without a shared understanding of the key challenges and how they constrain the solution set, shared vision is insufficient.  The participants find themselves discussing different concerns (with the other party not seeing the relevance) or suggesting solutions that seem viable, while the other party knows they are flawed.

 If not yet convinced, imagine that the 6 domain experts are replaced by ordinary citizens of Columbia, Egypt, Korea, Brazil, Croatia, and Thailand, who are separated by culture, education, and primary language.  The impact on communication effectiveness is likely to be similar.

 In summary, something that can enable development team members to have a strong common understanding of the situation has inestimable importance.  By this I mean shared understanding of:

Contexts              Where will the solution be used?  How do conditions differ?

Value                    What changes in benefit levels are perceived as most important?

Challenges          How do constraints and uncertainties limit value?

Priorities             Which capabilities, benefits or threats are most important?

Approaches         What are the alternative solutions to address each challenge?

Principles            Can we distill the various challenges and approaches into easy to comprehend rules or maxims?

 Software architecture plays a major role in ensuring this foundation is in place across domains.

Language Learning Overview

 Language learning experts differentiate between first and second language acquisition.  First language refers to the process which infants, children and adolescents go through to learn their native language.  Second language refers to the process that adolescents and adults (typically) go through to learn a second or subsequent language.

 Second language learning is a completely different process from first language learning.  The learner has their known language available to learn the second.  Many times this is a big plus. The native English speaker learning French associates bon with good and pomme with apple.   Other times this can be an obstacle, when the second language uses different idioms or formal/informal and masculine/feminine forms.  Pomme de terre in French literally translates as apple of the earth, which as everyone knows, is a potato.

 The CourseWare product is focused on second language learning, using English as the known language.  The primary emphasis is on building vocabulary, using declarative learning techniques.  The secondary emphasis is on using activities such as pronunciation practice to learn proper speaking techniques, and dialog reconstruction and multiple choice to learn grammar and style.

 There are four important domains that strongly affect language learning:

  • Pedagogy                      the art and science of teaching – why teach a certain way?
  • Instructional Design  creating instructional tools and measurement devices
  • Language Content      creating text, audio, visual, and image data for learning
  • User Experience          designing an effective and enjoyable learning process

SCORM Overview

The Shareable Content Object Reference Model (SCORM) organizes electronic learning around sharable content objects and simple content assets.  Simple content assets are just what their names indicate: media such as sound, video, image, documents that are used in a course.  By contrast, shareable content objects are composites that are managed directly by the Language Management System (LMS).  In other words, a lesson or assessment could be an SCO; a document or image is an asset; 

SCORM specifies three related models.  First, the CAM (content object model) shows how content objects and assets are represented and how course objects are aggregate into courses.  Second, the S&N (sequence and navigation) defines a protocol for determining the rules for moving through content objects.  For example, when a user completes a unit or lesson, what process and data are used to select the next one.  Third, the RTE (run time environment), specifies a protocol used by the learning client to report learning outcomes from client to LMS

 These models are integrated.  The S&N depends on the CAM.  And LMS’s can plug the run time events into sequencing and navigation decisions.  For example, the result of the current or previous outcome might be used to select the next course object.

 For as much as the SCORM standard does to help manage ways to enable a standard learning environment, there a still some significant issues:

  • “SCORM is not always SCORM”

Different LMSs implement this “standard” in different ways.  Unfortunately, this seems to be the case with all retro-active standards.  Different LMS vendors interpret them differently.  Also, several aspects of the SCORM API are optional by design.  Finally, different versions of SCORM (SCORM 1.2 /SCORM 2.4 v3) offer different API’s.  This includes new and deprecated data object names, changes in data types.

  • SCORM is not the only learning management standard.

There are alternate industry standards to SCORM (like Common Cartridge) that are popular in the university segment.  While these offer more capabilities than SCORM, some LMS’s implement both standards.

  • SCORM requires a specific RTE protocol, implemented in JavaScript on the client.

The RTE API lets any SCORM-compliant LMS communicate with any SCORM-compliant learning application.  Because there’s a many-to-many relationship between courses, learning applications and LMS’s, it is necessary for the RTE API to define a fixed set of methods and fixed data model.  In addition, specific rules are required (client/LMS) to name locate and deliver the RTE Driver.

  • The Learning Environment Must Support Connected and Disconnected Use 

In most electronic learning environments, learners use a Web Browser to connect to the LMS.  While this is a very convenient configuration to run and administer, one big limitation is that it requires that each user be connected to the LMS for the entire duration of learning interaction.  However, sometimes users must have access to course content when not connected.  To further complicate matters, a particular user might alternate between disconnected and connected modes, making synchronization a very big  issue. 

  • While JavaScript is a popular Rich Internet Application, it isn’t the only language

The development sponsor for the language learning product effort has mandated the use of Adobe Flash/Flex.  Also, Microsoft Silverlight can be used to program these types of web-based RIA applications with high-user experience, high-performing qualities.

In both examples, the learning application code must use JavaScript to interact with the SCORM RTE API.  The developer must implement a way to translate from the application programming model and JavaScript.  For example, in Adobe Flash/Flex, there are potentially three ways to call JavaScript from Flash, and they all have their own quirks.

SCRUM Overview

 SCRUM is an agile software development process.  By design, it focuses on short (2-3 week) development intervals (sprints).  During each interval, the development team (a.k.a. “the SCRUM”) focuses on a fixed set of goals and deliverables. The features in each sprint are a combination of the tasks estimates by the development team, and the priorities set by the product manager.

 Once the development interval has begun, only developers are allowed to participate.  This is the “chicken” and the “pig” metaphor.  In a bacon and eggs breakfast, the pig (supplier of bacon, ham, and sausage) is committed.  The chicken, who lays eggs, is merely involved. Developers who write and test code for each sprint are the pigs; other stakeholders, including the product owner are chickens.

 The major properties of the SCRUM process are:

 Clear separation of product manager and development team roles

  • Negotiation of deliverables in each sprint (product manager priorities, team estimates)
  • Change in goals or direction cannot occur within a sprint
  • Facilitation by a SCRUM Master, not management/direction by a development manager

SCRUM’s short time intervals permit the developers to work in a non-distracted, focused manner.  These short intervals have a second major benefit: they specify a time window for making changes in capabilities, direction or priority.  More specifically, SCRUM:

 Is an industry-proven process for organizing the development team

  • embraces periodic retrospectives – to support ongoing improvement,
  • keeps outside stakeholders out of the hair of the development team,
  • makes a concerted effort to achieve short term goals, and
  • ensures accountability for achieving the result, on time (since it is bounded enough and close enough in time).  This includes stakeholder demos.

 The Product Owner is responsible for being the central point for managing the concerns and issues of stakeholders, including QA, regulators, instructional designers, content developers. 

In other words, SCRUM’s foundation is the trinity of Development Team, Product Owner and SCRUM Master.  Features are established in a planning phase at the start of each (short) sprint, and then the development team spends the next 2-3 weeks implementing and testing them.

In addition, “the Product Owner’s neck is on the chopping block” for the overall success or failure of the effort.  Note that the Product Owner is not member of the development team, and is not an active participant in daily meetings or in-SCRUM decisions.  This is a rather lonely position, akin to being a derivatives trader sweating out the market to see if a highly leveraged trade makes $5 million or loses $7 million.

Software Architecture and SCRUM

 As Steven Covey says, it is vital to do things well, but even more critical to do the right things.  When a complex system is to be built, it is necessary to assemble the right set of ideas, resources, and processes.

SCRUM delegates to the Product Owner the job of coming up with the great ideas (of course, the Product Owner is free to outsource).  This is a fine approach.  Hospitals do it with neurosurgeons, shipping companies do it with pilots, the FAA does it with air traffic controllers, and baseball teams do this with pitchers.  Talented people who understand their area can provide great direction and achieve great things.  However, as discussed earlier in the “Relevance of Domains” section, conceptual distance often separates domain experts, and makes it difficult for them to understand each other.  Two recent practical examples of this are the series of decisions that led to the Space Shuttle Challenger and Columbia tragedies.

 While conceptual distance can have a noticeable impact on goals and priorities, it tends to be amplified for challenges and decisions.  Solutions proposed by one set of domain experts are vetoed or fought by other domain experts.  One reason is that the first set didn’t grasp or value concerns that the second set perceived as valuable.  Another reason could be that the first set’s proposal blocked or conflicted with something else that the second set wanted.  Add in a manager (especially one like Dilbert’s “Pointy Haired” Boss) who understands little about either domain, and the situation is likely to degrade further.  The manager doesn’t grasp the issues that each set of domain experts considers important, and fails to understand the linkages between them.

 In other words, architecture is the oil and filter that properly lubricates the SCRUM process.  While any oil and filter can suffice in the short run, the right architecture strategy is like having the right brand and viscosity.  As the mechanic in the Fram Oil Filter commercial said, “You can pay me now or you can pay me later.”  The same is true about software architecture.

SCRUM works nicely with software architecture in much the same was as an automobile’s steering system works with the car’s suspension.  The steering system provides drivers with agility, as they swerve or corner to vehicle.  The suspension provides essential stability as two tons rapidly change direction at 50 MPH.  Remove the suspension, and steering equates to rollovers.

 The following diagram illustrates one way that software architecture and SCRUM collaborate:

 Compexity Driven and SCRUM

At the core, the key challenge is that things are getting more complicated, more individuals are specialized, and we need to have a better way for them to understand each other.  Things erode when developer A doesn’t really understand product marketer B, or QA person C fails to get developer D (or product use case E).  Large-scale software development is just one giant 4×100 relay race, and dropping the batons just isn’t the way to get the job done.  What’s needed is to raise the bar higher on the common shared ground.

 SCRUM brings coordination of action, which is critical.  Software architecture brings coordination of intent and insights. 

Big Design Up Front (BDUF) vs. No Design Up Front (NDUF)

BDUF stands for “big design up front” and emerges from the waterfall methods which strive to design the whole system before coding any of it.  This approach might work for some small programs like the “Sieve of Eratosthenes”.  However, as complexity and scope both increase at the same time, this approach collapses like an N2 sort algorithm.  Interdependency is s serious contributor.  When you have 12 interdependent variables, any decision about one must consider the impact on the rest.  Add uncertainty and the problem explodes in complexity.  Encapsulation and isolation, two hallmarks of an object-oriented programmer are limited or sometimes nullified.  

“No BDUF” is one of the 12 core principles of Extreme Programming (XP).   The approach here is to assert that it is not possible to design an entire system up front.  Some amount of research and trial and error are necessary, because people (even very intelligent ones) cannot visualize the entire problem in their minds, on a white board, or in a design application display

Some agile proponents suggest that NDUF (no design up front) is ideal.  This mode does not forsake design; it just boxes it to each sprint.  Developers solve the problems at hand for each sprint.  No attention is paid to issues from future sprints.  When new, unanticipated issues do arise, refactoring and unit testing are the primary tools used to evolve.

The tension between BDUF, No BDUF, and NDUF will probably last forever.  However, with any luck, people will see the sense in what Ruth Malan, of Bredemeyer Consulting has been advocating.  “The real goal here is EDUF – Enough Design Up Front.”  While who defines enough is a slippery problem, two things can be said:

  • Enough should be driven by the nature of the problem (how complex is it, and how numerous and strong are the interdependencies between its elements)
  • Enough should not be driven by the whims of hackers or impatient programmers. Enough design up front means “enough design has been done,” not that someone has had enough designing.

SCRUM has its own form of “no BDUF”, and stresses the following:

  • The Product Manager writes down user stories, both up-front and after sprints
  • At the start of each sprint, the PM selects and prioritizes a set of important stories.
  • The developers size each of the stories, estimating difficulty, risk, are coordination.

 The result of this process is that team energy remains focused on the short term deliverable.  In principle, this is a good thing.  In practice, the approach is only as good as how well the PM selects and prioritizes the stories.  Back to Steven Covey’s thesis, being effective means doing the right things right.

Is a Product Manager a Suitable Architect.

There are many, competent, experienced, hard-working Product Managers, and they usually are very skilled in business, user experience, use case specification, communication, stakeholder management, and project coordination.  This is a pretty impressive combination of skills, and it is not a surprise that these individuals are not necessarily top rank in six flavors of technology, abstract analysis and systems-thinking.  

 For those few product managers who also have exceptional technical skills, they also may play the role of architect.   But if the Project Managers do not have the background, or the depth of experience, then significant risk exist if they attempt to play the architect role.  There are very good reasons why trained pilots fly our commercial aircraft, while airline executives, and flight crew don’t.   Perhaps it is because commercial airline crashes are perceived to have more devastating consequences than software catastrophes.

How Many Questions are Too Many Questions?

 So, let’s shift our perspective from the notion of “architect as person” to the notion of “architecting as a process” that yields great systems.  But how many questions do you need to answer in order to begin development?  Here are two similar views on this question.

The first comes from a blog article written by Hanno Hinsch, in the Joel on Software block on 9/13/05.  The URL of the article is: (

 Harking back to Joel’s post on BDUF last month: Some time ago I resolved to once and for all reconcile my inner agile with my up-front-design head. After duly mulling it over, I concluded there is no conflict. The XP guys just need to apply first principles to the question of when to design. Actually I went ahead and did it for them; here’s a two paragraph outline of the answer:

 There are design media (paper, UML, plaster, index cards, or whatever) and there are delivery media (code, bronze, oil paints, or whatever). The cost of working in the media varies (e.g. plaster vs bronze). But whichever media you use, mistakes will be made.

 You’re looking for design media that help you catch mistakes at low cost. For some projects the delivery medium (e.g., working code) will be a cost-effective design medium, for others it won’t be. The key to using design effectively is to think about the possible mistakes you might make doing your particular project, and then choosing design media appropriate to catching those particular mistakes at low cost. So don’t waste your time doing “design” that has no chance of flushing out your mistakes, but don’t jump straight into using a delivery medium if your mistakes will be really expensive to correct.

 Anyone who advocates a one-size-fits-all approach, no matter what it is, should be suspected of not having thought about this very much.

So the simple answer here is the approximate tradeoff between how long it takes to design something versus how long it takes to fix something that is badly broken.

This second view is about architecture challenges.  It complements the Hirsch post from above.  This passage is an excerpt from an article I wrote in my blog  (  This article explores four more fundamentals: requirements, goals, architecture and principles.  For this discussion, the four fundamentals listed below should be sufficient.

 Context is the setting in which solutions are experienced and value is perceived.   Changes in location, situation, surrounding systems, and subjective perceptions of users can alter the context, forcing the system to adapt.  In a semiconductor clean room, dust is a key part of the context.  For automobiles, weather and pollution standards are big parts of the context.   One of the most challenging aspects of context is finding an effective way to straddle several variants.

 Value is the perceived worth of a solution as experienced by some like-minded group of stakeholders within a similar context.  Value tends to be higher when an opportunity is opened or a pain point is addressed.  Value could be absolute, or be relative.  In the latter case, it could be relative  to another alternative, or to the stakeholder’s (unrealistic?) expectations.  Value is different from benefit.  Benefit is objective and quantifiable; value is how benefits are experienced.

 Challenges are major risks and obstacles with the most impact on value.  The key concepts here are difficult, valuable, and dependency.  Difficult, because easy risks and obstacles tend have lots of good alternatives (i.e. degrees of freedom); difficult ones don’t.  Valuable, because the solution should just avoid or mitigate big risks and obstacles that don’t have a big effect on value.   Dependency, because decisions on which many other decisions depend can be the most difficult to undo.

 Priorities apply to Challenges and are the principal guidelines used for determining the sequence in which architecture decisions should be made.  The specific criteria used to prioritize challenges may vary, but should always include value, complexity, dependency, and the availability of good alternative approaches.  The first three criteria were discussed briefly under Challenges.  The fourth criterion ensures that the architect avoids painting him/herself into a corner by treating “the last good alternative” as an alert.

 The funny thing about nature is that is often finds a way to penalize (or snuff) a being that fails to properly apply good approaches.   Here, focusing on the tradeoffs between cost to design vs cost to modify is key.

 Another good software approach that can be neglected is failing to truly understand the sources of complexity in the problem sub-domains and how they interconnect.   What makes a requirement difficult?  What are the strengths and weaknesses of alternative platform technologies?  Civil engineering has a concept of “strength of materials.”  This fits here as a process to ensure that the materials used in a building, bridge, etc. and how they are structured can support their load.

Use of SCRUM and Architecture in TL Courseware

At the start of Courseware Development effort was that a very good list of user stories had been compiled and prioritized

  • The development team had about 9 members, 33% in US and 67% in the Ukraine
  • The development team was pretty experienced in Adobe Flash/Flex
  • The development team was familiar with language learning activities that had been implemented in another development effort
  • The team had some PureMVC experience (including Muticore or Pipes)
  • Knowledge of SCORM and LMS’s was isolated in 1-2 individuals

This status list was transformed, using a short document and some group discussion, into a list of perceived top-level challenges in Courseware.

Top-Level Challenge


Different Versions of SCORM SCORM 1.2 and SCORM 2004 v3 have incompatibilities and both versions will be in the field and exposed to Courseware App.
Handling LMS Variances The two SCORM standards expand into about a dozen different LMS vendors. Each vendor has proprietary quirks for LMS tracking, content packaging, sequencing and navigation and metadata.
Rich Internet Application Selection of a RIA platform (JavaScript, PureMVC and SilverLight).
MVC CourseWare is a learner intensive package, working with complex underlying content.  It is vital to isolate views from the model.
Pluggable Activities CourseWare will need many learning activities.  A particular learning  unit will have a few, but the units are not homogenous across languages.  The ability to load appliances into a home and plug them in was as vital as it as for Courseware activities
Font / Ligature Courseware must support ~70 languages, and 6-8 scripts.  These languages vary in the way they represent characters internally, and they way they process ligatures.  Having characters that look as they do when natively written is critical.
Learning Event Tracking SCORM’s RTE model is rigid.  Within a SCORM version, attribute names and value formats are fixed.  The methods that operate on this data are also fixed.  These attributes control learner objectives, interactions, suspend/resume state, and many other variables that must be exchanged between learning application and an LMS.   The SCORM standard marks a large percentage of attributes as optional (i.e. LMS’s not required to support).

 The important thing here is that the list of challenges listed above was compiled quickly.  In a matter of 3-5 days, a few subject matter experts met to discuss problems and potential problems.  It was important that the discussions avoided straying into assessments of alternatives or solutions.  Subject matter experts took time to explain the language of their area to begin to clarify unfamiliar concepts.

Once the challenges have been compiled, the next task was to prioritize them.  Three variables drive prioritization: importance (value), difficultly, and cross-dependency.  The second two variables have a strong correlation with time and/or cost to repair.

With challenges that have great difficulty, the developer’s challenge is to find one way to get the solution right – the search for elegant ways often never happens.    With challenges having many cross dependencies, the solution is unstable – a change in any key variable can cause the structure to become imbalanced.

Summary and Conclusions

 From the CourseWare experience project of integrating Software Architecture and SCRUM, we drew six fundamental conclusions:

     1.  The Product Manager needs a good Architect (if they are not one already J)

The Product Manager is required to be an expert in the marketplace – how users will use the product and how they (or their organizations) will benefit.  They must be aware of competitive alternatives and what types of threats or opportunities they pose.  The Product Manager must be on top of their product’s role in their own organization, revenue and profit goals, and demands on support organizations.  In short, the Product Manager is the head coach, the point person for making sure that the product will deliver against business expectations.

 In some cases, the Product Manager is also very technical person and comprehends the architectural and engineering issues in depth.  However, as things get more and more complex, this tends to be the exception rather than the rule.  A solid Architect is the perfect complement for a competent Product Manager.  They have a similar grasp of systems and strategies, and both communicate effectively.  They face in different directions, have each other’s back, and cover the blind spots that the other has.

     2.  Separation of responsibilities is vital.  All necessary domains must be covered by people who are competent, and there must be good balance among the individuals.


Principal Responsibilities

Product Manager Define the business and marketing case (benefits, $$, time)
Architect Grasp/communicate the system.  Facilitate comprehension
Development Mgr Supply qualified team members and development resources
Product Manager + Team + Architect Write new stories for the SCRUM backlog
Product Manager + Architect Prioritize stories (importance, difficulty, depend)
SCRUM Master and Team Estimate, develop, test stories in sprint + demo

    3.  SCRUM can benefit greatly from a lightweight architecture strategy

\CVCCAP = Conceive Value Clearly, Produce, Awesome, Products

  • Contexts for product/system – How are they similar and different?
  • Value Expectations per context – What are benefits and priorities, and limits?
  • Challenges –  Which risks and obstacles most constrain value?
  • Priorities  – Which value expectations and challenges are more important?
  • Approaches – What is the high-level plan to address key challenges?
  • Principles – Distill the high-level strategy from the approaches

It is very important to note that this approach is not an example of BDUF.  Completion does not require object models, sequence diagrams, or API documentation.  With a relatively small amount of time and effort, it captures the critical aspects of the problem and associates each of them with a high-level solution approach.

    4.  Good architecture is the rudder and keel of a successful product development effort

The 90/10 rule applies in software architecture.  10% of the decisions account for about 90% of the outcome (or lack thereof).  As a result, four things are important:

  • It is essential to correctly identify the 10% of the challenges that are critical.
  • The architect must communicate effectively with the development team so that they comprehend the essence of each challenge.
  • It is critical that alternatives be weighed for each challenge, while considering the potential systemic impact on other challenges.
  • The architect and development team must follow-up periodically during the development process to ensure that the chosen alternatives are implemented.

While these things take a moderate amount of up-front time, they actually serve to increase agility.  A shared architectural vision, plus keen awareness of the factors that can thwart it facilitate coordination and collaboration.

    5.   SCRUM operates nicely within this framework

 The great thing about a clean, crisp architecture strategy is that it frames the development effort nicely.  The architecture strategy isolates important similarities and differences in contexts: value expectations, priorities and environmental conditions.  The architecture strategy identifies and prioritizes key challenges (barriers to success), and recommends approaches to address them.

The architecture strategy pins down the critical 10% of a system that needs to be a particular way.  But it permits the remaining 90% to vary and evolve gracefully.  The architecture strategy identifies key components, but does not specify the interfaces, collaboration diagrams, class hierarchies or design patterns.  As a result, it leaves room for the SCRUM process to work and software engineering to occur.

SCRUM sees the architecture strategy as a cousin to the product backlog.  SCRUM handles selection of stories (based on importance and architectural dependencies), and developers apply their comprehension of the architectural challenges and approaches in making informed engineering decisions.  When changes to the product backlog are needed between sprints, the architecture strategy becomes a yardstick to assess the impact and potential risk of the proposed changes.

     6.   Bottom Line: SCRUM and Architecture are quite compatible, if blended properly

The value of this pair increases as conceptual distance increases.  Architecture helps to ensure that the development team has a common understanding of the approaches to the most significant challenges.  SCRUM focuses the teams attention on short bursts (sprints), guided by the architecture strategy.  SCRUM provides a between-sprints mechanism to make as needed adjustments to stories, priorities, resources, and architecture.  Architecture clarifies which aspects of the strategy are more or less changeable and why.

 A development team that comprehends the system, understands each other, and communicates well is primed for success.  SCRUM and software architecture help to realize this.



  1. […] SCRUM and Architecture – Partners or Adversaries? […]

    Pingback by SCRUM and Architecture – Do they mix? « Charlie Alfred’s Weblog — September 6, 2009 @ 9:12 pm

  2. […] SCRUM and Architecture – Partners or Adversaries? « Charlie Alfred’s Weblog – view page – cached #RSS 2.0 Charlie Alfred's Weblog » SCRUM and Architecture – Partners or Adversaries? Comments Feed Charlie Alfred's Weblog — From the page […]

    Pingback by Twitter Trackbacks for SCRUM and Architecture – Partners or Adversaries? « Charlie Alfred’s Weblog [] on — September 9, 2009 @ 4:38 am

  3. Hello there,

    This is a question for the webmaster/admin here at

    Can I use part of the information from your blog post right above if I give a backlink back to your website?


    Comment by bidou — November 10, 2010 @ 8:14 pm

    • yes

      Comment by charliealfred — November 13, 2010 @ 12:26 pm

  4. Thank you very much for this profound article. From my 25 years software development experience – and the current situation in my company – I can say every single word here proofs true.

    Hope a lot of responsibles, especially top management, will read and understand this article. To understand this is crucial and very valuable.

    This knowledge has the potential to save a lot of money, to create excelent products, and – last but not least – to save companies not becoming a victim of software catastrophies.

    Comment by Achim Koch — February 15, 2011 @ 6:37 am

  5. Achim, Thank you for the very nice comment.


    Comment by Charlie Alfred — February 15, 2011 @ 8:15 am

  6. I would like to thank you for this wonderful article. I have used some of your ideas for my weblog article on Scrum and SW architecture. This is the link to the blog:

    I hope, there will be more good articles from your blog in the near future.

    All the best
    Nhan Truong

    Comment by Nhan Truong — March 17, 2011 @ 1:45 am

  7. […] SCRUM and Architecture – Partners or Adversaries? […]

    Pingback by The Role of a Software Architect in a Scrum Team | 1095 Days To Freedom — January 17, 2012 @ 11:24 am

  8. Good day! I could have sworn I’ve been to this website before but after reading through some of the post I realized it’s new to me.
    Anyways, I’m definitely glad I found it and I’ll be bookmarking and
    checking back frequently!

    Comment by internship for computer engineering — January 31, 2013 @ 3:08 am

  9. Do you mind if I quote a couple of your articles as long as I provide credit and sources
    back to your webpage? My blog site is in the very same niche as yours and my visitors
    would really benefit from some of the information you present
    here. Please let me know if this ok with you.

    Comment by Eugene — March 10, 2013 @ 6:04 am

    • Sure.

      Comment by charliealfred — March 10, 2013 @ 11:47 am

  10. […] me he conseguido con una tercera opción escrita por Charlie Alfred (@CharlieAlfred) en Scrum and Architecture: partners or adversaries que sugiere un mix muy productivo entre Cliente y Arquitecto. De solo imaginarme como Scrum Master […]

    Pingback by ¿Scrum [contra || con] Arquitectura? - Agilizandoando — May 14, 2016 @ 8:19 am

  11. […] me he conseguido con una tercera opción escrita por Charlie Alfred (@CharlieAlfred) en Scrum and Architecture: partners or adversaries que sugiere un mix muy productivo entre Cliente y Arquitecto. De solo imaginarme como Scrum Master […]

    Pingback by ¿ Scrum [contra || con] Arquitectura ? - Agilizandoando — May 22, 2016 @ 3:23 pm

  12. […] embargo, como comenta Charlie Alfred, en su post SCRUM and Architecture – Partners or Adversaries? que recomiendo leer: “la arquitectura es el aceite y el filtro que lubrica adecuadamente a […]

    Pingback by Blog de Jose Cuéllar | SCRUM, arquitectura de software y demás — May 31, 2016 @ 11:49 am

RSS feed for comments on this post. TrackBack URI

Create a free website or blog at

%d bloggers like this: