My Agile Journey

I was formally introduced to agile exactly 10 years ago when MySpace brought in Jeff Sutherland, the co-inventor of Scrum to train our entire Product Management team. Until then, as Product Managers, we were using Product Requirements Documents (PRDs) as the primary source of truth for development. And email was still the dominant form of communication across teams. So when I had a new feature/product idea, I’d usually go to the development line manager, so they could ‘assign’ some of their ‘resources’ to work on it. This assignment depended on the robustness of the PRD, number of use cases, negative scenarios and general format etc. In other words, the more detailed the requirements, the better chance of getting engineers to work on them. This led to long documents that developers were less than thrilled to read. Putting all the information ‘upfront’, also meant making several assumptions to generate them. And once in flight, updates to the PRD meant lack of research and due diligence; so they were usually not updated.

Jeff, in his sessions introduced the idea of SCRUM. Where development is done in small repeatable cycles by a cross-functional team of engineers, a product manager and a scrum master. Work is pulled from a list of items (product backlog) that is developed and tested within a few days and deployed to a production environment every few weeks. Further, the team members meet on a daily basis to sync up on the progress (standup) and line managers help provide technical coaching/assistance instead of gate keeping their direct reports.

These ceremonies and artifacts are now widely accepted as the essential building blocks of lean-agile development. And I’ve been fortunate enough to put into practice the principles of Backlog grooming, Sprint Planning, Daily Standups, Demos and Retrospectives into all of my software development ever since. Whether with early stage companies, where lean has always been the mantra (not out of choice but necessity). Though lean became a standard ever since Eric Reis published his hit book The Lean Startup in 2011, larger organizations have come to respect agile essentials in accelerating business value delivery as well. For example at YP.com and Mgo/Fandango, I often facilitated team standups, gathering around a physical board with post-its describing user stories. Moving left thru right in various columns denoting their statuses. This physical equivalent of a Kanban board is sometimes perhaps the easiest way for teams to start visualizing and introducing transparency (one of the key pillars of Agile) to their work.

Now this works well for a handful of teams, but complications arise when this model needs to duplicated across dozens of teams, where alignment and integration of work becomes a key issue. Many times, organizations will adopt an agile-waterfall hybrid where individual teams remain agile but their large scale planning, staffing and integration is still done in a linear fashion. SAFe, one of the more popular frameworks for scaling agile addresses this problem and provides a framework for scaling agile in enterprises.

I was first introduced to SAFe about 3 years ago when I started working as a product owner for a large media-streaming company. This effort that spanned a few hundred people was supposed to grow as more platforms supporting the streaming app were launched. At this point there were already about a dozen agile teams, each no more than 9 or 10 in size, made up of product owner, a scrum master and full stack developers and testers. These teams together with around a 100 people total then formed what SAFe calls an Agile Release Train (ART) or just ‘Train’ in short. The Program Increment (PI) planning – one of the core strengths of SAFe (or magic as it has been called), is done every 10 to 12 weeks with all of the members on the individual teams that make up the Train. By forcing the entire program to plan together (in person), teams are aligned to a common vision, business context and goal commitment. This is the basis of what is known as Essential SAFe. Most organizations moving to SAFe start with this version .

Essential SAFe

The cross functional teams made of developers, scrum masters and product owners power the train. There are further supported by an uber-scrum master called the ‘Release Train Engineer’ (RTE). The RTE, along with the Product Manager (an uber Product Owner) and an Architect, forms a trio that support the ART to deliver meaningful work at the end of each iteration and program increment.       

Portfolio SAFe Before grouping teams on a train, diligence needs to be done such that the ART can deliver value with minimal dependencies on other teams. This is achieved by a Value Stream mapping workshop that helps determine who (which teams) should be on an ART. This is perhaps the most crucial workshop while impmenenting SAFe. And it is run with executives and their teams to form the right grouping of teams by organizational value. Other notable concepts include establishing Lean Portfolio Management (LPM) that manages the initiatives at the portfolio level via a kanban style board. These large initiatives, called Epics are supported by lean business use case, which is SAFe’s version of the old age one pager.

Portfolio SAFe

Large Solution: For larger initiatives, multiple trains (ARTs) are stood up, such that the dependencies between ARTs are minimal and they are independently capable of delivering business value. Two or more trains are combined into a Solution Train that is guided by another triad of ‘Solution Train Engineer’ (STE), Solution Architect and Product Management. This along with the Portfolio layer constitutes Full SAFe.

Full SAFe

SAFe implementation typically starts with training leaders on SAFe principles, ceremonies ad roles by SAFe Certified Program Consultants. The SPC usually have had experience with multiple agile transformations and PIs and they guide and hold the organization on the path to becoming agile. The SPCs can further be augmented by training internal agilest, by providing them with the same level of SAFe education. This is followed by training the teams as Trains are identified via the Value Stream Mapping workshop.

It can take a while to understand every part of the SAFe framework and how it applies to your business. The principles are based on the Agile Manifesto that were put together almost two decades ago. So values like Individual and Interactions over processes and tools can be seen throughout the framework, as is the focus on Working Software and Responding to Change (over comprehensive documentation and following a plan respectively).

In summary, SAFe offers a detailed approach to Scaling Agile in Enterprises. Whether defining the ceremonies that should be performed, the roles that should be created or artifacts that should be produced, SAFe is well suited for large companies that need a more defined governance framework for scaling agile in their organizations. You can find this documentation including every aspect of the framework on their website.

Good luck and safe journeys ahead!

Taking a Kanban board to the next level

Intro: With 20 years of experience building products for social media, ecommerce and energy clients, Manoj has been an agile practitioner for the last 10. His interests include paddle boarding, kayaking and helping individuals and teams get better at building products and delivering value. Manoj is a certified SAFe Program Consultant, Scrum Master and Product Owner.

Photo Credit: Marko Stupic

Chart Credits: Scaled Agile Framework