Random Acts of Architecture

Wisdom for the IT professional, focusing on chaos that is IT systems and architecture.

Tag Archives: Process

The Problem with Agile Transformations

Leave a comment Posted by on July 5, 2021

It seems every organization wants to transform itself to become more agile. They want to respond to opportunities quickly and cost-effectively. They want to adapt faster than their competition in the Darwinian corporate landscape. COVID-19, for example, required a quick shift to remote working for their employees and remote interactions with clients and suppliers. Geopolitical changes alter supply chains and increase legislation. Cloud, IoT and similar internal IT trends accelerate.

An agile transformation often starts with a consultant-led agile processes adoption. These range from methodologies like Scrum at the small scale and Scaled Agile Framework (SAFe) at the highest. Despite some negativity in the agile community aimed at higher scale methodologies, these methodologies help by providing structure, vocabulary, and expectations.

However, following an agile process is the least important part of being agile. An organization attempting to increase agility solely by adopting a new process usually creates superficial changes that foster change fatigue, at best, or failure, at worst. This failure is often then incorrectly attributed to the process without any more profound and helpful introspection, leading to the negativity mentioned earlier.

An agile organization needs agile systems. “Agile systems” does not refer to using a tool like JIRA to track work. Agile systems, both IT and business processes, are easily changed and provide feedback for timely validation or correction.

Modern software development practices are a good example. Frequent demos to users and stakeholders and automated testing and deployment, for instance, ritualize change and create tighter feedback loops.

However, an organization’s systems are not agile if only their software development teams are agile. For example, consultants often build organizations’ back office and operational systems by customizing third-party tools. Organizations then maintain them with skeleton teams and, therefore, usually lack the skills or the environment to change them safely and cost-effectively.

Product Owners are not the answer. Product Owners can shield their team’s backlog to encourage agility. However, systems are more extensive than just the team or teams that maintain or implement them. Product Owners are also usually experts in the business area and handling internal politics. They are rarely also design experts and incentivized to think strategically.

Agility extends to data. Organizations are under increasing pressure to collect and monetize data. Agility requires knowing where that data is (“systems of record”), ensuring its quality and integrating it with other systems (“systems of engagement” or “systems of transformation”).

Governance systems must adapt. Regulatory, financial, legal, risk, IT security, privacy and similar teams must work in smaller batches. A lengthy, formal review of a completed system is often too late.

Unfortunately, articulating the benefits of agile systems is difficult. Pruning teams to their minimums has clear short-term financial benefits. Executives often overstate their systems’ capabilities through ignorance or self-promotion. Product teams may fall into the trap of a short-term, sales-oriented focus under the guise of being customer-focused. A system’s agility often depends on an executive’s skill at shielding budgets or convincing stakeholders.

These problems may extend to company culture. Business processes sometimes lack an agreed, empowered business owner. IT is sometimes “seen and not heard”. Insufficient executive representation or ownership means minimal focus and support, making agility practically impossible.

An agile organization also needs an agile structure. This statement may sound tautological. However, an otherwise agile organization that cannot leverage and benefit from that agility wastes that effort.

A good example is what SAFe terms the “network” versus the “hierarchy”. Most organizations structure themselves hierarchically around similar skills for ease of management. For example, an organization often has a legal department for lawyers, a sales department for salespeople and an IT department for developers and system administrators.

However, work frequently requires people across different teams to cooperate, called the “network”. Identifying value chains then building and supporting these multidisciplinary teams to implement and enhance them increases flow, ownership, and individuals’ agency. Effective use of “networks” requires different management techniques and incentivizing outcomes, not throughput. These often fail without executive support.

Organizations are rarely homogeneous. Some teams or systems may be more agile than others, such as through mergers/acquisitions or pockets of conscientious staff. Tracking and aligning these is vital. Otherwise, some teams may adopt inconsistent processes or tools, be omitted from the transformation or optimize at others’ expense.

This all assumes the organization’s bottleneck is the lack of agility. Organizations frequently want to decrease “friction” but cannot articulate it beyond the highest level. Defining friction by actionable, measurable metrics is a prerequisite. Increasing agility also only highlights any poor prioritization or lack of focus.

The “transformation” concept is also a misnomer. Agile thinking encourages constant self-evaluation and improvement, and this “transformation” does not end when the consulting engagement does. From the executive viewpoint, this can scarily move the fulcrum of structural control into the middle and lower levels of the organization.

