Building the Jumbo Tech Campus organization using Agile, Spotify and Pathfinders
At Jumbo, we’ve implemented an agile way of working, borrowing a lot from companies around us that have been doing this way longer than we have.
Because each organization is different, and implementing an organizational model is closely tied to the maturity of the organization, we didn’t blindly follow what all the cool kids around us have done. At Jumbo, we weren’t ready for all of these things immediately. Some other things simply aren’t applicable to us. Simply put: we did what is right for us, instead of blindly following someone on the internet.
At this 10,000 foot overview, we’ve kept it KISS (which means keep it standard, stupid in this case):
- We work widely accepted multi-disciplinary teams, containing all roles and skills that are considered core to the team goal, like front-end and back-end developers, testers and business analysts.
- We work using lean practices: removing waste from the software development value stream, creating short-cycle feedback flows and going to ‘pull’ delivery method.
- We use standard scrum practices and processes to carve up work. This means we do all the scrum rituals and have Product Owner and Scrum Master roles.
- We adapted the chapters and guilds concepts from the well-known Spotify model for agile organizations to our specific needs.
So, the tl;dr is: we didn’t reinvent the wheel, but rather leaned (pun intended) on Agile and Scrum, and borrowed from the Spotify model where applicable.
A little on the ‘why’
We do agile for a couple of different and very simple reasons:
- Autonomy of teams, optimizing independence on a local level. We want the organization to be effective, simple and clear. Anything else hinders productivity, as team alignment in bigger organizations is a pipe dream.
- Flow, making sure the team delivers on small increments of work, has a closed and quick feedback cycle and has an uninterrupted flow of work, not inhibited by bottlenecks external to the team.
- Simplicity: we want a simple model that everyone understands. This in turn simplifies onboarding, helps to explain our way-of-work to people outside the org, and more. Using a set of simple and well-known principles from existing frameworks simplifies explaining that.
How we organized ourselves
With these three basic premises, we have organized ourselves in the following way. As a food retailer, we like to explain things using food-references.
The ‘building block’ of our agile organization is the cherry, a small organizational cell, aligned to a technical domain. In the stem, we have the Product Owner and Team Lead, who are closely aligned. They work in tandem with a fixed number (two, sometimes three) of development teams. Technologically adjacent teams form tribes and solve similar issues together to reduce ripple effect to smaller, less complex scale.
Each team has a Team Lead, an experienced developer who’s HR-responsible for their team members. The Lead helps the teams with the ‘how’, coaches them on personal development and is the all-round escalation point for the team.
Each team has a Product Owner, responsible for the ‘what’. The PO is not part of the team, but rather part of what we sometimes still call ‘the business’, but the distinction between ‘the business’ and ‘IT’ is rapidly fading. They are not wholly responsible for all the work ‘their’ team does; teams also do work not dictated by the Product Owner.
We try to be aware of Conway’s Law and plan our teams around how we want software to be delivered. We organize teams in a couple of different ways:
- A technical domain, system or challenge. An example is ‘the app team’ or ‘the ecommerce core team’. These teams take ownership of a technical domain and independently develop and release into production. They are responsible for all of its aspects, like ‘tech stories’, some architecture work, and increasingly, Ops for the software they deliver.
- A business outcome. An example is ‘the shopping basket’ or ‘content team’. These teams take ownership of distinct part of the customer journey.
Turning the org around to reduce Friction
We try to avoid business function teams like ‘HR’, ‘Sales’ and the like. Those are exactly the type of organizational silos that we’re actively trying to dissolve.
As you can see, we try to avoid business function teams like ‘IT Operations’, ‘HR’, ‘Sales’ and the like. Instead, we’ve turned many of the services these departments provide inside-out and try to integrate them within the teams.
For a number of business functions closely related to the work the teams do, this works well. For instance, integrating the Team Lead into the team closely aligns HR-work with the team, making it a more integral, less corporatey part of the team.
For IT Operations, this works well, too. We’re working on diminishing the traditional disparity between development and operations, and moving operations of the entire ecommerce stack into the development teams. In the future, these teams will take responsibility of all aspects and phases of the technical domain they’re working on, not just the software development aspect.
These teams become less dependent on the silo’d business departments around them, but instead become more agile and nimble. They are able to decide on more and more aspects of their technical domain independently.
In other words, we give tribes, cells and squads the freedom to make their own decisions on IT ‘things’ that traditionally would be mandated from a central IT department, like infrastructure, identity and access management and operational management tools (monitoring, deployment, testing, etc.). We’re in the process of stopping forced usage of those central IT resources, and instead, teams choose their own.
All-in-all, we aim to completely decentralize the traditionally silo’d IT-department as a guild, that manages the end-to-end collection of connected simplicities (otherwise known as ‘architecture’). We integrate the roles and knowledge from that IT department into each of the teams.
This has some major upsides: bite-size and low-friction infrastructure consumption, better and more quickly integrated into their deployment pipeline. The services they choose tend to be self-service, ready-to-use, pay-as-you-go and most importantly: without the many dependencies traditional centrally provided IT services have. There’s no big and expensive company-wide infrastructure that has to be used by all in the org because it was a capital-intensive investment. Instead, teams have smaller, independent budgets, with which they can buy smaller, independent services.
Teams are in full control of the buy vs. build decision for each of the services they need to deliver software functionality and to operate it in production. This prevents heavy customization of a commodity-off-the-shelf software product.
Pathfinders lead the way
The inevitable downside is that different teams choose differently. To keep this problem manageable, we’ve introduced the role of pathfinder. A pathfinder is closely related to a Chapter Lead in the Spotify model. They are experts in their field, and mainly focus on the harder skills (in contrast to Team Leads, who focus on softer skills).
Pathfinders lead efforts across all scrum teams, like leading Guilds and Chapters, with team members from across the tribe in similar roles. For instance, the Design Pathfinder would hold meetings with all front-end developers, and the Quality Assurance pathfinder would hold meetings with testers and business analysts.
In a lot of respects, we do Chapters and Guilds for many the same reasons Spotify does: safeguarding non-functional and qualitative aspects. Pathfinders also help in efforts that span across cells and tribes, such as architecture, big initiatives and cost optimization.
At Jumbo, the pathfinders have a more qualitative perspective. They establish and implement way-of-work principles using, for instance, Coding Guidelines, Design Handbooks, ready-to-consume cloud services and micro-service scaffolding. They define standard use of technology and help teams implement these across teams.
Pick and Choose
We talked about a lot of different areas of our organization. This is just high-level overview. Because there’s a lot going on, we’ll dive into these distinct aspects separately in future blog posts. For now, I’ll leave you with these 12 aspect of building the agile organization at the Jumbo Tech Campus:
