So what should an “agile” software architect be doing?

“As architects, you have the opportunity to create spaces that inspire, uplift, and bring people together.”

“An agile architect in his natural habitat dancing in a field of complexity…”

I recently wrote a blog on whether software architects matter. The blog was written quickly and without much consideration, which sparked discussions among my professional network, particularly among architects. Many of these discussions focused on the role of an “agile” software architect. My suggestion that most design decisions be made by the team appeared to be the trigger point for these discussions. In light of this, I have compiled a list of things that I believe “agile” software architects should be doing:

Be part of the development team – You are there to inform, motivate, and influence the team without expending social capital by forcing your decisions. Being removed from the actual development effort and simply flinging architectural documents (that probably don’t reflect actual system code) at developers is not good enough anymore.

Adapt to the team’s way of working – Not the other way around. In order to build high-performance teams, you need to create space for autonomy, mastery, and purpose. The autonomy boundary can be constrained, but each team’s sweet spot in terms of their way of working will differ slightly. Standardizing your approach will simply lack the flexibility and variability that modern teams need and require.

Your job is to accelerate the project, not to slow it down – Your goal is to keep the project moving forward and avoid slowing it down. Be flexible and willing to change priorities, discard unnecessary requirements, and experiment with new ideas. Above all, keep the flow of value creation going. Don’t get stuck trying to understand or gain consensus on every detail. Instead, defer decision-making as long as possible and focus on the high-risk areas that could derail your design. This will help you avoid becoming a bottleneck in the development process

Your job is primarily about communication; do it often and early – Keep the lines of communication open and start early. It can be difficult to achieve a shared understanding among all project stakeholders, but transparency and simplicity can help. Avoid complicated diagrams and strive to provide context and understanding. Repeat key points until a common understanding is reached and people start taking initiative. Then, simply curate and ensure accuracy without stifling people’s attempts to contextualize the information.

Focus on the essence of the problem, the simpler the better – Stop creating artefacts, documents, and stuff that nobody can contextualize. Even if you have to explain things over and over again, this will refine the concept in your head and provide extra insights. Look at initiatives like C4 diagrams to get your drawings more in line with the actual thing being built.

Test your architecture – Prototypes and POCs are single-handedly the best way to validate parts of your architecture. But in too many organizations, this is seen as a waste of time and money. Change the way you fund projects and cater for this activity. While you are at it, always add slack for testing the non-functionals of your architecture (scalability, performance, and robustness).

Question standard practices and seek out new ideas – Don’t be afraid to challenge the status quo and seek out new ideas and approaches. The world of software development is constantly evolving, and it is important for architects to stay current and adapt to new methodologies and technologies. This will help you to stay relevant and effective in your role.

In conclusion, the role of the agile architect is to be an active and influential member of the development team, adapt to the team’s way of working, accelerate the project, communicate effectively, focus on the essence of the problem, test the architecture, and seek out new ideas. By following these principles, you can help your team to build better software and achieve greater success.

Advertisement

Developing a Culture of Meaning for Software Teams

“This means having a clear and compelling vision that speaks to the hearts and minds of potential team members. This vision needs to be real and have integrity.”

“To truly land the best talent in the industry, you need to have a cause or idea that people can rally behind.”

Building a successful software development team is a challenging task. Not only do you need to find individuals who are skilled in their craft, but they also need to have a certain mindset and approach to their work. They need to be idealistic and creative, but also able to think critically and pragmatically. They need to see their careers as a calling, not just a job.

Finding these kinds of people is difficult, and they are often in high demand. They regularly receive offers from recruiters and have a wide range of opportunities to choose from. As a result, to attract the best talent, you need to offer something that they can truly believe in.

This means having a clear and compelling vision that speaks to the hearts and minds of potential team members. This vision needs to be real and have integrity, and should be backed by a leader who is not just a salesperson, but someone who genuinely cares about the people who choose to follow that vision.

Many organizations try to attract talent by talking a big game and manufacturing unauthentic ideals, values, and visions. They try to show how “cool” they are by engaging in imitation innovation. But this kind of behavior can only fool people for so long if it is not truly part of the organization’s DNA.

To truly land the best talent in the industry, you need to have a cause or idea that people can rally behind. And you need to create a culture that aligns with the way that technology professionals want to be treated. This means moving away from traditional command-and-control structures and towards a flatter, networked organization that is in line with the modern knowledge economy.

Software has and continues to drive the modern industrial revolution, and as a result, it is at the forefront of shaping modern organizational culture. Instead of trying to fit technology professionals into existing corporate structures, organizations should strive to create cultures that align with the values and goals of the people who work in technology.

To do this, organizations need to prioritize autonomy, mastery, and purpose in their culture. They need to trust and empower their team members to use their skills and experience to build great things. They need to provide opportunities for growth and development, and create an environment where people can learn from each other and push the boundaries of what is possible.

