An Agile Architecture Community of Practice

Note:  The format of this article did not transfer over well from the previous site, so this pdf version might be much easier to read and distribute.


We often coach organizations on scaling Scrum, where 4-12 Scrum Teams are working on the same Product or a set of closely related Products (Applications, Systems, etc). We often get asked how things like Architecture and other multi-team related concerns are handled in a scaled Scrum approach. In Agile practice, handling these multi-team concerns is usually handled via a mechanism called a “Community of Practice”. Below is an example of a moderately mature community, based on a compilation of ideas that we have seen work well in the field. Note also that a TeamSet should always have more than one “Community of Practice”,and new ones should be formed and dissolved as needed.

For more info on Communities of Practice, see An Agile Community of Practice Starter Kit

Caveats about the example below:

  1. We use the term “TeamSet” below to refer to a set of teams, the 4-12 mentioned above, working on a Product or set of closely related Products. Obviously the more high impact the architectual initiatives, the more formality of process you will likely need. So, if your set of closely related Products is not that closely related, then this community should be less formal and less broadly applicable in its decisions. The converse of this is also likely true.
  2. The below example is that this shows more of an “ideal end state” — your org will likely have to take a few steps of organizational change before you can get here. But try to get as far as you can on step 1 — you might surprise yourself.
  3. We have probably added more formality and more documentation below than would be typical in a real life, highly Agile, community of practice. We do so here primarily for illustrative learning purposes, to give you more ideas than are truly needed (i.e. so you can pick and choose what work in your context). In real life, the community would likely be less formal.
  4. This example is for Architecture, but this same kind of approach easily fits other types of CoP’s: Agile CoP, Scrum CoP, Scrum Master CoP, Product Owner CoP, DevOps CoP, Programming CoP, Automated Testing CoP, UX CoP, SAFe CoP, RTE CoP, Nexus CoP, LeSS CoP, etc. [ONE MORE REMINDER: Your CoP should have the minimum amount of formality necessary, and to the extent possible, should operate bottom up.]

The Aegis Architecture Community of Practice

Our Charter Statement: We all work on a set of closely related products, collectively known as Aegis. This community organized around ensuring that the highest Architectural concerns that have a high impact on Aegis are efficiently and effectively addressed. Please note that this community focuses only on the highest Architectural concerns.

In Scope: The set of teams (TeamSet) that this community encompasses are: Stingray, 49’ers, Falcon, Journey, Explorers, Red October, Phoenix, and Hawking. The main “in scope” topic is high Architectural concerns, though the dividing line between “high” and “not high” is not always black and white. As you look below, hopefully the mechanisms we have in place will give you the idea of where that line is usually drawn.

Out of Scope: Practices related to Programming, Design and other concerns are generally left to others (Other communities and/or the Scrum teams themselves to self organize and solve). Test and Build automation is left to others. The Director of Software Dev hires and chooses the LA (Lead Architect), so that is out of scope for our community. Our Arch CoP only covers the teams in the Aegis TeamSet, so for Arch issues that are decided at the corporate level, you will need to talk to the EAG (Enterprise Architecture Group, not a CoP yet. 😦 ). Our Lead Architect has good communication with the EAG, but anyone should feel free to go the EAG for the appropriate services(just loop the Lead Architect in as well). Typically we form a working group from this CoP to go and talk to the EAG for any requests.

(In the sections below, note that we have specifically named them “Individuals”, “Interactions”, “Processes”, “Tools” to relate to the Agile Manifesto, valuing “Individuals and Interactions over Processes and Tools”.)


Community Leadership

Home Scrum Team

Community Coordinators (CC) Jill Hutchins, Henry Nguyen Stingray, Falcon
Agile Coach Jeff Schwaber (Liaison to Scrum Master CoP) Falcon
Management Contact Ellie Swanson n/a, Director of Software Dev
Lead Architect(LA)
90% allocated to community
10% allocated to Scrum Team
Ian Robison Journey
Community Architects(CA)
50% allocated to community
50% allocated to Scrum Team
Phillip Smith Explorers
Brijesh Singh Hawking
Jill Hutchins Stringray
Henry Nguyen (Liaison to Tech Excellence COP) Falcon

Community Members

Architecture Team Reps(ATR)
10% allocated to community
90% allocated to Scrum Team
Sheila Hill Stingray
Carlos Diego 49’ers
Rachel Story Falcon
Chris Bradford Journey
(open) (interim- Phillip Smith) Explorers
Adam Gideon Red October
Adrienne Maxhouse Phoenix
Sandesh Mokkarala Hawking
General Member (GM)
All people above are also considered GM’s
Anyone interested!
Melissa Hayden (Liaison to Testing CoP)
Role Definitions
Community Coordinators This role is to be a servant leader to guide the community on what initiatives and other efforts to focus on. This role also helps provide leadership on which decisions are truly of high enough concern to warrant formality and process via the community. The only requirements for this role are that the person has the appropriate architecture knowledge and must have 3 months of experience in the role of ATR and/or CA prior to serving. The Lead Architect cannot be a coordinator (this helps prevent command and control hierarchical leadership — and respects self organization of the community). The coordinators are elected every 6 months.
Agile Coach This role is to be a servant leader to guide the community on how to respect the Agile Manifesto, the Scrum Guide, and in general, the “Community of Practice” approach to self organization. This person is expected to be an experienced senior Scrum Master or Agile Coach. The requirements for this role are: 1 year of experience as a Scrum Master or Agile Coach, 2 Agile/Scrum certifications, and at least 3 months of participation as a General Member in this community prior to serving. This person will also need to be able to spend ~20% of their time playing this role. The Agile Coach is elected every 6 months.
Management Contact This is senior management role from the Dev Org, cannot be a first line dev manager. Currently the Director of Software Dev plays this role. This contact is used to secure funding, facilities, and other logistical approvals needed for the community to hold its events. This person does not usually spend much time interacting with the community.
Lead Architect This person is hired by the Director of Software Dev to be the Lead Architect for the TeamSet and for the community. This person participates heavily in the community and has some decision making power (see “Process” below). The requirements for this role are determined by the Director of Software Dev. Cannot be the Community Coordinator (see that role description for more info)
Community Architect This person spends around 50% of their time on community initiatives. They are expected to be good communicators, accessible, and have the appropriate architecture knowledge.
The only requirements for this role are that the person has the appropriate architecture knowledge and must have 3 months of experience in the role of ATR and/or CA prior to serving.
Architectural Team Rep This person spends around 10% of their time on community initiatives. This usually revolves around being a communication radiator for their Home Scrum Team and ensuring that all relevant community communication gets shared with their home Scrum Team. This person will also often help with architectural initiatives that their Scrum Team is sponsoring. This should never be considered a gate or bottleneck role — i.e. anyone on any Scrum Team can interact with the community without having to go through (or get approval from) their ATR.
General Member Anyone who has an interest in architecture can participate in the public activities, meetings, and communication mechanisms of this community. In order to vote for the approval of CWA’s or in approval meetings, the person should have significant knowledge of the subject at hand, and have materially participated in 3 months worth of immediately prior community activities. It is strongly recommended that you recuse yourself from votes any time you do not meet these pre-requisites, OR any time you don’t have a strong opinion on the thing being voted on.
Liaison The community has various volunteer liaisons to other parts of the organization, generally to other CoP’s. These people help us identify synnergies and conflicts of scope between this community and the other communities. This is a pretty informal position, and any General Member is free to provide the same kind of information — it’s just that these people volunteer to definitely keep an ear to the ground between the two communities.

CWA’s re: Individuals

