We operate in a domain that requires us to learn and adapt in order to excel. Promoting our ideas, leading and impacting our industry has always been a challenge, but it is something we know how to do.
Market forces has tossed us into the bleeding pool of managing open source projects. Working in a community of service providers and vendors (and in most cases also our competitors), is more challenging than ever.
We quickly needed to find ways to evolve and mitigate those challenges so we can continue to lead our industry and impact on what has now become the de facto standard for network automation - ONAP.
The immediate concern for us was to figure out how to adapt to working in this community. How can we ensure that we are not just tagging along, but are actually there in front, pitching our ideas, showing significant contribution, so that our voice is heard.
We looked at our organization and how we can adapt to working in a community, where the community doesn’t have architects, doesn’t have testers, doesn’t have teams, real teams anyhow. AND how should we manage our upstream and downstream teams? The same? Different? How do we manage accountability? How do ensure commitments? How does managing microservice-based applications change the landscape for us? Do we really have on-shore, off-shore teams? These and many other challenges are happening in a rapidly changing environment. It seems more and more that our current approach is no longer valid. SCRUM can’t solve everything. Leaving aside all the flaws the methodology has embedded within itself, it seems like it is not AGILE enough for us.
We started to look around. Certainly we are not the first company which is dealing with these problems. We’ve interviewed several companies, among them Red Hat, ConteXtream and Wix. We established our methodology based on the inputs we have and the experience we’ve accumulated over the past few months, but mostly on our vast experience with all kinds of development methodologies we’ve been practicing in the past few years.
Our approach was to leave the day-to-day work to resolve itself, i.e. the teams that are developing features will create their own working relationships and find the way to work. We just said that they will work in small teams, no more than 3 (a 1 person team is also acceptable in some cases) and they will take ownership of their work end-to-end, real E2E, from design to RELEASE, including upgrades, release notes, etc. And… we called them squads.
A squad is not a constant. They are assembled to build a feature and then are disassembled when the feature is done. They go back to their teams, but what is this team that they go back to?? We called it GOS – Group Of Specialists. This team is a domain experts team, who are responsible for their domain – microservices. They own those microservices, manage their technical departments, are responsible for their health and maturity and take ownership whenever something is broken. This team is built from the different types of developers, front-end and server-side developers, and of course can have people from various development sites.
The important thing to understand is that squads are built from different GOSs. In most cases features are cross-microservices, so a squad may be constructed of members from 1 to 3 GOSs.
So… we took care of the day-to-day (squad) and we took care of the domains expertise (GOS). We now need to deal with cross-platform issues like infrastructures and methodologies that are used by all GOSs. What is the role of the developer in this environment? How do we promote, build, and push our developers to new heights?
This is where we introduce the Guild. Guilds are divided by roles: FED guild (front-end development) and Server guild. The guild’s influence in the developer’s life starts before the developer starts working. They are actually responsible to recruit the developers, and once they join the team, they start their work in the guild, learning the product, the different domains, the microservices and the different foundations. Once this is done, a developer will join one of the GOSs and from there be assigned to squads. The connection with the guild continues with “Guild Week”, where every few months a developer spends one week in the guild. There they invest in the product’s foundation and promote their skills and the product’s capabilities. In addition, every couple of weeks, we have guild day, where all the guild’s developers are getting together for couple of hours to share, promote, talk about technologies, solutions and all those things that we love to do as developers.
One more challenge we need to resolve concerns testing and quality. For that we’ve set up an E2E testing group. They will look at use cases and E2E scenarios (not necessarily for one product) and will take ownership from the release rollout to production.
We’ve started our journey with SDC – Service Design & Creation, an ONAP component. The team is led by Tal Halfon, our first PTL (Project Technical Lead). We’ve set high expectations to get the most we can from this methodology. We’ve set KPIs in the areas of efficiency (story throughput, quicker turnaround in problem solving, # of commits, etc.), testing quality (code coverage, # of defects, automations, etc.), and community work (code reviewers, committers, etc.)
We will encounter many more challenges in the months to come, but this is what make it exciting. Our vision is clear, we are determining to build a stronger, more agile, and happier team.
Looking forward to what future holds for us, I will update.