The chosen agile methodology’s principles best guide agile transformations. Unfortunately, people easily gloss over these in favour of the easily implemented and more prescriptive processes. However, these are often what the more prescriptive parts are derived from, not vice versa. If you want to be agile, internalize the principles!

Agile transformations are more than superficial changes. Focusing too much on process changes instead of systems and structures often stalls or blocks agile transformations. Instead, these transformations require people to move outside their comfort zones, particularly executives. The problem with agile transformation is it is hard but increasingly necessary.

The image is from https://digileaders.com/webinar-shape-agile-organisation/, used under Creative Commons license.

Architecture, Op-Ed , , , ,

Toppling alpha developers

Leave a comment Posted by on May 18, 2018
Building blocks

Many people are attracted to software development because they love technology and development. Viewing it more as a hobby they are paid to undertake, they gladly spend time outside work solving that nagging problem, mucking around with the newest framework, contributing to open source software or exploring opinions on Twitter.

There is a subset of software developers that takes this to extremes. It is possible for someone that does not “eat and breathe” code to still take pride in their work, to still be a craftsperson or to want to learn more and improve. However, alpha developers make software development part of their identity and their desire for respect drives them to competitiveness.

From a hiring organization’s perspective, these alpha software developers are wonderful. Their pride dictates they produce high-quality work, often at the expense of their personal time. Training costs are minimal because they already know or quickly assimilate new tools, frameworks or techniques. Their competitiveness can force everyone to produce and learn more. They are happy to leave business decisions to others and focus solely on the technical. While these all have downsides, successful companies have learned to temper them.

However, alpha software developers create barriers. Alpha developers’ pride compels them to take technical leadership roles and demand others live up to their standards. Their knowledge of new tools and techniques and almost overriding urge to try them out can shut out discussions of other solutions. For those less enamoured with software development, alpha developers can be intimidating.

When asked to train others, alpha developers feel that owning one’s technical development and career path is a rite of passage. It is not that they look down on people who know less, more that alpha developers made the effort to train themselves so why should others be given special treatment?

Meanwhile, alpha developers feel their performance is judged on their own output and helping others interferes with that. Indeed, alpha developers will work around other developers if they feel they have to “save the project” by rewriting others’ code or taking on others’ work out of impatience.

This problem is exacerbated when alpha developers move into leadership positions. When hiring new developers, they perceive alpha developers as superior and hire them over others. When evaluating others, they reward alpha qualities.

Focusing on alpha software developers creates a monoculture, focused inward on technical prowess and knowledge. Decisions need broad, representative viewpoints. While few companies will have ample members of the target audience on staff, few companies’ target audiences are solely alpha software developers.

This relegates non-alpha developers to permanent “junior” roles. This blocks their career progression even though they may be well suited to roles that software development feeds into like business analysis, user experience, consulting, quality assurance, IT administration or solution architecture.

This also risks the competitiveness between alpha developers boiling over to conflict or burnout. Like a sports teams, having too many ego-driven superstars creates problems. Teams work best with people in a variety of roles and software development is a team sport.

Solving a problem like this, particularly something a deeply ingrained in software development culture, is not simple.

The first reaction is to move away from using lines of code or other similarly easily measured metrics as the primary determinants of productivity to ones that indicate the success of the project. This encourages a team-centric view of productivity, not individual-centric.

However, the problem is deeper than that. Like using the term “craftsperson” instead of “craftsman” at the start of this post, we need specific language to drive specific thinking. It is hard to conceive of ways to drive value without terms to describe them.

For example, a “developer experience” engineer could focus on improving the efficiency of existing developers and hastening the onboarding of new developers. While documentation is part of this role, its focus is more on fixing inconsistent APIs, gathering useful diagnostics, ensuring error messages are complete and descriptive, replacing or fixing buggy libraries and improving internal tool reliability.

This role focuses on the productivity of other developers and understanding how they work instead of raw lines of code. This person should not get too involved in the internals of the software. Otherwise, he or she may start to overlook or forgive bad practices.

Another potential role is a “business process integration” engineer. Working on a lower level than a user experience engineer, they look at product customization, integrations and automation/orchestration opportunities. For internal systems, this could be about integrating the system into a Business Process Management (BPM) or workflow solution. For external systems, this is similar to a customer-facing solution architect but works with the code directly to help users customize or leverage the product.

