SAFe for Small Value Streams – The Portfolio Level and Wrapping It Up

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.

In summary, SAFe provides a fantastic framework for scaling agile at Small Value Stream patterned organizations. With the addition of a thin layer for SVS Level Product Management and Backlog, SAFe provides a solid structure for implementing broad program initiatives while maximizing flow for the majority of product development happening locally within the SVS’s.

SAFe for Small Value Streams – Business Intent Flow and Organizing to Deliver Program Level Features

Small Value Stream (SVS) pattern organizations have the largest portion of their product development flow starting locally with intent generated from within each SVS. Therefore, we can optimize the planning within any SVS by using the Vision, Roadmap, and Program Backlog elements of SAFe by localizing these concepts to each SVS. However, there are rarer, but important, program-wide epics that require coordinated flow and planning across multiple SVS’s and their associated teams. I first introduced the following picture in the second article in this series. It depicts the business intent flow between the Program and SVS Levels in an SVS organization.

 

Let’s dig into the picture a bit, starting at the top. For those rarer Program Level features that cut across multiple SVS’s, the Program Level Product Management team is responsible for managing the Vision, Roadmap, and Program Backlog at the Program Level (depicted in blue). The Program still needs to manage business features along with architecture features (depicted in red) that are applicable across multiple SVS’s. The SVS-Level Product Management team (one for each SVS) is responsible for managing the Vision, Roadmap, and SVS Backlog at the SVS Level (depicted in green). Depending on the needs and priorities at the Program Level for the next PSI, the SVS Level Roadmaps and Backlogs will be informed by those Program Level priorities.  Additionally, an allocation model developed for each PSI will be utilized to determine the apportionment of the Program Level features vs. SVS Level features for each SVS. Those SVS’s, and their associated teams, that are heavily allocated towards Program Level features for the upcoming PSI (like SVS # 1 above) will be fully involved in the Program-Level Release Planning event at the start of each PSI. These SVS’s can still plan for delivering some SVS Level features in that PSI but they will focus their attention and priority on the Program Level features during Release Planning. SVS’s and teams that are slightly impacted or not impacted at all by Program Level features (like SVS # 2 above) can send proxies (such as Product Owners) to the Program Level Release Planning event rather than sending all team members. Therefore, when considering SVS and team allocations for Program Level features, it is better to have SVS’s and their teams mostly involved or mostly uninvolved with the delivery of program features so that there is clarity of participation in the Release Planning event.

As expected from SAFe, the participants in the Release Planning event will produce a set of PSI/Release Objectives and a PSI Program Plan. Those Objectives will mostly include the Program Level objectives but can also include any notable SVS Level objectives that should have visibility at the Program Level. The majority of SVS Level objectives will not be included in the Release Planning’s Objectives since they represent planning that is primarily done sprint-by-sprint (or PSI-by-PSI if that is preferred by the SVS) solely within the teams of that SVS.

Regardless of a particular SVS’s participation level in the Release Planning event, all teams within the Agile Release Train will still gain the lean benefits from a common cadence (i.e., 2-week sprints and 8-12 week PSI’s) and synchronization across all teams.

The System Demo held at or near the end of every 2-week iteration still holds the same value in the SVS pattern organizations. The System Demo should be concentrated on the PSI/Release Objectives and no significant time spent demonstrating any local SVS objectives which can be targeted in a separate demo aimed towards the local SVS stakeholders. Similarly, the Solution Demo, as part of the PSI’s Inspect and Adapt workshop, should be concentrated on the PSI/Release Objectives.

For SVS pattern organizations, the Program Level is really the most impacted level in SAFe. The next article will describe the Portfolio Level of SAFe applied to these organizations.

 

SAFe for Small Value Streams – The Program Level

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.

First, let’s look at a working model for an Agile Release Train, or ART, for an SVS pattern organization. As I described in the first article in this series, an SVS pattern organization, we might have 10 – 20 SVS’s all working on a connected technology stack with each SVS having 1 – 4 teams.  Therefore, we are talking about 20 – 50 teams contributing to the code base for the next release, assuming we average about 2 – 2-1/2 teams per SVS. The SVS pattern ART then requires these SAFe elements across all SVS’s to frequently release software across the 20 – 50 teams: 

• Release Management – the SVS ART still needs a governing set of stakeholders who ensure the release content is technically sound and coordinated to be a viable set of business intent. Because there are many SVS’s, we might need to proxy in the Release Management team to represent the combined interests of all business lines. Often, this representation can come from the business that is the closest proxy for the customer – like the Sales or Marketing business.
• Shared resources, including User Experience (UX), System Architect (SA), and Release Train Engineer (RTE) – Because the SVS’s are often connected by a common technology stack and deliver combined releases, all of these shared Program Level roles are critical for making the Train run. A UX team ensures the user experience remains consistent across the deliveries from the 20 – 50 teams. Similarly, the SA ensures lean governance of existing and evolving architectures in the design and code delivered by the teams and works with the teams to ensure that an architectural runway is maintained. And most critically, the RTE makes sure the success of all elements of the upcoming release.
• System Team – we still gain enormous value in an SVS pattern organization by centralizing the System Team functions such as configuration management, continuous integration, end-to-end automated test governance, and environment management. If staffed liberally, we can more economically provide all of these important services to the 20 – 50 teams with little to no wait times for servicing the needs of all teams. Additionally, we can provide key governance on these delivery elements to ensure the release gets out the door reliably.
• Inspect and Adapt (I&A) workshop – all of the elements of I&A still apply for SVS organizations. There is real value from the solution demo, quantitative measurement, and problem solving aspects of the I&A workshop. Because the release orientation of the SVS organization, this I&A workshop provides the venue for focusing on release or program level continuous improvement. For practical purposes, we will have representation from each of the teams attend the I&A workshop rather than trying to have 150-400 team members all in the same room.
• Economic Prioritization – all of the existing aspects from SAFe for prioritizing work based on the economics of product development flow using WSJF (Weighted Shortest Job First) are still wholly applicable for SVS organizations.

So, for SAFe at the Program Level, we have not yet covered Roadmaps, Vision, Feature Backlog and Product Management. The SVS’s develop most of their business intent independently from other SVS’s. However, we still need to get those rarer, but very important, program-wide epics and features delivered. I also have yet to cover the topics of Release Planning and Objectives. Since these topics are really the crux of using SAFe in an SVS pattern organization, I will devote the entire next article in this series to these topics.

SAFe for Small Value Streams – The Team Level

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.

So, even though the number of teams in a SVS is small (1 – 4 teams), to be truly agile, the practices within each team still require frameworks like Scrum and practices like XP.

Regarding SAFe’s Potentially Shippable Increment (PSI) cadence and synchronization, these elements do impact teams but still fit very well in the SVS pattern. All of the SAFe concepts around Lean Product Development Flow still apply to the SVS pattern. These organizations benefit from a common cadence across SVS’s for aligning program intent delivery or synchronization of commonly used technology stacks. Therefore, PSI’s are still very useful in an SVS pattern organization. Because it is more the exception for needing coordination of business intent across SVS’s, each SVS can generally develop useful, marketable intent in shorter timeframes. Therefore, the PSI for an SVS organization might not need a full suggested 8-12 weeks (i.e., 3 – 5 two-week development sprints plus the Hardening-Innovation-Planning (HIP) sprint). In my experience at SVS organizations, there is often the ability to align to shorter PSI’s (4 – 5 weeks). Especially if the SVS organization invests properly in continuous integration, the overhead for releasing to production can be small enough (<= 1 week HIP sprints) to favor the value of releases getting out the door at a higher frequency. SAFe does provide for the release cadence being faster than the PSI cadence. However, I have found that the value of a HIP sprint, and in particular the Hardening intent of the HIP sprint, synchronized across the many SVS’ is often necessary to get to a viable production release.

In summary, the Team level of SAFe works pretty much as-is for organizations with the SVS pattern.  Some of the SAFe Program Level elements do have impacts on operation of the Team Level. These team-impacting elements include Release Planning and Inspect & Adapt Workshops. These will be covered in the next article on the Program Level.

SAFe for Small Value Streams – Small Value Stream Pattern Explained

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.

First, let’s describe some examples of business value streams at a financial services company so you can get a flavor for the problem set:

• Deposit Services – business aligned to checking, savings, and CD products
• Deposit Operations – business aligned to back-office processing of deposit product features, such as check deposits, ACH processing, etc.
• Home Loans Acquisitions / Sales – business aligned to marketing of and acquisition of mortgage customer applications
• And so on….

Second, there is the matter of scale. For medium-sized companies, the IT investment in their products does rise to a level that you still need to be concerned with how to scale agile delivery. However, you are generally talking about IT shops with 100’s of team members rather than 1000’s. This does not preclude the potential that the SVS pattern might be present in larger companies. However, you will generally find that larger companies, due to their scale, will have 6 – 12 teams dedicated to each value stream much like the examples given above. In SAFe terms, that is about the right size for an Agile Release Train.

Third, the business intent for these SVS’s are most often not connected to each other. Therefore, they can create and maintain vision documents, roadmaps, and program backlogs that are mostly independent from each other and that allows them to make faster, local, and more adaptive product decisions. There are occasions, more the exception than the rule, where program level program initiatives need to take precedence over the SVS’s local priorities. For example, re-branding the website or an architectural shift to a new database version or system. For these broader initiatives, coordination of priorities and feature backlogs across each of the affected SVS’s is required to make these program deliveries happen.

Fourth, as an optional element of the SVS pattern, the technology stack (presentation tier, service layer, and back ends) for any SVS might be heavily shared across multiple SVS’s. So, while the business intent is mostly independent across SVS’s, there is a common set of platforms and components that are updated by teams in many SVS’s. As further optional element of the SVS pattern, these updates by many SVS’s could combine into a common, synchronized release that happens at a predictable cadence.

So, the SVS pattern emerges because: 1) the scale of each value stream is relatively small, 2) their business intent is rarely connected across value streams, and 3) optionally the technology stack is shared across value streams.

Therefore, for example, elements of SAFe, like the “all team members on board” Release Planning event, do not seemingly help the majority of value delivery across 20-50 teams. Can I realistically expect to get 300+ people in the same room for 2 days? Probably not. And if you could, would such a meeting have any chance of being effective? Definitely not. But what about those rarer program initiatives that do cut across multiple SVS’s – how do we get them delivered? In a future article, I will describe how SAFe, in a slightly modified execution at the Program Level, could be used to aid in the delivery of these larger program initiatives. As a preview of that article, here’s a picture that introduces Small Value Stream Product Management and accompanying Vision, Roadmaps, and Backlog for each SVS.

 

You might be saying, “Do we really need another layer?” Well, the highest majority of product management planning is happening within each SVS regardless of the broader Program Level planning. Therefore, the SAFe Program Level Product Management is relatively lightweight and provides a binding structure for getting those rarer cross-SVS initiatives delivered. I will spend more time explaining this flow in the future article.

In the next few articles, I will start looking at each level of SAFe, Team, Program, and Portfolio, and outline how it can be applied to organizations with the SVS pattern.

Applying Scaled Agile Framework (SAFe) for Companies with Small Value Streams

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.

At the end of 2012, I had the privilege to attend the SAFe Program Consultant (SPC) Certification training in Boulder with Dean leading much of the training. Yes, I passed the test and became an SPC! But, more importantly, I started thinking about all the benefits of the SAFe framework and how it could be applied into a Small Value Stream organization much like the one described above.

