The other day I was asked, "what do you love the most about Avature?" (Never happened.) Tough one, isn't it?
It was hard to pick one thing, since we are good at many different aspects of software development. But there’s one company feature that I've found particularly attractive since the day I joined: Engineering teams really have great freedom to choose how to achieve their goals. You’re probably thinking "yet another article about aligning your teams through goal-setting instead of micromanaging." Well, no.
While I think that's great, I also think that orientation to goals is foundational, almost a commodity these days. If you don’t move beyond that, you end up being excessively reactive. In other words, it's necessary, but not good enough. For example, suppose you have 10 teams and define a common mission, which you then split into 50 goals (five per team). You turn back and, a year later, check up on it. In a good scenario, two teams have failed hard enough to doom the whole mission. I'm being too drastic. That's easy to solve: You define methodologies, processes, and rules, and document them really well. That's the end of freedom for your engineering teams (drastic again). So, what to do?
Compromising (The OOP parabola)
Is it possible to have a bit of this and that, the proper amount of process and methodology while still giving space and freedom to the teams and getting a calculated risk?
Well, I've seen it here. I see it daily. And it always makes me think about one of the OOP S.O.L.I.D principles: the Liskov substitution principle. This principle encourages us to define interfaces that act as contracts and have different implementations honoring those contracts. While an interface exposes the "what," implementations hide the "how." Beautiful, isn't it?
Now, let's suppose that you define a process that does what interfaces do: define a contract of what’s expected and let the teams figure out how. For example, the process would say that we will have a release and we want to get metrics of A, B, and C every X weeks. One team might consider doing scrum with a cycle of X, another team could go Kanban and simply take a snapshot every X weeks, another team could opt for defining their own way. As long as the process gets what it needs to check progress and determine risks often, we shouldn't invade teams to teach them how. Furthermore, the best how is relative to each team’s reality.
However, on occasion, it could be better to consider the process as an abstract class with some implemented methods. It's like saying "this is a trivial implementation you can use until you find a better way." Then, the team can override it and even use it if needed (super).
I haven't found a single method in Avature’s engineering processes that is marked as final, and while that makes me happy, I wouldn't condemn any organization that decides to restrict things a bit more.
About bureaucracy and automation (what a lovely couple)
If you think on a large scale, no matter how seemingly non-intrusive a process is, it might end up being a nightmare to operate, maintain, control, adapt…
For most of these problems, I usually recommend dividing and conquering. But what I found at Avature engineering is so good that I don't know if I could work differently again. (Almost) every piece of the process is automated and driven by software, and the orchestration of those pieces is supported by software as well. You create a case, assign it to a team, define the priority, start working on a cycle, plan when to release it, write automated tests, run these before going to master, merge, run the tests again, deploy, monitor the platform’s health, receive an alert, create a case for a bug (that almost never happens wink, wink)…
As long as you implement the interface you get the benefits of automation! I haven't seen this anywhere else and now I can't help wondering: If we have all dreamed of having robots making our beds and cooking for us, why wouldn't we make it true for the aspects of our lives where that's actually possible?
The realm of good ideas
A good, lightweight, and non-opinionated process sounds good. But does it shout "freedom"?
Are engineering teams capable of defining their own roadmap and make logical technical decisions? Does the environment encourage constructive tension? Is there room for risk and innovation?
We are a software product company. That said, we have a product-driven roadmap that takes input from different sources (the market, customers, field and product specialists, among others). But we all know that software is still a technical outcome and it can't be built neglecting the technical aspects that make software not good but great. For that reason, every engineering team has a technical leader (TL) that doesn't report to the manager. Usually, forces are aligned and we all understand the necessary compromise to have a balanced backlog. But, when not, neither the manager nor the TL can overrule each other. Furthermore, the process determines that both the manager and the TL be present for quarterly planning meetings.
Personally,I have a very positive vision regarding how the company values my opinion and supports my decisions. And it is not because I'm allowed to do whatever I want, but because of the way the company treats those ideas:
- Ideas are always heard.
- Ideas are accepted if properly reasoned: strong arguments such as ROI, Calculated Risks, Contingency Plans are a great plus if the idea is a bit controversial/disruptive.
- If an idea is set to a plan, resources and support come quickly and aligned with its importance/priority.
I have been part of great transformative projects since I joined; I even proposed and implemented some of them. Having this kind of opportunities let me step up, grow, make decisions, take risks, make mistakes, and try again.
Cool features for a company, don't you think?