(CWA’s = Community Working Agreements)

  1. In everything we do, we try to honor Scrum(as defined in the Scrum Guide) and Agile (as defined in the Agile Manifesto). Because we have not yet chosen a scaled Scrum approach, we simply extend many of the ideas of the Scrum Guide and Agile Manifesto to our entire Community and TeamSet.
  2. The table and information above includes information that is also effectively CWA’s.
  3. Because we believe in the Agile value statement of valuing “Individuals and Interactions over Processes and Tools” and “Responding to Change over Following a Plan”, don’t ever be afraid to get some architects together in an ad hoc way to solve an architectural challenge — we can always retrofit those actions to our processes and tools later.
  4. Unless otherwise indicated, the use of the term “architect” refers to the LA, CA’s, and ATR’s (i.e. does not refer to GM’s).
  5. The architect titles above are completely independent from your job title and career path. The above titles are bestowed by the community (except for the LA, who is hired by the Director of Software Dev). This community makes no claim over the management or career path domains of the company. We are simply a self organizing community that co-exists with the rest of the organization.
  6. Every architect belongs to and works on a Scrum Team. In their Scrum team, they hold no special authority or title on their team other than “Scrum Dev Team member, ” regardless of their title in this community.
  7. Being a GM of the community is voluntary, with one exception: each Scrum team must choose and have an ATR with the appropriate skills, who is not an LA or CA.
  8. All new CWA’s(re: Individuals or any other topic) must be approved by a “fist of 3” by the entire community. For all new CWA’s that have a heavy impact beyond the community, a forum must be held where all Scrum team members from the TeamSet can give feedback prior to approval.
  9. There is always a Scrum team sponsor for each initiative, even if there is only a subset of the team working on the initiative.
  10. We strongly prefer bottom up initiation of all architectural initiatives, coming from the teams. Initiatives need not come from the architects, but the ATR for that sponsoring team must be involved and be highly informed of the initiative.
  11. The general time allocation expected of architects is listed in the chart above. Of course, there are exceptions at times. At any one given moment, an architect might have to choose between focusing on helping their team or helping their community. In that moment, the architect is expected to consult with others on which focus yields the most value for the entire TeamSet. Sometimes this means focusing on community efforts, and sometimes it means focusing on team efforts. Try to choose wisely in that moment.
  12. Coordinators can fulfill the role of either a CA or an ATR while also fulfilling the coordinator role, but this is not a requirement.
    1. Note above that an ATR cannot fulfill the role of ATR AND [CA or LA] at the same time, but an ATR could be an ATR and a coordinator at the same time.


Communication Mechanisms
Ad hoc conversations and informal meetings — we encourage these the most! We encourage involving your ATR or CA when needed.
This Wiki
“Roughly” Monthly Public Meetings
Occasional ad hoc public meetings when needed (includes educational meetings, approval meetings, etc)
Group Chat (HipChat)
Email List
Occasional Private Meetings (Primarily only open to the LA, CA’s, ATR’s, and specially invited guests)
ATR’s are responsible for communicating the important outcomes of all of the above to their respective teams.
Architectural elements of the TeamSet Definition of Done
Scrum Team “Code Based Tools” pages
Communication Contact To get connected to our communication mechanisms, ask your ATR who to talk to.

CWA’s re: Interactions

  1. In everything we do, we try to honor Scrum(as defined in the Scrum Guide) and Agile (as defined in the Agile Manifesto). Because we have not yet chosen a scaled Scrum approach, we simply extend many of the ideas of the Scrum Guide and Agile Manifesto to our entire Community and TeamSet.
  2. The table above includes information that is also effectively CWA’s.
  3. Because we believe in the Agile value statement of valuing “Individuals and Interactions over Processes and Tools” and “Responding to Change over Following a Plan”, don’t ever be afraid to get some architects together in an ad hoc way to solve an architectural challenge — we can always retrofit those actions to our processes and tools later.
  4. In all of our architecture discussions and initiatives, we agree to use Agile Emergent Architecture.
  5. Our community maintains a wiki for any communication where light documentation seems like a good communication mechanism. This page is just one of our pages. See our home page for lots more stuff.
  6. Any person in the TeamSet can contact their ATR or a CA for help, collaboration, mentoring, or whatever is needed. It is NOT required to go through your ATR for every architecture interaction. We generally discourage direct communication with the LA unless you are working on an initiative with that person. The person is VERY busy. Your ATR or CA will involve the LA if that is needed.
  7. Each Scrum Team must keep an updated “Code Based Tools”(CBT) page connected to their team wiki. Only include tools that your team regularly uses and/or has significant experience with. The purpose of this CBT page is to spread knowledge to the entire TeamSet about which tools are in use, and which teams have knowledge of those tools. On the CBT page, the team must include 2 categories of tools and info:
    1. CBT’s that they use that are expressly approved by the Arch Community Tool Matrix.
      1. For each 3rd party library, please specify the exact library and versions in use, why the library is being used(it’s purpose), known scope of use(product, module, class, etc), and how widespread is its use (low, medium, high).
    2. CBT’s that they have not been expressly approved by the Arch Community Tool Matrix. (Note that this is not considered bad usage — not all tools are in the scope of our community)
      1. please specify the exact tool and versions in use, why the library is being used(it’s purpose), known scope of use(product, module, class, etc) and how widespread is its use (low, medium, high).
  8. In all of our communication mechanisms, we try very hard to be specific about topics of discussion and whether they are they “in scope for the community”– or not?
    1. For instance, using our communication mechanisms to just get general ad hoc architectural or even design/implementation/technical help is perfectly fine, but say something like “This is really more in scope for just our team, but we could really use some help on — who can help us with that?”
    2. If you’re not sure whether a topic is in scope for the community, just ask the community for help in determining that!
    3. Obviously, if you realize that a topic is in scope for a different community, by all means, please use that community’s communication mechanisms instead of ours.


Architecture Tools Approval Process (ATAP) (tools, frameworks, arch approaches, etc)
Election of Community Leaders
Quarterly Retrospectives

CWA’s re: Processes

  1. In everything we do, we try to honor Scrum(as defined in the Scrum Guide) and Agile (as defined in the Agile Manifesto). Because we have not yet chosen a scaled Scrum approach, we simply extend many of the ideas of the Scrum Guide and Agile Manifesto to our entire Community and TeamSet.
  2. The table above includes information that is also effectively CWA’s.
  3. Because we believe in the Agile value statement of valuing “Individuals and Interactions over Processes and Tools” and “Responding to Change over Following a Plan”, don’t ever be afraid to get some architects together in an ad hoc way to solve an architectural challenge — we can always retrofit those actions to our processes and tools later.
  4. We use the term “Tools” fairly broadly, to include essentially all architectural initiatives that require community approval or coordination.
  5. Community retrospectives are held at least once each quarter, and at least within the 2 weeks prior to a new community leadership election. At this time, we often review our CWA’s and Charter Statement to ensure we are in alignment.
  6. Every 6 months, an election is held to select the CC’s, CA’s, and Agile Coach.
  7. All architectural initiatives must include an “independent usage plan” that describes how future users of the initiative can be quickly educated on the tool/approach such that they will not be heavily dependent on tribal knowledge by a small number of people. This often includes light documentation as well as video recordings of education sessions for the initiative. Decreasing this type of “key person” risk enhances our Agility and ability to respond to change in the future.
  8. The ATAP is documented in detail elsewhere, but here is a summary:
    1. A Scrum Team suggests sponsoring an initiative to be approved as an experiment or as a tool, initiative, or decision that is approved for widespread community use.
      1. We encourage the teams, as much as possible, to sponsor initiatives of their own choosing. I..e we prefer they initiate.
        1. In rarer cases, sometimes the CA’s or LA will ask a team to sponsor, but the decision is up to the Scrum Team.
    2. An approval meeting is scheduled (giving the team time to be prepared). Sometimes this is done in regular monthly meetings, sometimes scheduled ad hoc.
    3. The Scrum Team makes review material available 1 week prior to the approval meeting for voting members to review prior to the approval meeting.
    4. The Scrum Team presents to the community.
    5. The community votes with a fist of five, where at least a fist of 3 is required of all approved voters. If a fist of 3 cannot be obtained, a “unity group” is formed to discuss further and/or come up with a compromise within 2 weeks, including those strongly in favor, as well as any that are a fist of 2 or lower(the dissenters). If the unity group can agree with in 2 weeks, then the voted is considered approved. If they cannot agree, then the LA makes the decision to approve or disapprove as a last resort.
    6. If approved, the community then documents the new tool as “approved for experiment” or “approved for use” and is added to the tool matrix. (see below)


Tools Matrix

Tool/Initiative Name

Being Proposed


For Experiment


For Use



Logging Framework – SLF4J (v3.4, v4.0.1) X
Programming Language: Java (23.4 or above) X
Dependency Injection Framework: InjectorSpace 3.2 or above
(Home Grown)
Dependency Injection Framework: InjectorSpace 3.1 X
Dependency Injection Framework: InjectorSpace 3.0 or below X
Architectural Pattern/Domain Logic: Domain Model X
Architectural Pattern/Domain Logic: Service Layer X
Database: Oracle 23i or above X
Deployment Platforms: ???
Other various open source libraries:
Must be GPL-3.0 or EPL-1.0 license.
Programming Language: Scala (12 or above) X
Architectural Pattern: Microservices (will likely be limited in scope, as only valuable in certain contexts) X
Persistence Framework: Hibernate (54 or above) X
Architectural Pattern: Monolith applications X
Peer Review: Scrum Team must have documented procedures for peer reviews. X
… (author note — there would likely be many more items in a real CoP —
these are just examples)

