A way to be Agile without micromanagement

Everybody nowadays says they develop software with agility: individuals and interactions, working software, customer collaboration, responding to change. Who wouldn’t agree.

But the real complexity is in the practice, where the principles are constantly challenged.

After more than one year of experience of running the 6-weeks Squads at Adbrain, I wanted to share some learnings.

How agile masks micro-management

Business loves control, it’s in the nature of it: revenue forecast, cost-benefit analysis, delivery deadlines — music to ears. But engineers are creatives and love freedom: prototype, design patterns, refactoring — ‘just one more week and it’s done’.

The Agile movement has been instrumental in finding a better balance in this tug of war, and has proven to be effective in the last 15 years of mainstream adoption: software gets delivered faster, developers are happier and ultimately innovation has accelerated.

But with methodologies maturing, there’s the tendency to focus more and more on the processes rather than the principles. How do you get better at estimating task for user stories? What’s the best use case for TDD and BDD? And the list goes on.

Scrum has been refined to increase predictability, for example with a burn-down chart you can better understand the pace of delivery. This works very well if you build similar software, but can radical innovation be predictable?

Kanban has the advantage of keeping the focus and reducing the wastage of work and time. But the big picture is often lost and the awareness of the impact is diluted. It’s like walking in a colorful medieval village: you can see the pretty houses, colorful flowers and you get to know very well how to orientate in the maze. But only if you go on the hill next to it you can appreciate how magnificent it is.

Sometimes I have the impression that developers are trapped in a cargo cult, being introduced to the rituals of agile that will bring the myth-dream of “freedom & power to engineers”, without realising that methodologies can become a smart trick for a more sophisticated, invasive micro-management tool.

Is it really playing planning poker the most interesting way to contribute? You, as a developer, don’t aspire to have a more meaningful impact than a 2-weeks sprint planning?

There’s a way to empower autonomous team without board members logging in to check lines of code: a neo-agile approach.

Mission, time-boxing, and responsibility

The key to staying away from micromanagement is to be outcome driven, be explicit on the resources and constraints, and trust your team to get the job done.

The core of the system is a structure that exists in between the business and the delivery team — the ‘Squad’: an autonomous cross-functional team that has 6-weeks to achieve a mission.

It seems what everybody is doing, or at least saying is doing. But we’ve found a combination of characteristics that makes it game-changing: mission, time-boxing, and responsibility.

I consider these 6-weeks Squads to be a fork of the Spotify’s Squads, reinvented for a smaller, faster scale, and for a resource-constrained environment.

Mission. Be specific. But give problems, not solutions

The mission is one of three cornerstones of the Squad’s success. It targets the specific area for improvement, crystallising the problem that needs to be solved. But it doesn’t provide a solution to implement, it’s the responsibility of the team to figure out how to do it.

An effective mission is result-oriented, it indicates the picture of success when the mission is achieved. It needs to be realistic and achievable in the 6-weeks opportunity. It also needs to be narrow enough to guarantee focus, but general enough to stay away from the details.

For example, if your problem is a product that is getting traction but requires a lot of engineers operations, you could be tempted to give a solution-based mission: “Add a management and monitoring UI for the product XYZ”. But you could have instead an outcome-driven mission: “Streamline the XYZ process to allow the client service team to independently service our customers, in a reliable and automated way”.

Now it clearly states what the problem is and allow the Squad members to figure out the best way to solve it, in 6 weeks. Together with the product owner, the team will figure out what’s the best trade-off to achieve the mission: instead of a UI they might build a command line tool for your geeky CS team. You’ll be surprised by their solution you didn’t even think about!

The effect you create is double-sided: the business has enough visibility to see how engineering work is contributing to the success, relaxing the control-freak instinct usually coming from the lack of understanding on what the team is focusing on. On the other side, engineers have clarity on what is the business objective to be achieved and the autonomy to implement the best solution without story points or other violently transparent tools.

The mission becomes a promise to solve problems, not build features. A ubiquitous language that everybody can understand and relate to.

Time-boxing, Longer & Actual

We all know from the project management triangle that you can fix only two out the three attributes: resources, time, and scope. But what the triangle is not telling us is an effective combination of the three: how many people work well together? What is a good duration of time to empower people? How precise do you want to be on the requirements?

Despite the methodology you’re using, the real world most of the time works like this: you start with a set of detailed requirements of things to build, you put a non-trivial effort in estimating the effort and then you plan resources to deliver on time. And you constantly fail to deliver.

We introduced what I call an “inversion of control”: instead of forecasting the time based on estimation, you have time as a fixed element. You replace requirements with higher level problems to solve, and detailed estimations with order-of-magnitude complexity assessment. Then you let the team both define the requirements and build them!

There are also two other elements that make the system works well: longer duration and isolation from disruptions.

We decided for six weeks because it’s a duration that allows out-of-the-box thinking, prototyping and delivering a solution to non-trivial problems. It’s also long enough to leave room for internal iterations but short enough to not give the illusion that the end is too far in time. You can see the end when you start.