This article series will explore:

• A deeper dive into describing the pattern of a Small Value Stream delivery model,
• Similarities in frameworks between SAFe and the framework we developed at the financial services company – for the purposes of this article series, let’s call this SVS-AF or Small Value Stream Agile Framework, and
• Potential execution modifications for SAFe to account for the SVS-AF shortfalls and benefits.

Agile-Colored Glasses – mentioned in VersionOne’s Agile Chronicles

Scrum Alliance article, Seeing the World Through Agile-Colored Glasses, got a nice mention in the March 2013 VersionOne Agile Chronicles! Nice surprise!

Team Design Patterns – Wrapping it up

Pulling all the ideas together from this article series, I want to leave you with a couple of key thoughts when you are trying to design your agile organization:

1. When designing your next organizational structure, keep in mind that the target for your organization should be the Ideal Team Structure. The journey may take months or years, but you need to organize your teams to bring the opportunity to incrementally reach this target.
2. Don’t avoid the inevitable disruption that a move from waterfall process to agile frameworks will bring. The impacts of the disruption won’t last for long and the benefits of doing business in an agile way will pay dividends quickly.
3. Agile frameworks require thoughtful construction of an organization that maximizes delivery flow. Maximum delivery flow breaks out when the development teams are directly connected to the Business Intent Generators (BIG’s) and you don’t need multiple teams to turn intent into delivered solutions.
4. These articles represent some agile team patterns. Your organization will most likely need one, many, or a hybrid of these patterns to be successful. If you have not had experience with an agile transformation and how to design your organization for this change, hire a solid enterprise agile coach to help you with this part of your transformation. You won’t regret it!