This role requires an understanding of the broader business context, how software is used by the organization and what the organization views as important. It is a good conduit into business analysis or enterprise architecture.

This all boils down to a search for value. While focusing on software is what others would expect software developers to do, focusing it to the exclusion of some of the software development community is a poor strategy. We need to change how we view and measure our software developers and change who we see as aspirational.

Image from https://commons.wikimedia.org/wiki/File:Autism.jpg. Used under creative commons license.

Op-Ed, Software Development , , , , ,

Big Design Up Front versus Emergent Design

4 Comments Posted by on July 8, 2013

BDUF vs Emergent Design(This post is in response to Hayim Makabee’s posts on emergent design and adaptable design along with some of the follow-up discussions, such as the thread in the “97 Things Every Software Architect Should Know” Linkedin Group and Gene Hughson’s post on emergence vs evolution.)

One argument software architects regularly encounter is that time spent designing systems is wasted. Many say that “big design up front” is not the agile way and “emergent design” is more effective. This cuts straight to the value proposition of an architect. If up front design has no place in the Agile world, are architects redundant?

To most people, “big design up front” (BDUF), sometimes called “big up front design” (BUFD), means a lengthy, detailed design created at the start of a project. It works on three assumptions. First, one can create requirements for a project. Second, one can create a design to meet those requirements. Third, the design’s suitability for meeting the requirements can be evaluated without implementing it. In other words, there can be good designs and bad designs.

Meanwhile, emergent design means minimal or no design up front (NDUF). It works on the assumption both the requirements and design must be deduced so the team starts developing the product and iterates as they learn more about the problem and the solution. The process finishes at a predetermined time or when “good enough” requirements and design “emerge”.

By inference, emergent design assumes designs are often highly problem/solution specific. Adapting existing designs may create more work than they save. It also moves the focus from providing value to following the design.

Emergent design is quite popular among Agile and Lean practitioners. They argue emergent design reduces some waste (unnecessary work) by not creating lengthy documents that people may never read. Of the read design documents, few are updated as changes are made. Many developers are so cynical they refuse to read documentation and jump straight to the code to answer questions.

Big design up front may encourage over design. Unnecessary features may be added (violating the YAGNI principle) or the system may be unnecessarily complex (violating the KISS principal). Emergent design, particularly when coupled with Test Driven Design (TDD), can produce the minimum code required to meet a requirement and no more.

Big design up front may create an illusion the team knows more than they do. This may prompt decisions when the team knows the least about the problem, meaning big design up front can become big commitment up front. Meanwhile, a team that delays making decisions until necessary may discover different features are needed.

Big design up front’s assumptions are also not always true. Every project has a goal but it may not be clear how to get there. Most startups do not have quantifiable requirements, for example, where coding is more experimenting than implementing. New technologies may supersede old techniques or require new ones, meaning designs are either too difficult to create or cannot be evaluated without implementation.

However, proponents of big design up front point out that designing is often more useful than design documents. The design exercise validates and challenges requirements, explores edge cases and discovers mistakes. Without it, developers often dive straight into low level details and even a short time thinking about the problem can expose assumptions or alternate solutions they would otherwise miss.

Emergent design assumes change is cheap. A lot of effort and attention has been directed to this. Continuous integration and continuous delivery aim to make releasing easy. Test Driven Design (TDD) and automated testing aim to find regressions quickly. Agile methodologies like Scrum provide visibility and guidance on how to manage change.

However, not every change is cheap. Hardware can be difficult or impossible to change once manufactured. Network infrastructure changes need to be scheduled to minimize impact to others. Engaging external vendors may require lengthy contract negotiations. Legacy code may lack sufficient automated unit test coverage. Aspects like security, compliance and scalability are difficult to retrofit.

Similarly, software development must be accountable to the organization. Required skills and teams must be hired or contracted. Budgets must be determined. Progress is usually tracked against milestones and must be approved based on return on investment (ROI) estimations. Risks must be identified and mitigated. Early designs (as part of architectures) can help drive all of this.

Designs present abstracted views of the system, emphasizing important decisions and removing noise. This means designs can also be reviewed by others before the more expensive and time consuming implementation to find weaknesses or suggest improvements. Designs of notable projects can teach others, either by following or avoiding them.

