Guide your scaling engineering team with an architecture North Star | Hanjie Ji | #LeadDevAustinOn November 16, 2019 by Raul Dinwiddie
Hi, everyone, I’m here today to talk about
how you may guide your agile team, especially a growing one, with an architectural North
Star and what is an architecture North Star? How it can help your team to be more agile.
First, a little bit about me. I’m an engineering director at WeWork. I’m one of the early engineers
at WeWork for about the past six years, I grew from an individual contributor to a manager,
and a manager of managers. And for the last three years, I’ve been focusing
on building high-performing team that addresses critical business problems at WeWork ranging
from products, to pricing to billing and payments. And WeWork offers beautiful spaces for all
types of businesses to survive, from freelancers, solopreneurs to Fortune 500 companies and
you may see some photos on the slides. Back in 2013 when I joined WeWork, we had
6 locations and 485 members and today we have over 466,000 members, and it has been tremendous
that the people loved the concept and the space as a service. With the growing customer
base and buildings around the world, the complexity of the business grew with it. From the very
early stage, the software engineers and product managers at the company had to start building
products and integrating other software products to help the product grow more efficiently
and operate our buildings more efficiently, as well. And naturally, we use agile as the
framework to manage our software development process. If I may have a quick show of hands,
how many of you work on a team that uses agile? Well, that’s probably 80 percent of you?
Just like you, we follow the agile principles from the agile manifesto. We build and deliver
product incrementally and we ship frequently. We have minimum design up front, because we
didn’t have all the requirements and we welcomed changing requirements.
The system and applications evolved very quickly to deal with the ever-changing business requirements.
We believed in evolutional design and architecture of a system which chooses code over process
and the team were self-organized and empowered to be autonomous.
And we didn’t overcomplicate things. When the requirement wasn’t there, we didn’t do
it. We didn’t code it. After all, simplicity is the art of the maximum amount of work not
done. We work fast and build things and the team was growing and the team of software
engineers and products were growing, too. We kept the team size relatively small. Each
team was no more than 6 people. One team became two. Then two became three. New teams were
built to tackle the expanding business problems, or I may say opportunities, and would hire
new talented engineers who are driven, passionate, about delivering impact to the business and
when the team is assembled, they get the requirements, they figure out their ceremonies, they understand
the problem domain, then go on to create solutions. Agile practice worked.
Then we continued to hire great engineers, continued to grow very quickly we had dozens
of agile teams and the number of pull requests merged and deployed every day was growing
rapidly. Then we started seeing some cracks, and some problems that our agile teams cannot
resolve themselves. Some seemingly simple product requirements
required a major refactoring, and most importantly, the business landscape was changing. A lot
of the early assumptions that we built our software on were no longer true. And the simple
solutions we put out early on and the amount of work that was not done early, now needed
to be addressed. Things were working until it isn’t.
So we started hearing some signals of the common — we started getting some signals
of common concerns. Service A and service B are kind of similar doing the same things,
but they’re different. Or a service was build to do X and now is repurposed to do Y, it’s
now very hard to expand its capabilities. And architecture is changing so quickly, a
holistic view is missing. These are all inconsistencies, happens and require additional energy for
the agile team to address in their day to day, and these problems constantly become
blockers to the decisionmaking of the team, and the harmed autonomy of the team and ultimately
slowed the team down. If we take a step back and look at it, what
happened? When we start analyzing the cause of it, realize when you initially had a small
number of teams, it was easy to align the team to go toward the same architectural goal
and everyone was building towards the same direction.
And when you have a large number of teams who shared different contexts, focusing on
different business goals, the architecture directions started to diverge. And each team
followed the agile methodology, they’d just do enough and just in time, to carry out the
business goal, and some of the design decisions were made very fast and sometimes in silo.
And over time, different teams embarked on different architectural directions.
And each team may be hyperperforming, but they’re achieving the local maximum with agile.
On the grand scheme of things, the entire architecture isn’t coherent and over time
we ended up with a piecemeal architecture. And to the team, it feels like bumper cars,
the agile team use their reaction, and use their experience to navigate.
How do we address it? How do we help the team to advance towards the same direction? At
this point you might be thinking we can reduce the amount of autonomy in the agile team and
add in a little bit more coordination. That’s what a lot of the organization — that’s the
approach a lot of organizations have taken to coordinate processes in the agile process.
Some organizations use scrum of scrums for large projects, but you can only do so many
of them. And some have architecture design committees
to review the proposals, and some have embedded architects on the team to coordinate decisions.
Or some may just fall back to go back to waterfall and have a big design up front. While these
are all viable approaches, I don’t think they fit well with the spirit of autonomous, which
is the foundation of the agile practice. And if we think about it, is autonomy really
the problem here? As a true believer in agile I’m not ready
to give up autonomy for the team yet. And how can we align the seemingly disoriented
team without adding more coordination, but align them to go towards the same direction?
What’s the missing ingredient? The key is alignment: Introduce architecture North Star.
It is an approach and exercise to align your team that are attacking different business
problems on the same architecture direction. It can give your team a good sense of where
the architecture is evolving as a whole and help them with the daily decisionmaking.
This is my definition of an architecture North Star. It’s a coherent, forward-looking architecture
designed upon the shared understanding of requirements and constraints to help the teams
to orientate and navigate. How is this better than the other approaches
of coordination? The key is to come up with a North Star that’s
based on shared understanding. The emphasis on the shared understanding requirements gives
your team focus. A shared understanding to help ensure the
team are moving towards the same direction and have a whole holistic scope or view of
the scope of the problem. And usually an agile team is usually tasked with solving a specific
problem, only seeing a piece of the puzzle that address a very specific problem. Over
time, the siloed knowledge and the missing the bigger picture, causing the architecture
to be inconsistent which leads to poor integration and wrong abstraction.
Therefore, it is important to build upon a shared understanding.
Having a piecemeal architecture is a real risk in the agile practice. Equipped with
a shared understanding of a requirements of the constraints, your team can come up with
a better chance — have a better chance to come up with a coherent design. It can help
your team to not unconsciously create haphazardly structured code, duct-taped code together,
and believing in the right intention in your team that want to build sustainable and well
structured architecture, they just need a guidance of where they should be going.
With this alignment, you need less coordination. The North Star should be unambiguous and with
just enough information to help the team to make decisive, fast decisions.
And the North Star should be highly visible. It should be highly visible not just to your
engineering team, but to your product team, to your business team, and once the North
Star is created, it can help everyone to speak the same language, and in the future requirements
gathering in the future development, it can also serve as a base for further requirement
discussion. And last but not least: The agile team are
still empowered to be autonomous. In this case, the premises of self-organizing team
that originally helped you build the high-performing team, is not compromised. With the guiding
star, we can trust the team to make a well educated decision in their sprint. These are
what I think are the benefits of having an architecture North Star. Should you do an
architecture North Star in day one of the project? I don’t recommend it. you don’t have
the requirements yet and you don’t know what may change.
But once your agile team has been running for a while, we realize OK, some of the hypotheses
and assumptions you have have been battle tested. Some turn out to be true, some turn
out to be wrong. At that point, it’s a good time to have a discussion that exercise of
the architecture North Star and in this case the content of this architecture North Star
is different from the big design up front, because the goal isn’t to come up with all
the answers and the details, and it doesn’t negate the flexible development in the agile
practice. And the secondly, an architecture North Star plays nicely with autonomy of your
team while knowing a full picture of where the architecture is heading, your team can
continue to take an iterative agile approach that delivers value in small chunks, and the
discovery in the agile, in their daily agile practice, can in turn feed back to the North
Star. so how do we come up with the architect North
Star? The exercise of coming to the North Star is a discovery journey. It is also a
process of creating alignment. I’d be fooling myself if I stood here telling
you how you can build an ideal architecture North Star, but I would love point out a set
of best practices. With some of the learning exercises that we went through.
Every business and product is different. Every business and product is different. It’s
hard to be prescriptive about the architecture. The framework that we used to design — to
design for the complexity was demain-driven design. It is an effective approach to describe
a complex problem, and output of our North Star is a set of principles and anti-patterns.
A context map, which I’ll explain in a second. And the context map with owner for each domain
and a context map is basically a high-level view of your key problems and domains that
can help your engineers and product understand where they can take strategic decisions.
And if you want to come up with a system diagram, you can, but I would love — I would suggest
to leave enough space to let your agile team to make decisions in their day-to-day, but
it’s important to come up with a set of principles and anti-patterns and overall view to get
everyone on the same page. So this is an example of our context map in
sales, pricing, membership and product domain. Each domain can be further broken down, but
this is just an example. So now a few tips for you to create your architecture
North Star. Number one: Involve your stakeholders or your
customer. The most significant complexity of many applications is not technical. The
complexity is in the problem domain itself. If you think a number of engineers going to
a room and come up with a big reveal of the architecture North Star, you may be disappointed.
Engineers are a key part of this exercise, because they know the limitation and they’re
the builder of the system. But as engineers, we don’t have intimate knowledge
of the future requirements, and these requirements are fundamental to drive the decision in the
North Star. And very likely these are decisions that live
in the mind or documents of — from your stakeholders and product managers. Therefore, the exercise
has to be a joint effort with your product managers and stakeholders.
Interview them to hear about what they have to say. It’s even better if you can have a
live discussion with them with relevant — with everyone in the same room. Having a facilitator
with strong system design skills and the ability to architect complex systems definitely helps.
And this is where the role of the lead developer or architect shines and they can help facilitate
and drive decisions. No. 2: Some requirements are more important
than the others. Prioritize your requirements. Identify the requirements that are significant
to your architecture, and may fundamentally disrupt your architecture if you don’t pay
attention to them. And focusing on deciphering those requirements
and make sure the architecture-significant requirements, they are true that will actually
be impacting your architecture. And remember, the North Star shouldn’t be
designed for a far-reaching future. Be practical. Design depends on the stage of your company,
design it for six months out, and at most, one year out.
And focus on the core domains, and by core domains, I mean the core problem space of
your business. How do identify what is a core domain, ask yourself a few questions. Is it
something that you want to build versus buy? If it’s something you can buy off the shelf
and that’s something that can fulfill your needs, why not buy it? Is it worth your time
building it? Is it so fundamental to your business that can give you a competitive advantage?
and the core domains are usually the domains, the problem space with the most cross-cutting
concerns, allot of teams depend on it and a lot of the teams are tasked with that problems.
Limit the number of core domains to a small number.
And when you come up with each problem space, pay attention to the boundaries between these
domains, and define the boundary carefully, because once within a boundary, within a problem
space, your agile team can have the room to be autonomous and to solve problems, and if
you want to change the boundary, that’s when you want to be more careful. You want to carefully
design the interaction when you go across the boundary.
And make it light and iterate. Don’t forget the exercise of coming up with an architecture
North Star is to help your team make better decisions and fast, decisive decisions. If
the architecture North Star is big, it’s harder to update. Also, it’s harder for your team
to use it to incorporate it into their software development process. Your North Star shouldn’t
change very often if you build it on the architecture-significant requirements, unless the business fundamentals
changes. And the focus of this North Star should also be focusing on providing just
enough architecture, rather than a big design up front.
Equipped with the architecture North Star, your team can make better decisions and faster
decisions in their day to day. The autonomous teams can be more autonomous, because they
are assured that everyone have the same view of where the architecture is evolving. And
your teams don’t need to be in constant coordination. And hopefully, this will lead to less wasted
work and effort and reduce the frustration when there’s a big misalignment and your team
has to deal with that. And you as the lead developer can continue to scale the use of
agile methodology in your organization, and your team can continue to scale up while maintaining
the high performance they have always had. Try it, let me know how it goes, and you can
find me in the Office Hours if you have any questions. Thank you.