Note that the TeamSet Definition of Done requires that all 3rd party tools that are code based (Libraries, code frameworks, Development Environments, etc) be represented on the above Tool Matrix.

The items below have at one time been considered out of scope for the Architectural Community.

Out of Scope Matrix


CWA’s re: Tools

  1. In everything we do, we try to honor Scrum(as defined in the Scrum Guide) and Agile (as defined in the Agile Manifesto). Because we have not yet chosen a scaled Scrum approach, we simply extend many of the ideas of the Scrum Guide and Agile Manifesto to our entire Community and TeamSet.
  2. The table above includes information that is also effectively CWA’s.
  3. Because we believe in the Agile value statement of valuing “Individuals and Interactions over Processes and Tools” and “Responding to Change over Following a Plan”, don’t ever be afraid to get some architects together in an ad hoc way to solve an architectural challenge — we can always retrofit those actions to our processes and tools later.
  4. We use the term “Tools” fairly broadly, to include essentially all architectural initiatives that require community approval or coordination.
  5. We don’t yet have any more special CWA’s on the Tools topic — most of what we record here is in the tool Matrix above.
  6. These tools have been considered to be “out of scope” for this community: Agile ALM Tool, Wiki Tool Choice, Test Driven Development, Peer review procedures, Test Automation techniques, Build Automation techniques, process compliance.


[TODO: Make Tables appear better]

Metrics for Agile Teams — Evidence Based Management for Software Organizations

If you’re looking for metrics to report up or “status” to report up in your software organization, look no further than Evidence Based Management for Software Organizations from  The framework was just recently updated in 2018.  Note that these metrics are gathered at the Product level, not the team level.  If you plan to track metrics like this, and you try to track several teams on the same Product or in the same organization, what you will find is you will create an anti-pattern.  Once teams realize that they are competing against each other, they will stop helping each other!!!  So, don’t do that!  Instead, measure at the Product level, and have the teams retrospect both at the team level and at the product level on how they improve those metrics.  Also, remember that “not everything that counts can be counted”, and always consider subjective data in addition to objective data.  With all of those caveats, I highly recommend you click on the button at the bottom of the EBM page to download the “EBM Guide” as a PDF, and start measuring today!

An Introduction to Agile Emergent Architecture – Always Intentional

An Introduction to Agile Emergent Architecture: Always Intentional

Let’s Define Architecture
By definition, architecture is about the major pieces of the system^1, and about satisfying the non functional requirements such as availability, usability, compliance, scalability, security, extensibility , maintainability, and all of the typical “ilities.” It’s important to remember that architecture does not cover anything and everything that can be put into one of the above categories — because they would encompass every last bit of the *entire* system. The architecture should not encompass every last corner of the system. Instead, architecture focuses on the very highest level concerns in each of those categories, and nothing more than that. Further, architecture focuses only on the most basic of building blocks in those categories, and nothing more than that. This leaves as much flexibility as possible for later agility and implementation. So, be sure your architecture is focusing only on the highest of concerns. (The lower concerns might be considered such things as design, code, or implementation)

Big Up Front(BUF) Thinking
Legacy software development approaches put a large emphasis on understanding all the requirements for a system up front. This is also known as BRUF (Big Requirements Up Front). The disproven theory behind this thought is that if one understood all the requirements really well up front, then the most optimum architectures, designs, and software code could be created. As such, BRUF has siblings known as BAUF (Big Architecture Up Front) and BDUF (Big Design Up Front). All of these Big Up Front (BUF) approach theories have been disproven for one overall reason: it takes time to gain this BUF understanding, and by the time you do think you and your team have that understanding, the requirements have changed substantially, which then affects that architecture and design as well. What we have learned over the decades is that the requirements, technologies, users, technical team members, and the market for the product change quicker than we can gain that understanding, and certainly quicker than we can implement an architecture or design. In addition, customers often have trouble describing exactly what they want — they tend to have a much better understanding of what they want only after they see the working software. Further, with BUF thinking, usually the people that did the up front thinking are way different than the people implementing that thinking. So downstream from requirements, when changes to the architecture and design are truly needed, because of all of the previous history, BUF thinking, and totally different people involved, changes are extraordinarily costly *and* complex to retrofit. As such, Big Up Front thinking is a model that has been disproven, so it’s unacceptable, and indeed now.. passe.

No Up Front(NUF) Thinking
However, the other end of the spectrum, NUF (No Up Front Thinking), is also unacceptable. You can’t create a cohesive architecture, that is financially viable, without some good upfront thinking. Without at least some good upfront thinking, the architecture turns out haphazard, almost accidental in nature. Some people have called this unintentional architecture, and the name probably fits.

Signs you MIght be a Victim of NUF
One possible sign of NUF is a system rewrite. A system rewrite is almost always a sign of failure ^2, and the two biggest reasons for that failure are inattention to the user marketplace and inattention to continuous technical excellence via architecture, design, testing and coding practices. Inattention to continuous technical excellence creates what is known as technical debt, which is the other tell tale sign of NUF. Massive technical debt generally presents itself as a highly unacceptable amount of bugs, new functionality that takes way longer than it should, or systems that get jettisoned or re-written. Massive technical debt is pretty much a guaranteed outcome of No Up Front Thinking. As such, since massive technical debt has so many bad outcomes, No Up Front Thinking is also unacceptable.

Big Up Front thinking can lead to No Up Front Thinking
Now, before we move on, let me also address another relevant point. BUF thinking can actually lead to NUF. If a BUF architecture is not kept up to date, is not shepherded, or is extremely inflexible to change, people will avoid thinking about and making architectural changes. This results in NUF and massive technical debt. So, a single system can be a victim of both BUF and NUF. It would be really great if there was a way to find that right balance between BUF and NUF… right?

The Better Way: Agile Emergent Architecture
Enter “Emergent Architecture”, a term suggested by Agile thought leaders. One can think of this as Little Up Front(LUF) Architecture, combined with continuous attention to technical excellence. You could even think of it as “Continuous Architecture” if you so desired. With Emergent Architecture, you do just enough, just in time, at the “last responsible moment.” It’s also important to note that Emergent Architecture is also 100% intentional architecture. Architecture doesn’t just “magically appear”.

The Benefits of Emergent Architecture
By architecting at the last responsible moment, you are minimizing the requirement churn damage that accompanies BUF. By architecting at the last responsible moment, you are taking advantage of the latest and greatest technology knowledge. Finally, by architecting at the last responsible moment, you are very sure that the people collaborating on that architecture are the people that are about to implement that architecture. All of the sudden, the ingredients for success are all in the right place at the right time!

Technical Excellence
Technical Excellence can refer to architecture, design, testing, coding, and probably other practices too. Regardless of whether you do BUF, NUF, or Emergent Architecture, the ability to quickly and cheaply extend or change your software architecture at any given moment is directly proportional to your practices around technical excellence. The higher your technical excellence, the more quickly and cheaply you can change direction (<– indeed, this is the definition of agility). Having said that, in BUF approaches, since people make the mistake of thinking that they can “lock down all the requirements and architecture Up Front” , they rarely put in the technical excellence needed for rapid change. Examples of technical excellence are paired programming, collective code ownership, continuous integration, continuous automated testing, build automation and build pipelines, Test Driven Development, Unit Testing, lightweight code reviews, YAGNI, and many other practices. Agile approaches harness change for the benefit of the customer, so don’t forget Agile Manifesto Principle #9: “Continuous attention to technical excellence and good design enhances agility.”

Architectural Runway and the “Last Responsible Moment”
Now, let’s be careful with the “last responsible moment”. Note the word “responsible” in “last responsible moment.” For different architectural pieces, that last responsible moment will be at different times. Some architectural pieces will require a longer runway, and other pieces can do well on a shorter runway. In summary the more complexity and learning in the requirements, people, and technology, the longer the runway needed. If the complexity factors are low, then less runway is needed. Figure out that needed runway length (length of time before that architectural piece needs to be in place), and work your way back to when that runway needs to begin being built.

Let’s look at some examples.