The problem with comparing big design up front against emergent design is it usually devolves into straw man arguments. Neither are absolutes. Good big design up front recognizes some design and details are filled in during development. Good emergent design must start with some idea of how the system will work.

Both big design up front and emergent design can be done badly. Poor big design up front can miss important factors, provide a poor solution or communicate good ideas badly. Poor emergent design can waste time rewriting code, introduce regressions and impede governance. Both can create a big ball of mud. However, big design up front need not be change averse. Emergent design need not be chaotic and unpredictable.

Big design up front and emergent design are process agnostic. Big design up front originated in waterfall processes. As mentioned above, emergent design is common with agile development methodologies. However, emergent design can be used within a waterfall design phase (prototyping) or for defined components during development (spikes). A team using agile development methodologies may do some design inside, outside or between iterations.

Both approaches can be combined. For example, adaptable design is a technique where parts of the system that anticipate change, such as unknown or changing requirements, are designed to accommodate them.

Looking at the comparison from a different angle, what does “design” mean? Is it thinking about how to approach the system or is it documenting and communicating it? A small system may be something a developer can completely understand and describe in a few sentences. It has an implicit, undocumented design and can be iterated over time using emergent design. However, a large or complex system using a mix of legacy and new components whose development is split across different teams may need a different approach. In other words, the benefit of up front design increases as the system complexity increases.

Different approaches require different skills. Big design up front requires thinking about a system in abstract terms. It is skill that not every developer has, requiring breadth rather than depth, and is often why democratizing design fails. By contrast, emergent design embraces a detail and code focus, particularly with the focus on unit testing and small, incremental changes. This is one reason emergent design is more attractive to software developers.

Both big design up front and emergent design are tools a software development team can use. Rather than being excluded, software architects are in a unique position. They can help determine which approach is best for a situation. The real challenge for a software architect is knowing the right amount of design for a system and when to do it.

Software Architecture , , , , , , , , , , , , , , , ,

Should Software Architects Write Code?

12 Comments Posted by on November 20, 2012

Much has been written and debated on whether software architects should write code. Many argue the more architects understand the language, tools and environment they are designing for, the more effective they are and this is best achieved by implementing some or all of the design. Non-coding architects, sometimes called “PowerPoint architects”, “astronaut architects” or “ivory tower architects”, may use archibabble and talkitecture to convince non-technical stakeholders of their expertise while delegating the unsolved, real problems to developers, so much so that it has become an organizational pattern (“Architect Also Implements“) and corresponding anti-pattern (“Architects Don’t Code“). Others argue that architects responsible for implementing their architectures lose focus on the bigger issues and longer term vision. Understanding does not necessarily require knowledge of the minutiae and, as systems scale up and diversify, implementing it requires too much time or spreads the architect too thin. Therefore, should software architects write code?

As with many difficult questions, the problem starts with the question itself. “Should a software architect write code?” can mean “Should a software architect always prototype or implement their own architectures?”, “Should a software architect write production code most of the time?” or “Should a software architect be able to write code?”. It could also mean “Is coding the best or only way to become a software architect?” or “Can non-coders be good architects?” but that is best left to another blog post.

It also depends on the definition of “software architect”. The Canadian architect (of buildings rather than IT) Witold Rybczynski wrote in his 1989 book “The Most Beautiful House in the World“:

“For centuries, the difference between master masons, journeymen builders, joiners, dilettantes, gifted amateurs, and architects has been ill defined. The great Renaissance buildings, for example, were designed by a variety of non-architects. Brunelleschi was trained as a goldsmith; Michelango as a sculptor, Leonardo da Vinci as a painter, and Alberti as a lawyer; only Bramante, who was also a painter, had formally studied building. These men are termed architects because, among other things, they created architecture — a tautology that explains nothing.”

This is exactly the same issue for software architects. Without a clearly defined and segregated role, anyone designing software or IT related systems can rightly be called an architect, including many developers and technical leads. For the sake of argument, this post uses Simon Brown’s definition, where software architects are responsible for high level design, non-functional requirements and technical vision.

