At the Portfolio Level, there are really no significant impacts for SVS pattern organizations. We still use Kanban systems to manage the business epic and architecture epic pipelines that flow into each of the Agile Release Trains (ART’s). In SVS pattern organizations, we still have high value in utilizing Investment Themes to drive operating budgets across all the ART’s. Additionally, because an SVS organization is operating at scale, we need to have an Enterprise Architect to drive technology direction across all programs / ART’s.
We are happy to announce that Naeem and Brian will be speaking at CD Summit on Wednesday, November 19th. Our session is called "Realizing Continuous Delivery: From Startups to Large Enterprises" - so take a look!
In the last article, I outlined the Large Feature Team pattern as a first alternative to the Ideal Team Structure (ITS) if your organization cannot make the immediate leap to the ITS when transitioning to agile solution delivery. In another article, I provided an overview of the concepts of feature teams and components teams. In this article, I will discuss the second alternative using a combination of feature teams and component teams.
Transforming to an agile software delivery model is filled with lots of challenges, especially when you are talking about solutions delivered in an organization of a large scale. In these large organizations, one of the most common practices to achieve perceived efficiency is to build an organization of specialists. Every specialist knows how to get their specific tasks done very efficiently. Additionally, large companies typically have very large and complex software architectures for their systems. Between the specialists and the complex architectures, the job of getting the entire solution delivered is actually very inefficient since it “takes a village” (often a very big village) to get anything delivered. The most intrusive inefficiency with these organizational models is that they are not designed with support for natural delivery flow.
When considering the Program Level of SAFe applied to Small Value Streams (SVS's - see the first article in the series for an introduction to SVS's), I will describe SAFe elements that "work out of the box" and those challenges that SAFe brings and solves for SVS's.
One of the great parts of the SAFe framework is the emphasis on usage of industry standard practices like Scrum and XP (Continuous Integration, Pair Programming, Test-Driven Development, and Acceptance Test Driven Development) at this level. Scrum provides the light framework for teams to deliver “done” software at a regular cadence and XP provides many of the disciplined technical practices that make it possible for teams to be hyper-productive.
To get grounded on what the Small Value Stream (SVS) pattern looks like, I will describe what SVS’s (1 – 4 teams, roughly 7 – 35 team members) look like.
Last year, I got inspired to read Dean Leffingwell’s “Agile Software Requirements” book. As I read Dean’s concepts (better known as the Scaled Agile Framework™ - or SAFe for short), it was obvious to me that we had independently arrived at similar framework-level solutions to scale agile and move towards release oriented delivery (see my Scrum Alliance article – The Big Lever). My experience that is most relevant to SAFe occurred during my tenure at a medium-sized financial services company where we transitioned from waterfall to agile and then grew to execute monthly releases with solutions contributed from 30+ scrum teams. The principal difference in our frameworks was that ours was developed around the fact that we had many small business value streams mostly disconnected from each other regarding business intent but connected by a mostly shared technology stack that provided the solutions to every value stream. Each small value stream only required (or could only afford based on our budgets) between 1 to 4 teams worth of capacity.