Architectural Runway for a Deployment Platform
For example, determining the deployment platform(the initial UI, logic, and other tiers) for the Minimum Viable Product for a new product probably needs to happen before the first Sprint of developing that product. Having said that, let’s not regress to BAUF, but let’s do execute some upfront thinking and have that deployment platform pretty well figured out before that first Sprint. Since every Sprint has to include at least some small amount of user/business valuable functionality, it’s going to be hard to create some releasable software functionality *and* create your initial deployment platform all in Sprint 1. It is theoretically possible, but not likely.

Architectural Runway for an Open Source Logging Framework (Complexity is low, should be a fairly quick decision)
Another example of “last responsible moment” might be choosing an open source framework to do logging in your system. If logging is forecasted to be in Sprint 23, there is no reason to choose that framework in Sprint 3. You can probably wait until a few sprints before to begin working on that decision.

Architectural Runway for a 3rd Party Processing Component/Framework (Complexity is high, will be a long duration before a decision can be made)
Let’s assume the same as the above — we plan to begin using this component in Sprint 23, and we are currently in Sprint 3. We need to choose a large 3rd party proprietary component that does a large amount of processing or functionality(think accounting, medical, legal, or aerospace). Since it comes from a 3rd party, there is likely going to be a long runway needed to have that choice in place before functionality can be built on top of it. In this example, it might be perfectly fine to start the architectural discussions about which 3rd party framework to use and purchase in Sprint 3. Remember that you’re going to have to leave time for product evaluation, purchasing, legal, training/learning, and maybe even some technical investigation and technical spikes. It could actually take 20 sprints to execute that particular architectural runway and have the architecture first able to support business functionality.

Architectural Runway for logging standards across multiple teams(Complexity is medium, requires time for buy-in from multiple teams)
Remember that logging framework implemented in Sprint 23? Well, we’re now in Sprint 27, and now that the logging framework has been implemented on a couple of teams, the teams realize a need for standardization of use because the framework is beginning to be used widely across the product. At first people didn’t think this was a “high enough concern” to be considered architecture, but then then they realized that the teams were using widely different “logging levels”, that debug logging often crossed module/system boundaries, and that debugging across those modules was getting difficult. The teams finally realized that there would be some major value in ensuring some light standards were followed across the teams. Three might even be a nice wrapper around the chosen logging framework to make it easier for teams to use in a more consistent way. So, in Sprint 27, they began working on an architecture effort to solve those needs. By Sprint 31, the first teams were using the new wrapper and light standards. One thing to note here is that, back in Sprint 20, when they were originally choosing a logging framework, they could have chose to do all of that standardization up front — but that would have been BUF thinking, and they could not have predicted the ways the framework would be used. It’s very possible that no other team would ever pick it up and use it — as happened with most of their open source frameworks. In other words, they would have been heavily speculating needs rather than having a practical, experienced understanding of the real needs. Now, with the experience of a couple of different teams actually using it, in production, they can make better decisions about how to lightly standardize. In this way, they chose to do Emergent Architecture over BUF thinking.

Architectural Runway for Performance and Scalability(Complexity is highly variable here, depends on the product and the target stakeholders for the release)
Hopefully, if you have a new product, you have a Minimum Viable Product(MVP) release that doesn’t require supporting a zillion users concurrently. However, every product is different, so act accordingly. An MVP will certainly need to perform and scale in a way that meets the needs of the initial users. Get this wrong, and you will pay a very heavy price in terms of customer satisfaction and product adoption. As such, for an initial release, this topic is extremely important. The non functional requirements around performance and scalability will often be ordered high in your backlog, as they are both high value and high risk for an initial release. Having said that, sometimes premature optimization is a source of waste. The runway here will also depend on the tools and environments you need to do proper load testing. Choosing and setting those up can often take serious time, so that would extend the runway needed. So, the runway answer here is probably — “it depends.”

Architectural Runway for Government Regulatory Compliance(Complexity is highly variable here, depends on the weight/complexity of compliance, the agility of the agency, etc.)
The guidance for this piece of the architecture is almost identical to the factors involved in dealing with scalability and performance requirements. They are “must haves” that will often be ordered very high in the product backlog due to their risk and value. Note here that we are mainly discussing compliance needed by the product, not the process. (On a related subject, sometimes software process compliance ends up on your Definition of Done, which may or may not affect the product architecture or product backlog directly.)

The above runway discussions are just some examples to think about. The architectural runway for each of these needed pieces of the architecture will be different. As such, the “last responsible moment” to build that runway will require some serious thought as you refine your product backlog. Further, in order to deal with the unknown unknowns, you’d better put a time buffer into that runway since you can’t possible know the unknowable!

In Summary
Hopefully the above has given you a picture of what Emergent Architecture looks like. With each vital part of the architecture, you will need to consider the runway that gives you the “last responsible moment” and some buffer for the unknowns. Because the requirements will be emerging over time, so too will each of the architectural pieces. The architecture will emerge, or evolve, over time, but with intentional forethought to the necessary runway. Remember, due to the number and churn of moving parts (requirements, people, technology, etc) inherent in almost all software development, the *only* way to keep an optimum architecture over time is to give continuous attention to technical excellence. Finally, in order to avoid the gigantic trappings of BUF and NUF, Emergent Architecture is really the only sane choice.