Should a software architect be able to write code? Architects should be able to read and write code because it:

  1. Verifies the code written by developers matches the design and identifies deviations.
  2. Helps the architect learn about changes or new features. If the architect has been assigned to a new project, he or she can learn the product sooner by looking at the code, too.
  3. Allows the architect to write a proof of concepts or prototype. A working demo is much more convincing than an architecture diagram and will usually facilitate better estimates. Care must be taken to prevent non-technical stakeholders attaching too much credibility to it, as with any prototype however.
  4. Provides another pair of capable hands during the project crunch periods.
  5. Makes the architect more forgiving of bugs because the architect has likely made similar mistakes in the past. At least, the architect should have a better understanding what types of issues to expect.

Writing code may help earn the architect respect of the developers. Developers can be notoriously dismissive and a software architect producing some of his or her own code, even if it is just a proof of concept, or providing good feedback from a code review can make the developers feel like the architect is one of them. Having a working development environment and access to source code means the architect can try out new versions without waiting for a build or release. Any significant build, development environment or source code control issues also become apparent to the architect.

Note that code reviews do not replace talking to developers because regular discussions between developers and software architects can help build mutual respect. Otherwise, developers may see the architect as a constraint or threat that must be circumvented. Also, developers often know or can find problem areas faster than the architect reading the code but there needs to be a balance between architect self-sufficiency and squandering developer time.

Software architects are often required to settle disputes between developers, such as when one team discovers a better way of solving a problem or that the proposed design will be harder to implement than first thought. Software architects are also sometimes mentors or coaches for developers or may be used as internal consultants to examine process, quality, automation or similar issues. Understanding code means the architect can use his or her judgment more effectively rather than rely on which developer is more persuasive.

Should a software architect write production code most of the time (usually implementing their own architecture)? If a software architect implements their own architectures, this ensures the design is implementable with the tools and environment used. This can lead to new insights, improved designs and more accurate estimations. It is also implemented by the person most familiar with the design so minimizes miscommunication.

However, architects may jump to implementation (depth thinking) before exhausting other solutions (breadth thinking). Existing implementations may overly influence the architect or the architect become attached to his or her code, fighting against needed improvements. It can distract the architect from higher level tasks such as longer term planning, communicating with stakeholders and reviewing other developers’ code.

Also, part of the role of an architect is to fight for reuse, security and other non-functional requirements. Being forced to prototype or implement their design may encourage compromises that the team need not make. It is not that an architect does not make compromises – design is the art of compromise as many have said – more that it is the architect’s job to make the right compromises rather than those the architect makes creating the initial implementation. The developers will likely rewrite much of the architect’s code, anyway.

Indeed, the more an architect focuses on communication, requirements analysis, stakeholder management and non-technical activities, the more the development skills of software architects may atrophy. As long as the architect is providing value via other means this is not an issue. However, an architect should maintain his or her development skills; whether by extensive research, working on their own projects or contributing where they can; but needs to focus on capabilities, limitations and edge cases rather than speed or a complete understanding.

Problems may occur when organizations promote their strongest developers into a software architect role rather than good communicators that are capable of working at higher levels of abstraction. Friction arises when these architects try to “lead from the front” by implementing their architecture rather than facilitating others to do so. Organizations should promote a developer that has better soft skills, instead.

Many confuse not writing code with a lack of feedback. An unprototyped architecture, hypothetically, may be difficult to implement or problematic. However, a senior developer or technical lead can prototype the architecture if required. This also allows architects and developers to work together and ensure the design is communicated well. Alternatively, the architecture can be shared with others that have implemented similar systems previously or architects or developers working on integrating products. Requiring an architect to implement their own architecture beyond a proof of concept also does not scale well, particularly for large or complex products.

Similarly, many confuse an architect not writing code with a lack of accountability. Architects must produce designs that not only are approved (whether formally or informally) by stakeholders but also developers and developers should not approve a document that does not meet their needs. Issues or errors in the designs should be noted. Some change is expected but major or expensive errors should be attributed to the architect. An architect implementing their architecture in code does not guarantee an issue-free project.

With increased use of agile development methodologies, architects are no longer creating an architecture and “throwing it over the wall” to developers. Even previously ivory tower architects are more involved with lower level issues since less critical decisions are deferred until later in the process and design is iterative. For example, architects in organizations using Scrum should attend at least the planning, review and retrospective meetings. (Some architects may move to other projects or otherwise not see the project through, the “Architects Play Golf” pattern. This is an organizational issue and unrelated to whether architects code.)

