Blog

Cloud

How to become SaaSi...a personal change story

It’s an usual goal to make yourself redundant, but when it’s for the greater good, it can become almost an obsession!

Author Image

Adi Yahas, Program Manager

Amdocs


07 Mar 2022

How to become SaaSi...a personal change story

Layout canvas

Let me explain. Last June, as leader of Amdocs’ Optima Center of Excellence team, I had the privilege of coaching managers and teams as they navigated their Agile journey. One of my most important objectives was to guide them in changing their mindsets and practices.

I wanted them to move away from the traditional “reactive” approach to one where they would actively seek early feedback and use that information to create fast business value.

Things were going great until our CTO offered me some advice. He suggested that I switch my own mindset too and go “Agile out of the box”, leaving me scratching my head as to I what had I been doing wrong until now.

I then understood what I wanted from my next role: to be part of this great team and transform this idea into reality.

Which is what eventually led to our new way of working. “Agile out the box” is a concept that supports and accelerates our SaaS journey, driven by the following main elements:

  • Domain-driven design, which creates boundaries around business functionality – technical development driven by independent business domains
  • Treating internal integrations the same as integrations with external systems / users
  • Trusting that other domains will satisfy their contract with the world
  • Fostering cross-domain collaboration
  • Focusing on the working system instead of stories marked, “done”

Although we’re a sizeable unit (~20 scrum teams), being service-oriented means each domain defines its own contract with the world. To do this, we use three main elements:

  • URL
  • API
  • Authentication (based on AWS and cloud-native approaches)

This also led to the understanding that for us to be successful as a team, we need to apply the same principles to the way we run the product organization, which meant doing away with the program management office!

To explain better, the operation of a program usually creates dependencies and requires people to act as integrators. But this idea goes against our new way of working, where independent domains and teams are the ones who own their product. Because they are meant to be self-sufficient, they are the ones to best manage it based on their deep understandings, allowing them to operate in context and within well-defined boundaries.

In October, I joined R&D as Agile program manager with one clear goal: to eliminate my own role by coaching and mentoring managers and teams to operate their domain in a way that empowers them to choose priority items from the backlog, code them, release them and deploy them on an ongoing basis.

In a nutshell, here’s how we shifted our focus and mindset:


From To
Technical user stories Incremental business value user stories using the INVEST model
Measuring time and capacity Estimate story points and measure velocity
Planning and predictions based on epics and capacity Planning and predictions based on user stories and actual velocity
Sprints and PIs Kanban with weekly targets and retrospective analysis

While I haven’t yet achieved my goal, I’m well into the journey and making excellent progress!

To be continued...