You also want to protect the Squads from disruptions and context switching. There is a special Squad that works on a weekly rotation, called ‘Solutions’, which is the first line of defence: among other responsibilities, it deals with production bug fixes and any urgent customer-facing needs. This guarantees that the time spent in the 6-weeks squads is predictable and usually free from disruptions, while the Solutions team guarantees a first-class service to your customers.

You ultimately change the attitude from “we need these functionalities asap; how long does it take? implement them until they are ‘really’ finished” to “we have this problem, you have 6 weeks opportunity to get the best trade-off delivered, go and do it!”. It protects against scope creep and problems of defining ‘done’ that come with agile.

Responsibility: Don’t finish tasks, achieve a mission

When a team controls both the scope and the execution, they are empowered to succeed and they are the master of their own destiny. This is the key that makes people accountable to each other and fosters a collaborative environment.

Let’s assume your software delivery metrics are based on how many tickets you work on and how fast you open/close tickets. If somebody in your team needs help, even though you could help, you might actually decide not to, as you’re focused towards finishing your own task.

But with Squads nobody is measured on such metrics, the squad success is considered as a whole. You might then want to help others in finishing their work, because it’ll help you achieving the mission.

You also prevent the go-it-alone cowboy behaviour, I’ll save the world alone. An interdependent autonomy emerges, you succeed when everybody else succeed, and everybody else will succeed when you can work in autonomy to help the team. This brings back the importance of the individuals, it prevents that Agile turns individual developers again into cogs of the machinery, making the disposable clones within a more or less anonymous process.

You want to respect and leverage the seniority of the tech leads, as the order-of-magnitude complexity assessment can be effectively done only by whom has multiple times seen the long-term impact of their decisions — developing the necessary intuition to protect the team from taking shortcuts that they’ll regret very soon.

With great power comes great responsibility. The good news is that smart, empowered people can be trusted.

Not only bells and whistles

Refining this neo-agile methodology for more than a year allowed us to also get to know the minuses of it.

The mission is very helpful in determining the ‘What’, but lacks in providing more context on the ‘Why’ the mission is important and how it affects the company success. The product owners put a major effort in being sure that the kick-off meeting, and throughout the whole duration of the Squad, there’s as much clarity on the Why as there’s on the What. I firmly believe that context and sharing of knowledge are key to empower the team.

You also observed a tendency to release ‘all at the end’ in a waterfall-ish approach. It sounds counterintuitive, but missions are quite ambitious and empowered people want to succeed! There’s an instinct to squeeze in as much scope as possible with the illusion that ‘we can do it’. Instead of imposing a cadence in the internal release (e.g. sprints), we asked the team to agree at the beginning on an MVP (Minimum Viable Product) — which represents something that should be completed halfway.

Even if the 6-weeks Squads are game-changing in terms of empowerment, they could be perceived as a myopic tool: they can be attributed to short-sighted planning and trade-offs in both commercial requests and tech decisions. But be very careful in falling into the trap of blaming the tool: Squads are 6-weeks opportunities to make progress on business objectives towards the success of the company. If you struggle in breaking-down a bigger problem in smaller achievable milestones or you don’t give enough clarity on the longer term vision, it’s mainly a problem of planning and lack of context.

For example, at some point we needed a significant increase in efficiency in one area of the stack. We recognised it was a major effort, it would have been almost a miracle if a team of four people would have solved the problem in 6-weeks. But we accepted the risk and we went ahead anyway. At the end, a “follow-up” Squad on the same problem was needed.

Was this a Squad failure? It was definitely not, it was a planning error. We didn’t respect one of the core roles — mission has to be realistic and achievable — and we failed at breaking down further the problem.

There’s also plenty of room to improve in involving everyone in understanding and having a say in every stage of the planning and roadmap-ing, providing a bottom-up approach for initiatives to be prioritised.

A ubiquitous system

6-weeks Squads allow you to shift from delivering a laundry list of stuff — call it user stories, requirements, features, … — to higher level problems to solve that everybody in the company can understand and relate to. It can be a customer problem, an engineering challenge, a cost optimisation effort: everybody will understand what the tech team is working on and how it contributes to the company success.

Prioritisation is a trade-off exercise, which is most of the time hidden and leaves the business in the illusion that everything will get delivered, at some point. This triggers the control-freak instinct when the ticking-clock breaks the bubble.

With Squads, the trade-offs are organically exposed from the very beginning. There’s no need to micromanage because you only talk about realistic work that gets achieved.

There are well-known examples in the industry of successful innovative Agile methodologies, like Spotify or Transferwise. But they are effective in large teams and later-stage products.

6-weeks Squads work in a way smaller scale (12–20 people) and in a context of a higher need of adaptability. You can manage to innovate quickly, delivering values to your customers but not forgetting to have in place strong foundations for growth. Without micromanaging engineers.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!