Of course, creating this kind of culture is not easy. It requires a commitment to change and a willingness to challenge the status quo. It requires leaders who are willing to listen and learn from their team members, and who are willing to adapt and evolve in response to feedback.

But the payoff is worth it. A culture that aligns with the values and goals of technology professionals will attract the best talent in the industry. It will foster innovation and collaboration, and it will enable your team to build great things together. And in the end, that is what truly makes a software development team successful.

Do software architects matter?

“In order to be effective, the role of the software architect should be closely tied to the act of coding.”

One of the most problematic versions of this role is when someone without a technical background starts making pronouncements about architecture and is labelled as an architect…

The role of the software architect in software development is an important one, but it is often misunderstood and can be problematic if not approached correctly. The term “software architect” often conjures up images of a senior engineer who has mastered their craft and no longer needs to engage in the mundane task of coding. They sit in their ivory tower, making grand pronouncements about how software should be built and then bemoaning the inability of others to execute their vision.

However, this approach is misguided and can lead to a number of problems. For one, it creates a disconnect between the design and the implementation, which can result in unrealistic expectations and poor decision-making. Additionally, it can foster a lack of ownership and responsibility among the development team, leading to subpar results.

In order to be effective, the role of the software architect should be closely tied to the act of coding. This means that there should be no distinction between architecture and coding – it should be a shared concern of the autonomous team building a system collaboratively. This approach allows for a more well-rounded understanding of the design, as well as fostering a sense of ownership and responsibility among the entire team.

Of course, it’s helpful to be able to articulate architecture and the impacts of technical decisions in a way that non-technical people can understand. But this is a skill that every technologist should strive to perfect, not just those who carry the title of “architect.” Clear communication is essential for ensuring that all stakeholders have a shared understanding of the design and its implications.

One of the most problematic versions of this role is when someone without a technical background starts making pronouncements about architecture and is labelled as an architect. They are likely to be completely unaware of the subtleties of technology frameworks and the practicalities of building coherent software systems. This can lead to unrealistic expectations and poor decision-making. Yet, these individuals are common in corporate environments.

So, what is architecture, if anything at all? Martin Fowler’s view is that if there is such a thing as architecture, it is about creating a shared understanding within your team and investigating and answering the things in your project that will be hard to change in the future. The rest can be left to your capable and trusted development team. By focusing on collaboration and clear communication, the role of the software architect can be valuable in ensuring the success of a software project, provided is rooted in authentic knowledge.

Estimates, commitments, and targets in software projects

“Many people don’t even know that there is a difference that has led to countless project failures.”

Most people have never learned what good software estimation looks like or how to communicate it effectively.

The importance of understanding the difference between estimates, commitments, and targets in software projects

In my previous article, I discussed the inherent complexity of doing software estimation and the phenomenon of discovered complexity. Beyond this complexity lies another problem: poor communication. Most people have never learned what good software estimation looks like or how to communicate it effectively. Business people involved in software projects often view estimation as the domain of the technical team and make no effort to understand its nuances. Technical team members, on the other hand, often rely on gut-feel estimates without understanding the importance of clear communication.

As a result, estimates are often treated as commitments, and commitments are communicated as targets. Many people don’t even know that there is a difference between these concepts. This lack of understanding has led to countless project failures and eroded trust in the software development process.

To clarify the differences between these concepts:

• An estimate is a best guess at how long something will take, based on the information available at the time. As I explained in my previous article, estimates are inherently flawed and will change as more information becomes available and problems are solved. A good estimate should be plotted against a probability curve to quantify the uncertainty and risk surrounding it. Rather than communicating a single point estimate (e.g. “I think this will take 6 months”), it’s better to communicate a range (e.g. “given what we know, this could take anywhere from 6-9 months”). Thinking of estimates as a range of possibilities reduces the stress of having to be perfectly right and accommodates the inherent ambiguity and uncertainty of the software development process.
• A commitment is a promise to deliver functionality at a certain level of quality by a certain date. It’s critical to realize that estimates inform commitments, but commitments should never drive estimates. The working position should be that the estimate is flawed and commitments should be based on the most pessimistic estimate, allowing for additional buffer time. If the estimate is not acceptable, business stakeholders should prioritize the project and make the hard choices necessary to give it a quantified chance of success.
• A target is a single-point hard deadline, usually driven by external factors such as a product launch or a regulatory requirement. Targets are not based on estimates or commitments and are often imposed on a project team without their input. Meeting a target can require significant compromise on scope, quality, and/or timeline.

In summary, it’s essential to understand the purpose and value of software estimation and to communicate estimates, commitments, and targets clearly and accurately. By doing so, we can avoid the frustration and trust erosion that often results from project failures.