This completes this series on Team Design Patterns and I hope you found it useful and informative. Please post a comment to let know.

Previous article

© 2012-2013 AgileTrailblazers, LLC – All Rights Reserved

Team Design Patterns – Feature teams with mixed-composite skills

This article is about the third and final alternative to the Ideal Team Structure – feature teams with mixed-composite skill teams.

Let’s assume that you still have an organizational issue of too much specialization of skills. With that assumption, it is difficult to jam-pack all skills, knowledge, and expertise into a 7 +/- 2 sized team to be able to transform every piece of business intent into a workable software solution. The idea behind mixed-composite skill teams is that you can create different mixtures of skills across many teams (each sized at 7 +/- 2) and design those teams so that their skill mix is a composite of skills that match the patterns of the business intent. Because you need the intent to be bite-sized (i.e., can be turned into “done” solutions in 2 weeks or less), it is very likely that any particular piece of intent will suggest changes to 5 or less platforms / components. So, let’s say that you design our teams in the following patterns:

• Teams 1 and 2 possess a mix of skills in components A, B, C, and D
• Team 3 possesses a mix of skills in components C, D, E, and F
• Team 4 possesses a mix of skills in components A, B, C, and F
• Team 5 possesses a mix of skills in components A, D, E, and F
• Team 6 possesses a mix of skills in components B, C, D, and E

Because the pattern of business intent suggesting software changes in components A, B, C and D is more common, you can allocate 2 teams (Teams 1 and 2) that align their skills to this pattern of intent. The skills in Teams 3 through 6 match less common, but still often occurring, patterns of business intent. So, as a final step in the story splitting and grooming process, you need to steer the final stories towards the teams that have the needed skills to turn the story into a delivered solution. This certainly adds a level of complexity to the Product Owner’s role – matching story intent to team skill mix. It also implies that you may need to broaden out the breadth of Business Intent Generators (BIG’s) that feed into this pool of mixed-composite skill teams to be able to reasonably utilize their capacity. For example, if BIG 1 (see picture in the Ideal Team Structure article) requires 3 teams worth of capacity to get its expected level of solutions delivered, it might be difficult to construct 3 teams with the right mixtures of components A through F and keep them all well utilized. However, if BIG’s 1, 2, and 3 were to share their teams, they would combine to require 6 teams worth of capacity to get their solutions delivered. You then have significantly more flexibility to build the right team skill mixes across 6 different teams to marry up with how the patterns of intent are generated from these 3 BIG’s.

One very key point in constructing mixed-composite skill teams is that it provides the real opportunity for knowledge sharing and movement towards development of generalizing specialists (multi-skilled team members). For example, a developer on Team 3 who starts out with specializing in component C knowledge could readily work with other developers on the team to pair program and learn components E and F. Once that developer is now knowledgeable in all 3 of these components, they could be moved to Team 1 and provide the ability for that team to cover any story that involved change to components A through F. With leadership permission to broadly spend on knowledge sharing, you will have many teams that could handle any business intent that came their way. Before you know it, this organizational structure has transformed into the Ideal Team Structure.

So, if you can figure out what your patterns of business intent look like and then can build teams that fit those patterns, you will be blazing a trail towards 100% feature teams by starting with mixed-composite skill teams.

In the next and last article in this series, I will wrap up my thoughts on feature and component teams.

Previous article | Next article

© 2012-2013 AgileTrailblazers, LLC – All Rights Reserved

Seeing the World Through Agile-Colored Glasses

My article “Seeing the World Through Agile-Colored Glasses” got published on Scrum Alliance this morning. This is my take on trying to explain what agile really means. Thinking about agile as a lens for seeing the world, making decisions, and taking action. Take a look!