Many developers also look down on “PowerPoint architectures”. However, many forget the role of a software architect is as much communication as development and completed, implemented architecture does not help non-technical stakeholders, QA, localization, documentation writers and so on. Of course, these stratospheric PowerPoint architectures are not substitutes for high-level designs developers can implement but the architect represents the developers and products to outsiders and developers often feel any time not spent developing is unproductive. Ultimately, PowerPoint architectures do have their place but developers are as much the architects’ customers as the stakeholders.

Should architects write code? The question is loaded and should be determined by the team on a case by case basis. Architects may prototype high risk projects, experiment with new libraries or try out now tools. Architects may completely delegate the design and implementation of well understood, low risk components. The real question is “How does an architect be successful?”. It is a question of managing and mitigating risk. Architects are often good coders but good coders are not necessarily good architects.

Update: There is a large discussion about this post on the IASA (International Association of Software Architects) LinkedIn group: http://www.linkedin.com/groups/Should-Software-Architects-Code-1523.S.188454845

Software Architecture , , , , , , , , ,

An Architect’s Place in Agile

3 Comments Posted by on August 19, 2012

Scrum, the most common implementation of the Agile development methodology, has many well-defined roles. Those that contribute directly to the sprint (a unit of work usually lasting 2-4 weeks) are called “pigs”. Those that consult or assist only are “chickens”, the “scrum master” coordinates the sprint and the “product owner” prioritizes work and ensures the customer needs are met.

So where does the software architect fit in? The architect is not a pig if he or she does not write production code. Is he or she a chicken? The architect needs to be driving his or her features in the sprint and be more involved than a chicken. The architect is not responsible for team organization and a customer representative is usually the product owner.

Going back to basics, why is a software architect needed? Architects are rarely needed in projects with small, co-located teams full of senior developers working on well-defined requirements or well-understood problems. They can usually design and cooperate well enough to produce the desired results. However, large, distributed teams full of junior developers working on vague requirements or complex problems need coordination and direction. This is where architects are most useful.

One way of looking at it is Scrum is a software development methodology, not a productization methodology. Software development is one part of producing a product but there are many other parts, particularly for commercially sold software, such as business case design, marketing, licensing, documentation and localization. The architect could deliver non-functional requirements and high-level designs outside sprints like the other non-development tasks.

However, the architect need not deliver a monolithic document for the high-level design. In keeping with the Agile manifesto, as well as the Lean principle of making decisions as late as possible, the architect only needs to produce enough of the design to unblock the next sprint. The architect will still need a high-level design and identify non-functional requirements initially but Agile recognizes that design is as much a process as a product. Designs for subsequent sprints can be fleshed out in parallel with the development team, minimizing design rework as the team learns more about the problem and finds better solutions.

Could a software architect use Scrum to create the high-level design, either separate to or in parallel with the development teams? This can work if the architect has easy access to the resources he or she needs, such as customers to help understand the business problems, architects from other teams to discuss integration and development managers to check resource estimates. This cannot be guaranteed, particularly with larger, distributed groups – the cases where architects are most useful. However, it will occur in practice if the architect is providing designs for the start of each sprint.

Indeed, if the product owner is remote or often unavailable, an architect fits best into Scrum as a stand-in product owner. This breaks the Scrum rules of only having one product owner. However, different time zones, large projects and multiple commitments mean a single person cannot scale, as a former colleague of mine explained.

Development management may baulk at the perceived loss of control by making an architect a product owner. However, the word “owner” in “product owner” does not mean control of the product, merely creating, prioritizing and clarifying tasks, which architects often do anyway. Architects may not be customers but are judged whether the product meets the requirements or creates business value, just like product owners. They also know the product strategy and have spent time with the customer understanding the problem so are well-suited for this role, using their judgment to determine whether to escalate each question to the product owner.

Moreover, I think the question is not “Where does the architect fit into Agile?”, it’s “How can architects leverage Agile to better perform their role?”. For example, the architect can gain more visibility into the development team’s progress and status (through the backlog and burn down charts). The architect can present the design and gain consensus at the planning meeting that starts a sprint and (hopefully) see it working in the hand-over meeting at the end of a sprint.

Most importantly, architects must be in control of their performance rather than victims of process. A lot of smart people have worked very hard on Agile and Scrum and developers new to Scrum are advised to follow it as written, at least initially, because the reasons behind its nuances are often unclear. However, no development methodology can handle every case, and software architects are one of those things that can fall into the gaps.

Software Architecture , , , , , , , , , , , ,