(If you have several teams on the same product or in the same org who need to keep the Architecture of systems excellent, see:  An Agile Architecture Community of Practice


^1 The focus of this article is Agile Emergent Architecture, so we give only brief attention to a definition of architecture here. It’s worth noting that many thought leaders have multiple credible definitions of architecture. Further, Martin Fowler and Molly Dishman have mentioned that some think the term “architect” is not even the correct metaphor — that maybe “city planner” is the better metaphor.

^2 It’s worth noting that there are some very rare scenarios where a system re-write might not be a sign of failure. For instance, if the system re-write is an early pivot in a product’s lifecycle, it might make great sense and not be due to the above mentioned causes. Having said that, I’ve never personally seen a re-write that was due to a good reason.

How to Contact us for Scrum, Scaled Agile Coaching and Training

Contact us at ScrumCrazy to discuss tailoring a training or coaching program to align with your strategic goals. (We do work nationwide in the USA, as well as Internationally upon request.)

  • Email: service at ScrumCrazy dot com

Good Resources for Scaling Agile and Scrum

Good Resources for Scaling and Spreading Scrum and Agile

  1. Scaled Agile Framework
  2. Large Scale Scrum(aka LeSS) Resources
  3. Nexus Framework For “Scaled Professional Scrum” from
  4. My Presentation to Agile Denver Comparing LeSS, SAFe, and Nexus
  5.’s “Evidence Based Management for Software Organizations”
  6. Schwaber’s _The Enterprise and Scrum…_
  7. Cohn’s _Succeeding With Agile…_
  8. Kniberg’s “Scaling Agile at Spottify” (Free PDF)
  9. Schwaber’s _Software in 30 Days…_
  10. Larman/Vodde’s _Scaling Lean Agile…_ (Make sure you check out Resources in #1 above before reading #10/11)
  11. Larman/Vodde’s _Practices for Scaling Lean and Agile…_ (Companion book to the above)

ScrumCrazy My Preferred Agile, Scrum, and XP Resources

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

My Answer

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below.

My Preferred Resources

All below are in order of our recommendation in each category.


  1. The Scrum Guide (Only 16 pages, Must read for all)
  2. _Scrum: A Pocket Guide_ by Gunther Verheyen (Short book, Must Read for Scrum Masters, Management. Highly recommended for all others.)
  3. Chapter 1 of _Professional Scrum Development_ by Richard Hundhausen (Short read)
    • PDF download, see Chapter 1, which is a “must read” for all roles)
      • Don’t let the “Visual Studio 2012” part of the book cover fool ya — Chapter 1 is about Scrum and there is no tool stuff in Chapter 1.
  4. Doshi’s _Scrum Insights…_ (Short book, Must read for Scrum Masters)
  5. My article called “Scrum For Laypeople” (A good intro for total newbies or people who won’t be on the new Scrum Team. If you’re a manager or PO or someone interacting with the Scrum team, be sure to read #1 above if you haven’t already)
  6. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters, but note that some of the Scrum stuff is out of date, and some of the story stuff is more directed at the PO role)
  7. SSW’s video on the Product Owner Role (Must watch for new Product Owners — only 2 minutes!)
  8. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
  9. Hundhausen’s _Professional Scrum Development_ (The book is a must read for Scrum Development Team Members)
      • If your team doesn’t use Microsoft tools, then just ignore the chapters in the book about the MS tooling.
  10. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
  11. Goldstein’s _Scrum Shortcuts…_ (Great read for Scrum Masters)
  12. Derby/Larsen’s _Agile Retrospectives_
  13. Any article, blog post, presentation, or other material on Roman Pichler’s web site.
  14. Our web site, of course!
  15. The web site (especially the articles and forums)
  16. The Scrum Alliance web site (especially the articles)

XP (Extreme Programming)

  1. Jeffries’ “What is Extreme Programming?”
  2. Jeffries’ _Extreme Programming Installed_
  3. Koskela’s _Test Driven…_
  4. Martin’s _Clean Code_
  5. Feathers’ _Working Effectively With Legacy Code_
  6. “The Rules of Extreme Programming”
  7. Wiki entry on XP Practices

Testing – Agile/XP

  1. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
  2. Martin Fowler’s Excellent article on Unit Testing
  3. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
  4. Cripin’s “Using the Agile Testing Quadrants”
  5. Crispin/Gregory’s _Agile Testing_
  6. Crispin/House’s _Testing Extreme Programming_
  7. Osherove’s _The Art of Unit Testing_

User Stories (which originated in XP)

  1. I co-authored this article, and I’m pretty pleased with our work — a great starting place for learning about User Stories.
  2. My “User Story Basics” article and all of the links at the bottom of that article
  3. Cohn’s _User Stories Applied_ (Book is VERY dated, and definitely the Scrum stuff is way out of date)
  4. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
  5. Richard Lawrence’s “User Story Splitting Flowchart”
  6. My User Story Maturity Model (Has a list of User Story best practices)

Scaling and Spreading Scrum and Agile

  • Warning: Scaling Scrum is not for people or orgs new to Scrum. The first focus should be on doing “single team Scrum”. After that, when scaling, we strongly recommend getting Scrum Coaching help. The resources below, while all excellent, are dangerous and risky in the hands of people new to Scrum. We realize that this is a self serving statement since we provide coaching services, but we honestly believe it based on our own experiences of having to rescue companies from poor performing implementations. It costs much much less to get started on the right foot than to rescue an organization. Having said that, we love the challenge of rescues, so don’t be afraid to contact us!

This section has a page all it’s own now !

Dispersed, Distributed, Offshore, and Multi-Site Scrum (use only if applicable)

  1. Deemer’s “The Distributed Scrum Primer”
  2. Larman/Vodde’s _Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum_
    • Especially Chapters 12-13.
    • Note: This book is not for Scrum Newbies, but neither is Large Scale, Multi-site, and Offshore Scrum. Hire a Scrum Coach, or maybe a dozen.
  3. Woodward et al’s _A Practical Guide to Distributed Scrum_
  4. Cohn’s _Succeeding With Agile…_
  5. Numerous teams have gotten a lot of value out of the “Toss the Microphone ” Daily Scrum Pattern, and not just for Daily Scrums. Some teams use it for Product Backlog Refinement, Retrospectives, etc.

Special Topics of Agile (use only if applicable)

  1. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
  2. Agile Scrum Contracting Resources

Scrum For System Integration & Analytics Data Warehousing Teams


–This article was co-authored by Professional Scrum

Trainers Charles Bradley and Mark Noneman.


Things to Think About When Using Scrum for System Integration Efforts

Vendor Platform: Think of something like SAP or SalesForce App Cloud Platform. The platform might have some out of the box functionality, but really, to get the major value out of the platform you need to hook in all of your company’s data sources (usually with the need to do data ETL type work on the incoming data to transform it into the target data model of the platform). You will also need to “configure” (tailor/enhance) the out-of-the-box functionality to your specific organization. For example, using your organizations language for labels, implementing workflows, identifying roles and permissions, adding functionality through scripts or software, etc. Some Business Intelligence platforms (Informatica, Business Objects, etc) also fall into this category (at least in how they affect Scrum).

Since Scrum’s earliest adopters were “vanilla software teams”, often doing full stack development where software programming is the primary activity, System Integration Scrum Teams tend to be late adopters. As such, they suffer from several typical problems that even vanilla software teams suffer from as late adopters to Scrum. See more about that in the Top 10 Challenges to Scrum Adoption. In addition, certain challenges present themselves to vanilla software teams regardless of whether they are late adopters to Scrum or not. Analogous challenges happen in System Integration Scrum Teams, so it might be a good idea to familiarize yourself with the Top 10 Challenges That Scrum Teams Face.

Caveat: The term “vanilla software team” is just a term used for this article to distinguish System Integration Scrum Teams from your basic full stack development software team. Vanilla is not in any way meant to imply that “vanilla software” is easier or harder, only that it’s the more generic kind of software development. Having said that, System Integration, BI/DW, straight web development, and lots of other forms of software development are also extremely valid forms of software development. They’re just other flavors of software development that have some uniqueness about them.

When doing System Integration (SI), many teams like to use Scrum for this effort. Many SI Scrum Teams think that the challenges that they face when doing Scrum are unique to SI, but most of those challenges are not unique to SI at all. Having said that, there are some challenges that seem unique, or at least more accentuated, in SI efforts.

Challenges not Unique to System Integration

Here are some challenges that SIVP (System Integration of Vendor Product) Scrum Teams perceive as being unique to them, but they really aren’t unique to SIVP Scrum teams at all.

  1. Due to the proprietary unknowns about how the Vendor Platorm(VP) works, SI Scrum teams feel the need to do more spikes, analysis and design when requirement gathering.
    1. Most VP’s, whether due to feature bloat or having to deal with such a wide variety of clients, have several ways to accomplish a particular business need, which prompts teams to do more analysis or design in order to come up with system requirements that describe application behavior. This is understandable. However, when compared to vanilla software dev, the # of ways to accomplish a business goal is infinite, so this should make the number of ways to accomplish a goal in SI teams fewer than in vanilla teams, right?
    2. Due to the vendor product proprietary bits that are hidden from the Scrum Team(think of the VP as a “black box” component), it might take more time for a SI team to figure out good paths forward(analysis/design/architecture). Hopefully this can be mitigated by good platform documentation, team experience with the VP, and/or support/professional services from the vendor.
    3. All of the aforementioned challenges happen in vanilla software teams too. See “Extensive Discovery/Market Research”, “3rd Party Component Analysis/Design,” and “Complex Business Domains” in the Top 10 Challenges That Scrum Teams Face..
    4. In SI teams you tend to have a higher occurrence of situations where the dev work is small, but the number of User Story acceptance criteria (aka acceptance tests) is very large. The User Storry or effort can be said to be “lopsided.” This is sometimes due to the data heavy nature of SI, and sometimes due to the fact that once the data is in the VP, the VP GUI has numerous ways of viewing that same or similar sets of data. (Of course, the converse can also be a true — a whole lot of data manipulation, but it only shows up in one place in the GUI — that’s just lopsided in the opposite direction)
    5. VP’s usually require extensive configuration that will need to be tested against. This is really no different then finding the right balance of testing as mentioned in the points just above. This also happens in vanilla software teams when the system under development offers a ton of configuration choices. It’s another case where you might end up with lopsided stories.
    6. All of the above happens often in vanilla software teams too — see “Lopsided User Stories” in the Top 10 Challenges That Scrum Teams Face..
    7. Much more frequent traffic (real time, daily feeds) and volume in those data interfaces, and
    8. Much less knowledge about and control over those data interfaces. (which increases analysis/requirements time/complexity as mentioned in #1 above)
    9. Much higher number and impact from external dependencies on 3rd parties in development coordination, release deployment coordination, and in production support coordination. This cannot be emphasized enough. This is a heavy complexity multiplier that results in less predictability of software schedules.
      1. Even MORE extra complexity and delays here when the 3rd parties are using waterfall.
    10. The upstream/downstream data source challenge happens often in vanilla software teams too. See “Upstream/Downstream Systems”, “Waterfall Organizational Design by Application(WODA), and “External Dependencies”in the Top 10 Challenges That Scrum Teams Face..
  2. SI Scrum teams tend to have difficulties around writing poor User Story acceptance criteria
      1. This happens often in vanilla software teams too — see “Poor Acceptance Criteria” in the Top 10 Challenges That Scrum Teams Face.
  3. SI Scrum teams tend to have discomfort around not having “stories” that account for the time spent in refinement, understanding requirements, analysis, and just enough of the design to create proper User Stories with the INVEST attributes.
    1. This happens often in vanilla software teams too — see “Massive Unknowns” in the Top 10 Challenges That Scrum Teams Face..

Challenges that are Mostly Unique to System Integration

Now, finally, here are the few challenges that the authors have seen that seem to be mostly unique to SIPV Scrum Teams.

  1. Test automation at the GUI level might be challenging since you may not have as easy access to the undercarriage or GUI of the VP GUI.
  2. SI Scrum teams tend to struggle with incorporating Vendor professional services personnel into their Scrum implementation
    1. This is especially difficult when the vendor is either not Agile friendly or when they want to matrix specialists in and out of the team rapidly like special forces (In Agile we call this “specialist silos”, and it’s waterfall thinking — we want T-shaped skills and long lived team members instead)
    2. Scrum Teams should get to interview and help choose new dev team members, but vendors usually don’t allow for this.
    3. Waterfall thinking in terms of fixed scope/fixed date vendor professional services contracts can misalign with Agile principles.
  3. There is an extremely low amount of “on point” Agile/Scrum literature about how to use Agile/Scrum practices for system integration type work. As we have shown above, many of the Scrum concepts transfer readily, but the literature almost always gives examples from vanilla software development. This can lead to further “snowflake”/ScrumBut thinking (see “The Snowflake Objection” in the Top 10 Challenges to Scrum Adoption.)
  4. SIVP teams often feel that their tool is the “Golden Hammer” for all the work related to their domain. For instance, they might be able to solve a particular problem using 15 transformation steps, when they could have written 15 lines of custom code instead, possibly reducing a 6 week story into a 1 week story. This is not a direct threat to Scrum per se, but it can impact a team’s creativity and cause a dysfunction where stories are constantly carrying over from sprint to sprint. Also, it might be a sign that the team is not terribly cross functional, which can cause other complications with respect to Scrum. Last but not least, it could save 5 weeks of dev time and money! –Submitted by Professional Scrum Trainer Jesse Houwing

Top 10 Challenges That Scrum Teams Face

Below are the top 10 challenges we see Scrum Teams facing in terms of trying to execute and reap business value utilizing Scrum. These problems are faced by all software Scrum teams, whether the teams are doing more straightforward full stack software development, data warehousing, business intelligence, web sites, system integration, etc. All of these types of Scrum teams see these challenges.

  1. Scrum Adoption Challenges At the Org Level: Almost all Scrum Teams struggle due to organizational level Scrum adoption challenges, and many of the below are just specific instance of those challenges. As such, it’s probably a good idea if you go ahead and familiarize yourself with the Top 10 Challenges to Scrum Adoption.
  2. Leadership Refuses to support Scrum and/or Refuses to get Proper Training/Coaching for Scrum Teams: Scrum is night and day different from what you used to do, and because orgs “don’t know what they don’t know”, they often refuse to invest in proper training and coaching. Learning about Scrum is easy. Doing Scrum is incredibly difficult, but it yields a 3-10X success factor, so it’s worth the effort to do it. A training class or coach can accelerate the learning curve by months or even years.
  3. Upstream/Downstream Systems (External Dependencies):
    1. Some software teams have a large presence of upstream and downstream systems and/or data sources. Most software teams have more control of their own data, but the presence of many upstream/downstream systems means the control of the data can be scattered far and wide across the organization. This is often present in companies/orgs that are late adopters to Scrum. See “Waterfall Organizational Design by Application (WODA) in Top 10 Challenges to Scrum Adoption.
      1. In particular, “vertical slicing” in software development, with respect to User Stories, doesn’t seem to be the best metaphor for stories that have a lot of upstream and downstream system dependencies — maybe “end to end” or “expected inputs / expected outputs of the system” or “I/O channels” are better metaphors for those kinds of stories. See this alternative to the typical User Story Slicing model.
    2. While Upstream/downstream systems tend to be the most damaging External Dependencies, there are many other kinds of external dependencies that can be damaging as well. Delays in signoffs from other departments (legal, finance, hardware/software acquisition, marketing, release management, software operations), as well as delays or errors from dependence on skill specialists (architects, dba’s, other component teams, etc) can also damage flow and value delivery.
  4. Creating Releasable Software Every Sprint: Often times a Scrum team will not be able to create a releasable bit of software every Sprint, even though that is strictly required by Scrum. The impediments to creating releasable software are often due to the above and below challenges or due to more organizational level Scrum adoption challenges. Regardless of the source, teams and Scrum Masters across the org need to band together to attack these impediments to creating releasable software every Sprint.
  5. Poor Acceptance Criteria: Many software teams have trouble learning how to create and communicate well structured Product Baklog Items or User Stories that have good acceptance criteria (aka acceptance tests).
    1. Sometimes stories:
      1. Do not describe system boundaries, but instead intermediate steps (aka acceptance criteria that are really technical tasks, so called “technical stories”, or design instead of requirements, etc) or
      2. Have acceptance criteria that is not described in end the user/domain language — but in technical language instead
      3. Do not respect the INVEST criteria
    2. The above challenges can be mitigated by having a Scrum Master or Agile Coach who is strong in User Story practices and technical enough to know the difference between system boundaries and intermediate technical steps. (As always, there are trade offs: having a Scrum Master who is technical can invite technical micromanagement from that technical Scrum Master)
    3. We put this challenge close to the top because it’s usually the first one you want to tackle with a team new to Scrum(after getting some Scrum basics right, of course). The reason this one is so damaging is not about adherence to Scrum practice, but because the failure to adhere to this particular practice means you lose a TON of transparency onto what is working well and what is not working well in your team’s software delivery efforts. Get this one right early on, and you will have maximum transparency. Get it wrong… well…. get it wrong, and you will have just about every challenge on this page, and several of the challenges that didn’t even make this list. (the decrease in transparency makes it much harder to see those challenges — so they will last much much longer too)
  6. PO Unavailability: Many software teams struggle with getting a business side Product Owner who can engage enough with the team. This creates a huge chokepoint in the most important stream of work — the Product Backlog. This spawns off many other anti-patterns. There are several ways to skin this cat, but a good start is making sure the team has a good grasp on the Product Owner role basics, as well as the /modern definition of the Product owner role. There are lots of ways to solve this challenge, but they depend heavily on your organizational context and the root cause of your challenge.
  7. Little Access to Users and Key Stakeholders: This is an age old problem in software development, exacerbated by Waterfall habits. The Scrum development team members should have direct access to the users (if they are internal to their org) or at least direct access to user analytics (if users are external to their org). Sometimes built in telemetry and A/B testing can help with understanding the user viewpoint as well. When choosing which Scrum team members to talk to the end users, you definitely want to pick ones with good comm skills as well as coach them to never make forecasts or commitments on when particular functionality will be delivered. The goal is to get super early, super direct feedback from users as early as possible, preferably as early as during the release planning or Product Backlog Refinement process and definitely in the Sprint Review. It’s also worth noting that this challenge, along with “PO Unavailability”, create another large challenge: the Development Team has no idea what business value their Product is delivering. This is very very damaging to the overall effort and wastes a massive amount of product development money.
  8. Scrum Outsiders: People who are outside the Scrum team often attempt to apply Waterfall management practices onto the Scrum team, without recognizing they are almost certainly harming the Scrum Team by doing so. These are usually front line management or project management who has never been to Scrum training and/or never practiced Scrum. These people need to compensate for this lack of experience by doing some deep learning on Scrum, and accept coaching from their Scrum Masters and Scrum Coaches. It’s worth noting that the Scrum Master has a specific duty in Scrum to coach those outside the Scrum team on how best to reap the benefits of Scrum. A good, cheap, entry level learning experience would be for all involved management to get the PSM I certification, which only costs $150 to attempt the cert exam.
  9. Massive Unknowns: Some software teams, during certain development periods in the product’s lifecycle, will go through a period of having a massive amount of unknowns (people, requirements, infrastructure, technologies, green field development, etc). Truth be told, all software development is complex and has significantly large unknowns, so the issue we’re describing here is when there seem to be a massive amount of unknowns. There is often a discomfort on Scrum Teams around not having “stories” that account for the time spent in refinement and discovery understanding these unknowns (discovery, requirements, analysis, and just enough of the design) to create well structured User Stories with the INVEST attributes. Teams will be tempted to create “Analysis Stories”, “Design Stories”, and “Spike Stories” to account for this time, thought this is really just a waterfall habit. (“Technical Stories” is sort of the “broader term” to describe this waterfall habit of feeling the need to create stories for any team activity that takes significant time)
    1. This one is especially damaging because many orgs decide to try Scrum for the first time with a “new project” or major new product development effort. Due to the organizational pressure exerted around such efforts, often times management and teams are very quick to backslide into waterfall thinking and feel the need to create a story to describe every significant activity of the team. This is really just a sign of thinking the Product Backlog in Scrum is the equivalent of a traditional Project Management project plan. That is not what a Product Backlog is at all, and because the Product Backlog is the centerpiece of work in Scrum, this is a particularly harmful anti-pattern that spawns many other anti-patterns. See the discussion on “Treating the Product Backlog like a Project Plan” in the Top 10 Challenges to Scrum Adoption.
    2. 3rd Party Component Analysis/Design: Many software teams choose to use 3rd party proprietary software components (libraries, frameworks, web services, API’s created by another organization or from outside the organization), or even open source components that are not well documented/supported.
      1. These components often behave like black boxes with proprietary bits that are not visible to the component integrators, which creates challenges around how to use the component wisely, This often requires more analysis/design up front about how best to learn and use the component. This work can be folded into Product Backlog Refinement.
  10. Extensive Discovery/Market Research: Some teams have a challenge where more refinement and analysis might be needed than other teams in order to understand the target market for the product. This is especially challenging for product companies that sell software or products to the public.This can be mitigated by having more personnel committed to market research or by having market experts working closely with or on the Scrum Teams. This can also be mitigated by simply having market experts take the time to teach the Scrum Team about the market.


What Now?

You may be asking yourself, or asking us, “Ok, so great, but how do we solve these challenges?”. The best way to solve these challenges is to find people inside or outside of your organization who are heavily experienced and/or heavily certified in Scrum techniques (preferably they have both heavy experience and heavy certification). Obviously we provide those services (see the “About” link above for how to contact us), but we don’t want this article to be a sales pitch about us. First, listen to the Scrum Experts in your organization, then partner with them and accept coaching from them. They will lead you down the path that will enable your best understanding of these large challenges to Scrum Teams.

A Few More Challenges

Below are a few more challenges to Scrum Teams that we found to be of interest.

  1. See our list of the Top 10 Challenges to Scrum Adoption
  2. 3rd Party Component Testing: There is a question as to how much testing should be done against the component since in it’s already been tested by it’s creators.
    1. Most teams use a “spot check” mentality when testing includes 3rd party component behavior, with a focus on
      1. More testing on the extensions/glue code that your custom code brings to the table.
      2. Lots of end to end testing that also does “spot checks”
    2. Speaking in terms of the Test Automation Pyramid, this would call for a heavier focus on “Integration” and “UI” testing that is more end to end focused. Both of those higher levels of testing end up using more tools and scripting languages rather than programming languages (programming languages are generally more focused on unit testing ). Compared to Unit testing, “Integration” and “UI” tests are more expensive to create and maintain (but the excellent ROI of automated testing is almost always present once learning curves are dealt with)
  3. Complex Business Domains: Some software teams operate in automating business domains that are extremely complex. Examples are: aerospace, medical, telecom, embedded devices, or domains where compliance rules are complex — banking, security, etc. Examples that might not be as complex are: social media, retail, web sites centered around content, education, etc.
  4. Lopsided User Stories: Most software teams experience situations where a particular User Story seems extra heavy in either the coding or testing effort. A good rule of thumb for the number of acceptance criteria(aka acceptance tests) for a single User Story is somewhere around 3-5, which usually reflects a “little bit of coding”, and a “a few acceptance tests”. However, sometimes one line of code can spawn dozens of acceptance tests, and sometimes a ton of code results in only two acceptance tests. This “lopsided-ness” will also probably heavily influence how you split the story.

Top 10 Challenges to Scrum Adoption

Organizational change is hard, right? When adopting Scrum in your team, or in your organization, you will often encounter many challenges moving to the new way of thinking. Knowing these challenges helps you improvise, overcome, and adapt to solve these challenges. We’ve been working with Scrum teams since 2008, so our view of the top challenges is certainly colored by our own experiences. We chose not to directly address the “scaled Scrum” (i.e. multiple teams closely coordinating on the same product/system/value stream) challenges. That might be the subject of a future article.

  1. Leadership that Refuses to get Agile Coaching and Training specifically for Leadership
    • In the “2017 State of Scrum” survey, the #1 most important consideration when adopting Scrum was “Active senior management and support”. #3 was Participation of experienced Scrum trainers and Scrum coaches. The TOP 3 items causing tension between Scrum teams and the wider organization were: Top Down Command and Control management, Resistance to change (by the org), and lack of understanding or support (from the org). The #1 motivator for undertaking an Agile adoption was “Active senior management sponsorship and support.” In this article from Harvard Business Review, co-creator of Scrum Jeff Sutherland drives home that Executives should get in depth training on Agile/Scrum (i.e. not the “Executive Summary”):

“When we ask executives what they know about agile, the response is usually an uneasy smile and a quip such as ‘Just enough to be dangerous.’ …because they haven’t gone through training, they don’t really understand the approach. Consequently, they unwittingly continue to manage in ways that run counter to agile principles and practices, undermining the effectiveness of agile teams in units that report to them…With the best of intentions, they erode the benefits that agile innovation can deliver.”

    • This challenge is best described with a true story we heard from a well respected Agile thought leader.
      • Company: “We want you to come teach your Agile Leadership class, but instead of 2 days, we’d like you to shorten it to a half day.”
      • Very well respected Agile thought leader/trainer: “Why only a half day?”
      • Company: “Our company leadership doesn’t have enough time to sit through a two day class on Agile.”
      • Agile Thought Leader: “Then we don’t have enough time to get involved with your failed Agile transformation, because that’s what will happen. Let us know when your leadership is ready to succeed instead of fail.”
  1. Waterfall Thinking
    1. In the “2017 State of Scrum” survey, the #2 reported Challenge to implementing Scrum was the difficulty of transitioning from Waterfall to Scrum.
      1. Because this anti-pattern is so prevalent, there are many names used to describe this phenomenon: Scrum in Name Only, WaterScrum, Scrummerfall, flaccid Scrum, the Methodology Facade Pattern, Cargo Cult Scrum, Half Baked Scrum, Fake Agile, Faux Agile, FrAgile, Agilefall, Agile Hybrid, waterfall backsliding, waterfall inertia, etc.
        1. The “Agile Hybrid” is one where your organization is sort of thinking halfway in Agile, halfway in waterfall. Some orgs try to blend Agile/waterfall, but that in and of itself is Waterfall Thinking. Agile approaches like Scrum form an ecosystem of interlocking parts. Remove even one of the more important interlocking parts, and the ecosystem will degrade over a period of time and then fail altogether, and it will be an absolute morale killer. Because the failure sometimes takes a while to occur, it is sometimes hard for the Agile beginners to know why it failed.
      2. Note that there are many other spinoffs of waterfall: RUP, Spiral, Iterative, traditional Project Management, and some people even consider Kanban a spinoff of waterfall. So, when we talk waterfall here, we are also speaking of waterfall’s “children” too.
  2. Assuming Agile is quick or easy to Adopt
    1. Many orgs, and indeed some Scrum Coaches, act like a team or an org can adopt Scrum or Agile techniques within a few months, AND reap all of the benefits of Agile in the same time frame. It doesn’t work that way. First you have to learn to walk, then jog, then run, then fly. While a few benefits can accrue early, it often takes months or years to get good enough at these techniques to reap the /3-10X more successful benefits.
  3. Waterfall Organizational Design by Application (WODA) (aka “Too many Component Teams”, creates unmanageable “External Dependencies”)
    1. In the “2017 State of Scrum” survey, the #1 reported Challenge to implementing Scrum was organizational design.
    2. WODA is present in an org where there is a team, dev manager or project manager who “owns” one or more applications (systems/products, etc). in the org. or where applications live in silos and have a ton of upstream and downstream connections to other applications. Features often cross multiple apps, apps owning a particular set of biz logic or functionality. This creates a traffic gridlock pattern in the organization where no one is able to make much progress on anything. While people and teams appear to busy, overall value delivery slows to a crawl and software deliveries are constantly late and impacted by each other. Simply starting to use Agile terminology and practices won’t solve this problem, though it will make the problem much more visible.
    3. The other big problem with WODA is that it often involves dev managers who “own” an application. These app owner dev managers often interfere with the Scrum roles as such:
      1. Interfere with Product Owner: Assigning work to the Scrum Team without going through the Product Owner.
      2. Interfere with the Scrum Master: Allowing Dev Team members to escalate impediments directly to the dev manager rather than to the Dev Team first, then Scrum Master, then the dev manager if needed.
      3. Interfere with Dev Team: These well meaning managers often try to manage day to day tasking or by misinterpreting Scrum artifacts and techniques. Another way to interfere is to use performance appraisals of Dev Team members has a way to maintain command and control authority over the team.
      4. It’s important to note that many of these managers have good intentions. In many ways, these managers are still being judged on their ability to “own” an application or function, so they think they are doing the right thing for the company, but they are not. The root cause of this problem is usually a lack of Agile/Scrum knowledge on the part of the managers and the leadership/people those managers report to (See #1 above). Managers need to learn how to be effective leaders in a Scrum organization.
      5. WODA is a larger version of a strong preference for Component Teams in an organization, again, a Waterfall holdover(hangover?). The org needs to move to Feature Teams instead.
  4. Waterfall Organizational Design by Function (WODF)
    1. In the “2017 State of Scrum” survey, the #1 reported Challenge to implementing Scrum was organizational design.
    2. WODF (just as bad or worse than WODA) is when your organization is trying to do Scrum or be Agile, but the structure of the organization is still designed for waterfall. The worst examples of this are functional silos, where the people in different functions (architecture, programming, testing, UX design, business analysis, project management, release management, DBA) are all in different departments and/or report up to different functional hierarchies. This dysfunction can also present itself as:
      1. Individual functions sit together, rather than cross functional teams sitting together.
      2. Teams that are highly dispersed/remote in multiple locations and timezones rather than being co-located in the same room or Agile Team Workspace. Truth be told, dispersed teams don’t work well in waterfall either.
      3. Misaligned guidance coming down to teams from differing functional hierarchies.
      4. Annual budgeting processes that involve wishful thinking predictions about schedule, scope, and cost.
      5. Too many layers of functional management
      6. Too much authority being projected onto individuals by their functional managers who write their annual performance reviews.
      7. A separate department or team for any of the above mentioned functions. Ideally, in Agile organizations, all of those functions for a particular team would report to the same management regardless of their function.
      8. The other big problem with WODF is that it often involves functional managers who “own” a particular function (Programming, Testing, Arch, etc). These functional dev managers often interfere with the Scrum roles as such:
        1. Interfere with Product Owner: Assigning work to the Scrum Team without going through the Product Owner.
        2. Interfere with the Scrum Master: Allowing Dev Team members to escalate impediments directly to the dev manager rather than to the Dev Team first, then Scrum Master, then the dev manager if needed.
        3. Interfere with Dev Team: These well meaning managers often try to manage day to day tasking or by misinterpreting Scrum artifacts and techniques. Another way to interfere is to use performance appraisals of Dev Team members has a way to maintain command and control authority over the team.
        4. It’s important to note that many of these managers have good intentions. In many ways, these managers are still being judged on their ability to “own” an application or function, so they think they are doing the right thing for the company, but they are not. The root cause of this problem is usually a lack of Agile/Scrum knowledge on the part of the managers and the leadership/people those managers report to (See #1 above). Managers need to learn how to be effective leaders in a Scrum organization.
  5. Waterfall Organizational Design by Matrix (WODM)
    1. In the “2017 State of Scrum” survey, the #1 reported Challenge to implementing Scrum was organizational design.
    2. WODM is essentially a special case of WODA, where a brand new “team” of “silo skill specialists” is assembled for each new “important” project, where the new “team” is formed by cannibalizing members from other existing teams, or worse, by cannibalizing people from other teams by saying things like “you are now dedicated 30% to this new project A, while maintaining your 40% on project B, and 30% on project C). The rest of the problems suffered by this design are described in the WODA section elsewhere in this article.
  6. Big Bang Release Strategy(BBRS)
    1. This dysfunction is characterized by orgs attempting to change to Scrum but keeping the waterfall habits of big bang releases. While some improvement can come to Scrum teams in these scenarios, often the big bang waterfall bias will make these teams operate more like waterfall teams. (aka FrAgile, WaterScrum, etc — see “Waterfall Thinking” above) If your org is planning releases for a single product that span more than ~2 months, you are still doing big bang releases.
    2. Also prevalent in this challenge is the failure to understand vertical slicing of PBI’s/User Stories that have INVEST qualities, Minimum Viable Products, and the inability to recognize the value of incremental software delivery and short feedback loops from end users.
  7. The Snowflake Objection
    1. This is the “Scrum won’t work for us” mindset that usually sounds like “Our team/org/business domain is ‘different’ than everyone else doing Scrum, so Scrum won’t work here without serious modifications. This also known as “ScrumBut,”, “Incorrect Scrum”, etc
    2. Scrum has been proven to work in ALL software development efforts in all industries. Vanilla software development, System Integration, Data Warehousing, Business Intelligence, Analytics/Reporting, small orgs, large orgs, external software, SaaS, internal systems — you name it, Scrum works great. Just do a google search and you can find people who have done it and written about it. You can also check out the Scrum Case Studies web site.
      1. A project mindset instead of a Product mindset, and the failure to recognize how early and often value delivery to end users is a huge business advantage of Agile practices
  8. Adherence to Failing/Legacy Project Management techniques
    1. The Iron Triangle. Another key sign of Waterfall Thinking is any kind of preference for fixed date/fixed scope deliverables(aka the “Iron Triangle”). In the Agile space we call this “wishful forecasting” or “wishful thinking”. Software development is an inherently complex activity. Only 14% of Waterfall projects are able to meet the schedule/scope/cost iron triangle. Agile Scrum approaches are 3X as likely to meet the iron triangle, but this still is not a very accurate way of judging software success.
    2. Projects instead of Products. Communicating in terms of “Projects” (Waterfall) rather than Products (Agile) or Product Value Streams (Agile). This is often tied to Waterfall funding mechanisms like Annual Budgeting, and funding projects(Waterfall) instead of teams(Agile) or sets of Teams (Agile).
    3. Treating the Product Backlog like a Project Plan. Many orgs assume that the Product Backlog is a project plan, thus including every single activity on a team that takes time. One huge indicator of this is product backlog items or stories that do not represent software features (Technical stories, Analysis stories, etc) This is a huge misunderstanding. The Product Backlog is a Feature Breakdown Structure (Agile), not a Work Breakdown Structure(Waterfall). It’s focus is on feature delivery times, not tracking everything a team does.
  9. Lack of User/Business Engagement
    1. Especially damaging are these mindsets from business side stakeholders and end users
      1. “You’re doing a rewrite/upgrade — just make it work how the old system worked with a few tweaks, and call us when it’s all done.”
      2. “We’re going to need all of the functionality before it’s useful to us or before we’ll give you feedback. Call us when it’s done.”
      3. “We’re too busy doing our day jobs to collaborate and give feedback to you every Sprint”
      4. “We are on board with Agile, but we don’t have time to participate in that ourselves”

What Now?

You may be asking yourself, or asking us, “Ok, so great, but how do we solve these challenges?”. The best way to solve these challenges is to find people inside or outside of your organization who are heavily experienced and/or heavily certified in Scrum scaling techniques (preferably they have both heavy experience and heavy certification). Obviously we provide those services (see “About” link at top of page for how to contact us), but we don’t want this article to be a sales pitch about us. First, listen to the Scrum Experts in your organization, then partner with them and accept coaching from them. They will lead you down the path that will enable your best understanding of these large challenges to Scrum Adoption.

Also, see our list of Top 10 Challenges to Scrum Teams for some team level challenges.

Some other Challenges

Here are some topics that didn’t make the top 10, but are likely in the next 10 challenges to Scrum Adoption: Dev Manager Mindset Change, Component Team Preference, Failure to Embrace Scrum (CoP, dedicated SM’s, New Career Pathing, etc)Waterfall Annual Budgeting Systems, Managing via Waterfall Metrics, Status Report thinking, Lack of Test Automation Skills, Slow/Dysfunctional Value Streams, Manufacturing Mindset, System Re-Write Death Sprials, Death March Scrum, Technical Debt Buildup, “I” shaped teams/people, Technical Stories, Software that is not Releasable. has Moved…

To contact us about our Coaching/Training services, please see the About page.

So, our old content engine provider,, went out of business, so we are migrating the most important/valuable articles over to this blog, incrementally of course.  Some of those are linked below.

If you find yourself distraught because an article from that you really enjoyed is no longer accessible, send us a request to re-post the article here on the blog.  Hint: we give high priority to the articles that are requested by you!  Just send an email to by putting “service@” prior to the domain name mentioned earlier in this sentence (trying to defeat the spam bots).  In your email, include any old posts that you are hoping for us to bring back.

Popular Migrated Posts:


%d bloggers like this: