“Our chosen technology can’t do that!” Is not what you want to hear in an established project. You especially don’t want to hear this if it prevents you from installing a nifty tool to make life easier. Unfortunately, siloed decision making for different project architectures can cause this. A decision-maker did not consider other team needs when making critical decisions.
When faced with complex problems, it is a natural reaction to try to simplify them. You might focus on a tricky hardware decision, assigning other choices to other teams. Or you might focus on the most complex problem first, leaving other challenges to later. But you might rule out options that would benefit other teams.
Are you a strategic leader or developer? Regardless, you should focus on the Lean-Agile principle of optimising the whole. You can work smarter, see more innovation, and improve your product by doing this.
The Four Quadrants is a strategic approach to getting a handle on these core architectural decisions. An idea that we first heard from our friend Tobias Kästner of Method Park.
This blog will discuss a holistic way of approaching these four different architectural decisions. You can vastly improve project outcomes when your decision-makers consider the bigger picture.
What is The Four Quadrants concept, and why does it matter?
The Four Quadrants show architectural choices in a software project and how they overlap.
These architectures are the system architecture, toolchain architecture, collaboration architecture, and documentation architecture.
The system architecture is the structure and behaviour of the system. It includes the operating system, hardware choices, processor, and UI Framework. The decision might consider:
- Processor speed
- Value for money
- Hardware availability
- Tool support.
Toolchain architecture covers tools and test automation frameworks. These include:
- Test-Driven Development (TDD)
- Test frameworks for Behaviour-Driven Development (BDD)
- Requirement management
- Configuration management
- Continuous integration.
Documentation architecture includes how to store and update documentation. Will you use living documentation, executable specifications, and do you need regulatory documentation? Most teams struggle to keep documentation up-to-date, accessible, and relevant to all involved. And it can be very time-consuming. Knowing how to make valuable documentation is often a big puzzle for many companies.
Collaboration architecture describes how the people involved will work together. A collaborative approach is vital to creating a product that meets everyone’s needs. Collaboration can be your Lean-Agile ceremonies, such as three amigos, stand-ups, reviews, demos, and retrospectives. It can be other regular meetings and workshops or training. How will you communicate with other teams? You might choose messaging platforms, emails, or living documentation.
It also confirms goals and priorities, approval processes and responsibilities. Finally, it sets down how (and how often) to involve the customer or user and react to their feedback. Simply, it’s about how you share knowledge across the whole project.
Different people or teams can handle each architectural decision. But you see more success if you collaborate. Choices that help other groups will improve quality and help meet your strategic goals better. You can also gain shorter release cycles and improved consistency.
So which problems can arise?
There can be many inadvertent impacts from siloed decision making. Problems you can face include:
- The system architecture decision might restrict better toolchain solutions. Without effective tooling, you risk slower release cycles and reduced product throughput.
- Manual tasks will increase workload and reduce velocity if other decisions block you from automating them.
- Without good collaboration, you miss opportunities to share and innovate. Talented people do not get together to brainstorm or solve a problem.
- Poor communication makes it harder to make improvements based on user feedback. The requirements and documentation can quickly become out of date.
- Siloed documentation or QA teams can lead to low quality and low-value documentation. It misses the cross-team benefits to make it beneficial to everyone. It can become a chore to create and maintain.
- Outdated documentation because the team isn’t kept up to date about changing user feedback. Or the team has inflexible requirement management tools.
Example 1: Using BDD to improve the whole
A useful example of the Four Quadrants working together is Behaviour-Driven Development (BDD).
BDD involves good collaboration from the start. We find three amigos meetings to be particularly valuable for collaboration. They bring together three or more people who stand for distinct aspects of the business to discuss the upcoming work. These include product stakeholders, developers, and testers. Each “amigo” has a different mindset, and regularly getting those people together helps break down barriers. Together, they create human-readable tests to illustrate these system behaviours.
Regularly getting people together who have different mindsets helps break down barriers and share knowledge.
Automating these tests will save time and help shorten release cycles. These tests can become requirements known as executable specifications. In this case, the test titles become the requirement wording. Running the test proves that the requirement passes, and the log file is evidence of this.
The toolchain architecture decision-makers use this goal when choosing required tools.
The system architecture decision-makers consider automation toolchain support when choosing the platform. Sometimes the choice is arbitrarily between two similar platforms, without any compromises.
They can choose the one which enables a UI testing framework (UITF). A UITF makes testing more cost-effective and unlocks gains for the whole product. (Besides, most engineers know that all platforms have pros and cons.) We chose Qt for a bare-metal device in an earlier project because it enabled Squish BDD. Despite not being the best technical performance, it worked best in the big picture.
Living documentation brings it all together. Tools automatically generate the documentation. They collate automated test results and technical documents into a usable format. This can be an internal website or even a PDF.
We store documentation in source control alongside the software implementation. Storing it like this ensures it will always match the software version. With documentation and code aligned, teams have freedom to experiment and innovate. Living documentation improves collaboration and project visibility for those who need it.
“People are really excited about the idea and oversight. They really, really want it. It’s like a bit of a holy grail in terms of integrating the documentation quadrant.”
Paul Massey, Founder, Bluefruit Software
Considering the collaboration and tooling together leads to better results when using BDD.
Example 2: Using Agile and UCD to gain high flexibility to adapt to user feedback
We also see improvements using an Agile collaboration architecture to incorporate User-Centred Design (UCD).
When sprints end with a usable version of software, it enables fast feedback from users (collaboration architecture). Using feedback, you can update requirements for the next sprint (documentation architecture). Fast adaptability needs good requirement management to track these changes (toolchain architecture). And it needs a technical architecture with the give to respond to this feedback (system architecture).
It forms part of an effective evolutionary lifecycle, where rapid decisions ensure the product meets the users’ needs.
How do we do this?
What can you do if your business is on an Agile transformation journey or you’re preparing for the future? Don’t worry—you are likely not starting from nothing. You’re possibly doing some of these things already:
These are intrinsic to Agile practices.
The goal is to collaborate more so that every decision-maker sees the bigger picture and what other stakeholders need. Find ways to reduce bottlenecks, such as manual testing and requirement management. Work to have effective collaboration.
There are also communication and technical actions you can take to improve how you already work:
These things are easier if you can start doing them from the beginning of a project. Get those conversations happening early. Then work out a plan for how you can collaborate well going forward. Starting full documentation and unit testing or automation for an established project can be tricky.
Even if you’re not adopting Agile and automation tomorrow, building foundations can help you make the transition when you’re ready.
Shared responsibility for decisions
Encourage cross-team ownership of decisions. Getting teams to talk and agree will reduce the risk of siloed decision-making.
Schedule relevant meetings regularly. Invite affected parties and those who have different perspectives. If you plan to use Agile, these meetings could be:
More meetings can also help. Meetings for cross-team updates, skill-sharing, or solving problems. Plus, UX workshops to get quick feedback. Choose tools that can make it easy to have discussions.
It can be tempting to drop collaborations like three amigos when people are busy and diaries are full. However, meetings can improve joined-up thinking between teams. This means you can find more opportunities and make more informed decisions. When clients have found it hard to find time for meetings, we have often had tasks blocked while waiting for answers and information. Making time for cross-team meetings can also improve productivity and quality.
Joined-up thinking: Thinking about a complicated problem in an intelligent way that includes all the important facts.
Source: Cambridge Dictionary
If you are not already invited, ask to come along. You’ll get to learn about strategic goals and be a part of relevant architecture choices. Plus, you’ll have the chance to understand cross-team tool and documentation needs. This knowledge can help all team members improve their choices.
Empowered and informed decision making
Following an Agile approach empowers team members to make decisions about how they work. For example, testers can choose their testing methods. Yet those making the decisions must know the context they’re making them in and how it helps achieve cross-team goals. Empathy always helps! For the users, and the other people creating it.
Schedule meetings or workshops for knowledge sharing, solving a problem or skill-sharing. We recently had a successful ideas meeting where two senior developers from different teams met. Their aim was to find ways to help a client understand different, valuable, novel directions they could move their project. One is an expert in embedded, and the other in AI. They do not typically work together. Yet they produced innovative ideas, showing how great cross-team collaboration can be for innovation.
If you do not already, invest in automation for testing and documentation. This can be automating BDD and unit testing, or code quality tools. These things can save time and manual effort. You free up testers to do more valuable testing activities such as exploratory or usability testing. Tedious manual tasks can stop becoming a chore when automated. Testing becomes more cost-effective and higher quality, enabling faster release cycles.
Shorter release cycles are another big win. These wins might be a value-add, cost-save, or both.
If you automate BDD tests, the tests can form your requirements and cover automatic software verification. TDD tests give indicators of product quality when automated, and doing TDD improves the quality further. Automated requirement documents give project status visibility to other stakeholders.
Some clients don’t want to budge on technical architecture decisions, or make compromises to do TDD. However, this decision reduces the success of the project. The trick is to find the right balance.
When you start seeing the value within a business, it is extra motivation to continue to do it.
Feasibility and experimentation can enhance solutions to complex problems. If the problem is complicated, you probably won’t get it right the first time.
Think of Agile’s “Fail fast” concept and experiment sooner. Experimenting reduces risk early, gains fast feedback, and finds issues faster. Prototyping different options allow you to compare them and improve overall efficiency.
If you only begin with one possibility, you could invest a lot of time and effort before realising it is not workable. It will be harder to stop and try a different solution by that point.
Tools can help you with this freedom to experiment. Tools like Git (source control), test automation, and living documentation helps you switch between variants. You can then choose to continue the one that works best or that users prefer.
See the big picture
Seeing the big picture, decisions made in all four quadrants, will boost the whole and improve the overall outcome. Several little wins in all areas soon add up to make a significant difference to a project.
There might be some compromises, but the value of optimising the whole is enormous.
The project benefits from shorter release cycles and improved product quality as time testing and documentation updates save time. There is a better understanding of the goals and needs of people in separate roles. Everyone wins.
Are you looking to develop a new product or have an existing one?
For over 20 years, Bluefruit Software’s embedded software engineers and testers have worked with many different clients. Our work has included software development for clients producing products across manufacturing, scientific instruments, medical and more. No matter your project stage, we can help.
Did you know that we have a monthly newsletter?
If you’d like insights into software development, Lean-Agile practices, advances in technology and more to your inbox once a month—sign up today!Find out more