Haidt states that studies show that intergroup competition increases love of the in-group more than it increases dislike of the out-group. Intergroup competitions, such as friendly rivalries between divisions, or intramural sports competitions, should have a net positive effect on hivishness and social capital. But pitting individuals against each other for scarce resources (such as bonuses) will destroy hivishness, trust and morale. This aligns with the studies cited by Daniel Pink that monetary rewards reduce individual performance.

Since the principle includes the word “healthy” and there isn’t any clarification of this phrase we have to think about what would tip competition from healthy to unhealthy. I will expand the concept of intergroup competition to the idea of teams as individuals and if you pit teams against each other for scarce resources in the same way that you pit individuals against each other – you would destroy a large project team in the same way that you could destroy a small development or operations team. I would start with some idea of bragging rights as the reward that keeps competition in a healthy state. You have likely seen this as a character or mascot that is passed between teams as a visible indicatory that they have “bragging rights.” I have never seen pathological behaviour to obtain this type of reward, however I have seen it drive teams to greatness (or at least betterness). 

Very early in my consulting career I adopted a practice of stating my expectation that any team that I lead to be the “best team on the project.’  I always tailor that statement to each engagement, but the common practice is that I make this announcement and restate it regularly to establish “hive greatness” as a purpose. This shared purpose has consistently created a competition between my teams and others within an engagement completely unbeknown to the other teams. Since this purpose doesn’t come with any material reward and it is simple bragging rights it has stayed a healthy competition.

Reflecting on your team leadership, does your team see themselves in a competition with other teams? If they do, you likely have a high performing team and now you know why. If you don’t have a high performing team, maybe it is time to create a competition!

I had a recent experience leading an agile coaching team on a large digital transformation and will explore how I employed these 3 principles in taking the team from a group of chimps to a cooperative group of humans. That story is next in “How the IBM Coaching team activities align with the “Hive Switch” Principles. 

Previous blogs on this subject: Fool proof principals for building high performance teams, Exploring Principle #1 Build Similarity, not diversity, Exploring Principle #2 Move Together

The actual words Haidt uses in The Righteous Mind are “Exploit synchrony.” Since Leadership often gets the rap of being exploitive of members of a team, I avoided using that term and replaced it with the more positive “Move Together.” He states that “People that move together are saying ‘We are one, we are a team,…’” We can see this manifested in many facets of our daily life but let’s just look at the aspect of sports team fan membership. Chicago Cubs fans had the ritual of singing “Take me out to the Ballgame” with Harry Carey. This activity was as identified with being a Cubs fan as daylight only baseball. If you had ever been in the stadium for that ritual, the group bonding during that activity was palpable. The change in interactions between fans before and after were noticeably better. Singing Carmen Ohio at Ohio State football games is another example and I am certain this is a key element of other fandom memberships. An example of this applied to workplaces is the daily calisthenics at Toyota factories.

I know what you are thinking – calisthenics or stretching seems awkward to be part of the workplace routine. Agreed, so let’s think of some other activities within your workplace norms. I’ll start with one that is likely already happening – the team daily standup. Using this as a starting point you can now see the value in having all members of the team in attendance. Another example is the daily podcast “Coffee with Scott Adams” that I listen to. Scott begins with the Simultaneous Sip where he asks all listeners to take a sip of coffee or some beverage together. He freely shares that this is a bonding device, however it still has the effect of building comradery between him and the invisible participants. So maybe add a morning toast to the day at the start of every standup to add to the movement together. Another example of daily bonding school children starting their day with the Pledge of Allegiance. I started my first 6 years of school with daily prayers and the Pledge of Allegiance so I had some extra bonding, first as a member of the US community second as a member of the catholic community. Haidt also adds that marching, chanting, dancing, singing all work to bond the group. 

How can you increase bonding within groups that cannot meet everyday? Haidt suggests that activities that you don’t every day can be powerful if done occasionally. A Karaoke night once a month will still be a powerful activity to get the team moving together. You could invent some catchy fun ditty to chant or sing at the beginning of every team event, or just use “We are the champions” like 90% of sports teams. An activity that I have found very effective is a shared meal, the act of eating together seems to be an act of moving together as part of our common humanity. I have organized a weekly or biweekly event for teams that I have called “Get a life night.” This encourages the team to get outside of the workplace and engage in an activity together that ideally includes a shared meal. The mechanics are to create a schedule that has each member of the team to identify an activity for the team. The team is then under peer pressure to attend each event to ensure that their activity will also be attended. In this way the team begins to move together and they also are pushed to explore activities they would have avoided. No one bowls alone, but with a group, bowling is a great time. I have gone to karaoke, jazz clubs, toured cemeteries and historic districts, BBQ joints, dance lessons, comedy clubs, etc. 

Reflecting on your team leadership, is your team moving together? If they are, you likely have a high performing team and now you know why. If you don’t have a high performing team, maybe it is time to get them moving together!

Now let’s explore principle #3, Create healthy competition among teams.

Previous blogs on this subject are: Fool proof principals for building high performance teams and Exploring Principle #1 Build similarity, not diversity

Coming soon: How the IBM Coaching team activities align with the “Hive Switch” Principles

Wow, this is another revelation by Haidt that is swimming against the current within our culture! The actual statement is “Increase similarity, not diversity” which is a goal statement which I have changed to an action statement “Build…” Haidt elaborates “To make a human hive, you want to make everyone feel like family.” He describes a family as “having shared values and mutual interdependencies.“ Looking outside of families, this drive for similarity is striking when you observe any group of individuals that have created a club to separate themselves from a larger group. Visit a high school and you will be able to identify serveral groups that are self-identified as non-conformist by the uniform they have adopted– conforming to non-conforming appearance. The question for leaders is how to build similarity in a diverse workforce that you cannot (and should not) force thought, dress or appearance conformity. 

The great news is that our shared humanity is the foundation of our similarity. I was working in Canada in the mid 2000’s and had many discussions with my co-workers about the crazy American war mongering ethos. At the heart of these discussions was the belief that living south of the Canadian border changed a person into something unrecognizable in Canada. My reply to these types of statements was my observation of our vast similarities. Both Canadians and Americans wanted safety and security for themselves and their families. They both enjoyed good food and lively conversation. They both wanted to live long and prosper. These were vast similarities that would drown out the single difference, the stance on the Iraq war, that was the focus at the time. In many times I offered this observation, not once did any of my Canadian friends deny these basic truths. Back to the good news, as a leader you can use our basic humanity to drown out our differences. I still have friendships that I developed during my time in Canada and it was one of my early successes in building a human hive. This was just one of the many approaches that I employed to build that hive – it seemed intuitive, but good to know that it has some science behind it. 

So how do you focus on our shared humanity as part of our workplace? During a recent virtual training session we had a morning check-in where the participants displayed a favorite background picture with a short description. Three common themes emerged during the session. The first one was a love of sports, even when the participants were fans of different teams the similarity was that they were sports fans. The second theme was a love of family, with multiple participants showing a photo of their children they showed a humanity that most of us share. A third theme was a love of beach vacations with a third of the class showing a picture of a favorite vacation. My modest role in these sessions is to demonstrate the check-in themes during the first day of training avoiding any reference to work, training and avoiding any humble brags. During the check-ins I comment on the similarity between interests either between the students or between the students and the instructors. The photo check-in was the start of day 2 of the 4 day training that was followed by a favorite t-shirt and favorite hat check-in on day 3 and 4. What we witnessed was growing cross talk and engagement in the main session and group break outs. In our instructor retrospective we noted that this was one of the most active and engaged training groups. In summary, share your humanity (no need to act like a fool) and invite your team to share theirs. 

Shared humanity seems easy now, what would seem to be the easy part is really tricky – how do you bring in work? Managers have been sharing the work and plan with teams for a very long time without moving the hive switch. This is where we need to leave management behind and become leaders.  Avoid the actual work your team is engaged in and bring in “purpose.” One of the dimensions of Mazlow’s work was the need for individuals to have purpose in their life to become the best version of themselves. I will apply this to a human hive to say that a common purpose for the hive is a critical dimension to become the best version of the hive. As I was building my first agile team we had the good fortune of having a great Product Owner (PO). Dave was very active in all of our team events and could describe the impact our work (or lack of) was having on the users of the solution we were supporting. The engagement of the PO came with the conversion to agile methods which was impactful, but the alignment around the common purpose to make the system user friendly was a large part of our success. 

Is purpose the same as mission? I won’t try to tease out the distinction between these two concepts because many could argue that what I described above was a team mission. So, describing the mission of the team in a motivating manner will result in giving the team purpose. The goal is to provide the team with something they can share in common to connect with each other in a meaningful way. In What we know about Leadership Hogan and Keiser stated it this way “…good leaders are able to project a vision, to explain to the group the purpose, meaning, and significance of its key undertakings.” One other interesting point from What we know about Leadership Hogan and Keiser is the distinction between leadership competency and managerial competency. Leaders have to have this vision thing but a vision alone isn’t going to move the hive switch. Leaders must be competent managers to be credible leaders to their followers, however effective managers without leadership skills will not build high performing teams. 

Reflecting on your team leadership, what are you doing to foster a common bond within your team? If you are doing this, you likely have a high performing team and now you know why. If you don’t have a high performing team, maybe it is time to drown their differences in a sea of similarities!

Now let’s explore principle #2, move together and principle #3 Create Healthy competition among teams

Previous blog: Fool Proof principals for building high performance teams. 

Coming soon: How the IBM Coaching team activities align with the “Hive Switch” Principles

Let’s be honest, we all know that the key to success for any leader is the performance of the team. As leader I consumed many articles and books on building a high performing team, they all offered great advice on what to do or what not to do. In my attempts to follow, I would tailor them to my situation, sometimes creating other activities that felt right. A lot of what I tailored and created worked, some of the things didn’t work or worked for one team and not the next. Following this approach the past 20+ years I have had many successes, but it was never fool proof. I was confident in my ability to build a high performing team but could not distill my successes into something tangible that I could offer other leaders as guiding principles. An example of this challenge was a recent webinar describing a rewarding experience leading an agile coaching team. As I was detailing the approach and specific activities that I used to build team cohesion, I realized that anyone attending wouldn’t know if these activities lead to the success of the team or if was just a happy coincidence. 

Coincidentally, I happened upon a pot of gold in “The Righteous Mind” by Jonathan Haidt. Most folks recognize this book as a way to understand why we are so politically divided and how we can bridge the chasm we are experiencing. Halfway through the book in the chapter “The Hive Switch” I found what had always been missing in all of those team building articles and books – 3 principles to build a high performing team. Haidt calls high performing groups  “Super organisms” in that they are more productive than the sum of the individuals. The “Hive” concept is an analogy between human super organisms and a bee hive as a super organism. 

An important distinction is that humans tend to act individually even as we are a member of a group. However, with the right activities we can have our “hive switch” turned on to become part of a super organism – A HIGH PERFORMING TEAM. In sociology terms this is called a “cooperative group of individuals”, upon reading this I realized that this describes the higher value every leader should be trying to obtain. As noted earlier, the complication for human leaders is that we are not bees. Unlike the queen bee in the hive, the leader of the human hive cannot just let nature take its course, there is a conditional nature of human “hivishness.” An anthropologist once remarked that you would never see two chimps carrying a log. Chimps don’t cooperate, they always act as individuals in a group and can only accomplish what an individual chimp is capable of. Humans tend to act like chimps unless we have our “hive switch” turned on, that is why as leaders we consume those leadership books. That is also why leadership is critical to forming a cooperative group of individuals – a super organism.

Haidt identified the three principles of building a human hive¹ I will call them the “Hive Switch Principles” going forward. 

1. Increase similarity, not diversity. Make everyone feel like a family. 
2. Exploit synchrony. People who move together are saying “We are one, we are team…”
3. Create healthy competition among teams, not individuals. Studies show that intergroup competition increases love of the in-group far more than it increases dislike of the out-group

Interesting right, but you may be asking – why are principles important when every possible thought about team forming, storming, norming and performing has been written down and available?” Good question – since my introduction to the Agile Manifesto and SAFe (Scaled Agile Framework) I have developed a real appreciation for a set of principles that guide you to the attainment of what you value. What we value as leaders is a cooperative group of individuals, a super organism that outperforms the sum of the individuals in the group. 

One last thought on leadership models – the 3 Hive Switch principles for building high performing teams isn’t about leadership. Haidt points out that these principles are about creating “followship”, what makes a group of individuals bond together to follow a leader. This is important because the leader is placed in a Servant Leader model and completely removes the idea of MANAGING a high performing team. By adopting the leadership approach to building a human hive you are going to be focused on how you can serve the hive, help move the Hive Switch to the “On” position rather than expecting the hive to appear to serve you. Any bee keeper will tell you that hives are delicate organisms that must be carefully nurtured to survive. 

Reflecting on your team leadership approach, are you building similarity? Is you helping your team move together? Have you created a HEALTHY team competition with other teams? If you are helping create these things you likely have a high performing team and now you know why. If you don’t have a high performing team, maybe it is time to reflect on the alignment with the Hive Switch Principles and adjust. 

In the following blogs I will explore each of the Hive Switch principles in detail followed by the activities that we adopted as we were building the coaching team and reflect on how they were aligned with these Hive Switch Principles.

SAFe has updated the LPM Competency and LPM Configuration practices based on the continued maturity of LPM. I have reviewed the updates and have pulled the changes together as they align to the 3 LPM Collaborations which aligns to the organization of the SAFe course delivery. These are nice improvements and align with the real world which will remove some friction from adopting Lean Portfolio Mgmt practices.

• Strategic Portfolio Review
• Portfolio Sync

Lean Governance

• Expanded description of Participatory Budgeting to align with Epics
• Forecasting an Epic’s duration using ranged estimates
• Improved the treatment of KPIs
• Portfolio Roadmap update

Let’s dig into the details of the change at the next level. Starting with Strategy and Investment funding:

Definition of an MVP for a SAFe Epic – Defining the Epic MVP Analysis of an epic includes the definition of a Minimum Viable Product (MVP) for the epic. In the context of SAFe, an MVP is an early and minimal version of a new product or business solution that is used to prove or disprove the epic hypothesis. As opposed to story boards, prototypes, mockups, wire frames and other exploratory techniques, the MVP is an actual product that can be used by real customers to generate validated learning.

Estimating Epic Implementation costs initially in T-shirt sizes – This technique is used to more easily prepare for Participatory Budgeting, which uses real costs, not story point estimates, to establish the value stream budget. A cost range is established for each T-shirt size using historical data. The gaps in the cost ranges reflect the uncertainty of estimates. Each portfolio must determine the relevant cost range for the T-shirt sizes.

Revised Lean Business Case new cost nuances – The MVP cost ensures the portfolio is budgeting enough money to prove/disprove the Epic hypothesis and helps ensure that LPM is making investments in innovation in accordance with lean budget guardrails. The forecasted implementation cost factors into ROI analysis, help determine if the business case is sound, and helps the LPM team prepare for potential adjustments to value stream budgets

Simplified Budget Horizon treatment – Budget Horizon discussion is reduced to a single graphic with Horizons 3 – 0 from left to right including the solution investments. The discussion of the 3 investment horizons running from Horizon 1 to Horizon 3 is removed from the Lean Budget article. 

Agile Portfolio Operations updates are focussed on the Portfolio Sync

Strategic Portfolio Review – The Strategic Portfolio Review is the key LPM event designed to foster continuous strategy, implementation and budget alignment. The focus is on assuring that investments are continually aligned with strategic themes and communicating any emerging guidance needed to inform rapid, quality, decentralized Value Streams decisions. The event is oriented primarily around reviewing MVPs and Epics as they work their way through the Kanban system and make their way to implementation. New epics are discussed as they arise. Epic Kanban state changes are discussed and approved. In order to enable value streams to prepare and respond to any changes, it is typically conducted approximately quarterly, at least one month before the next PI Planning meeting

Portfolio Sync – The Portfolio Sync is an LPM event designed to gain visibility into how well the portfolio is progressing toward meeting its objectives. This meeting has a more operational focus than the strategic portfolio review.  Topics typically include reviewing epic implementation, status of KPIs, addressing dependencies, and removing impediments. The portfolio sync is typically held monthly and may be replaced on a given month with the strategic portfolio review.

Lean Governance updates touch four distinct areas of this competency

Participatory Budgeting – The change to this section consumes the updates on Epic Costing for a natural connection to Participatory Budgeting. In the previous here was significant friction with Epic estimating in story points and most budgeting mechanism in monetary terms (dollars, euros, etc.) This is a significant adjustment and aligns with the reality of most portfolios to understand their value stream funding and their biggest initiatives in currency.

Forecasting Epic’s – This removes one of the stumbling blocks to forecasting Epic implementation duration by providing a size range to acknowledge estimating is imperfect. The graphics reflect this adjustment in both the Portfolio article and the LPM 5.0.1 course material.

Improved KPI treatment – The organizational structure of proposed Portfolio Measures has been updated to Measure, Metric Used, Desired Result. The list of proposed KPIs starts with the measure of performance against the “Key Results” of the Portfolio OKRs. This is followed by a list of proven measures to begin a discussion on the right set of KPIs for the Portfolio.

Portfolio Roadmap – The new roadmap article and graphics provide better treatment of the connection between the multiple configurations of SAFe (Essential, Large Solution and Portfolio.) This will assist with implementation discussions to resolve some of the leaps of logic that were required and ofter resulted in significant disagreements within change agents.

Links and Action

Since this is intended to pull out the updates and not a discussion of these in the context of the larger LPM Competency and Portfolio Configuration I am providing these quick links to the articles that contain this information in context.

Lean Portfolio Management

Roadmap

Epic

SAFe has updated the LPM course and activities to align with the LPM article content. All of the updates reflect a maturity of the LPM Competency and the LPM practices. I have completed the course instructor validation and have updated the course activity templates in Mural to align with the course updates.

Follow this LINK to the November course information. https://www.visiontemenos.com/events/digital/est/safe5.0-lean-portfolio-management-with-lpm-certification-9nov-2020

In discussing the application of the SAFe Large Solution with other transformation coaches, I have realized that when a large organization is implementing SAFe for a significant transformation it is challenging to determine the boundaries of the Large Solution from the functions of the Lean Portfolio and Agile PMO. For a well functioning SAFe transformation this distinction is critical to align with the SAFe House of Lean as well as the 10 SAFe Principles. 

Large Solution boundary guidance

My experience indicates that the overhead (or tax) of the Large Solution should only be paid if it is solving a solution delivery issue. The issue should be limited to: 1) Dependencies within an Epic 2) Supplier co-ordination. This sounds simplistic, however the costs of the Large Solution should be reserved for these limited applications.

In order to illuminate the need to draw these boundaries it is helpful to the identify and describe the costs of the Large Solution in terms of specific costs in new roles, Large Solution events and additional costs on the ARTs within the Large Solution. The additional roles are the Solution Architecture, Solution Management and Solution Train Engineer that if filled properly will consume at minimum three senior members of the organization and could be many more. The responsibilities of creating Solution Architecture and Solution Backlog to provide PI Planning guidance and participation in PI execution with the aligned ARTS demands full time engagement of the Solution level roles. This additional engagement with the aligned ARTs places additional demands on the ART leadership roles (System Architect, Product Management, and RTE.)  Paradoxically, the better defined the Large Solution the fewer individuals will be required in Solution level roles, the less time will be required to complete the Solution Activities and the fewer distractions to the aligned ARTs.

The issues/challenges that should not drive ARTs being included into a Large Solution are 1) Common Architectural guidance, 2) ARTs aligned to the same Operational Value Stream, 3) Portfolio Funding, 4) common strategic theme, 5) planned future integration… 

Need for Solution Intent does not indicate Large Solution!

Early in a recent engagement, I was completing a Leading SAFe course and a participant and leader of the group I was coaching announced that “We are a Large Solution because we need to implement Solution Intent.” This comment was insightful to their experience with agile development and the recognition that the Architecture and Systems Engineering components of SAFe Solution Intent were missing from their previous experience. This highlights a common mistake of taking the appearance of Solution Intent on the Large Solution level of the SAFe configuration as a directive for Large Solution. Your SAFe transformation may require the goodness of the Solution intent for Portfolio or Essential configurations as well. What this is intended to convey is that if you meet the criteria of a Large Solution boundary guidance you will need the Solution Intent construct. However, many SAFe transformations require Solution Intent to support the alignment of multiple ARTs around a common architectural guidance. 

How Lean Portfolio Management fills the gaps better

Starting with the set of issues/challenges identified as reasons for NOT implementing the Large Solution: 1) Common Architectural guidance, 2) ARTs aligned to the same Operational Value Stream, 3) Portfolio Funding, 4) common strategic theme, 5) planned future integration… I will elaborate on how the LPM activities would better address these issues/challenges. 

1. Common Architectural Guidance – Enterprise Architecture is a key role in multiple functions of LPM and is described an important contributor the Architecture and Design artifacts of Solution Intent. Placing this responsibility with the EA role will both enhance EA engagement but also provide a more consistent application of the architectural guidance. 
2. ARTs aligned to the same Operational Value Stream – The cadence and synchronization functions of Portfolio Operations describe specifically the activities and responsibilities for this scenario. 
3. Portfolio Funding – With portfolio funding (Strategy and Investment Funding) should come Lean Governance functions of the LPM. To use the Large Solution to address the gaps in either of these LPM functions is not going to filly resolve the gaps while creating addition issues with current ART execution.
4. Common Strategic Theme and 5) Planned Future Integration – These have the same answer in the creation of a robust Solution Intent model (see other blog poses on Solution Intent.) A robust Solution Intent model would be better described as an “Enterprise Intent” with the inclusion of Strategy, Strategic Themes (OKRs), Portfolio Vision in the Solution Intent. These Enterprise/Portfolio level artifacts along with NFRs would have alignment of all levels of the architecture would better resolve this challenge. 

Let’s take Solution Intent to the Enterprise level!

From the view of Enterprise Architecture, an enterprise domain model connects the Enterprise Strategy and Enterprise Key Resources with Portfolio execution. The Enterprise Intent consists of a set of artifacts that are created and validated as the Enterprise Strategy is executed. With the creation of an Enterprise Intent, architects (Solution & System) in each portfolio can be guided and constrained by these artifacts.

Why can’t we just use Solution Intent and extend it up to the Enterprise? The reason for using a new term of Enterprise Intent is the term “Solution” seems confining the description of business solutions delivered by Development Value Streams that does not address the SAFe 5.0 turn towards Business Agility. To align the Enterprise Strategy and Lean Portfolio Management to the goal of Business Agility the artifacts that guide the Portfolio and Business Operations “Why it is being built” should be contained in the same structure as the Solution description artifacts that contain “what is being built” as well as “how it will be built.”

The alignment of Solution Intent to the Large Solution configuration confines the application to the large/complex system descriptions. While I will agree that a large/complex system requires the Solution Intent construct I will argue that the alignment of the Portfolio “what to build” is equally important for all SAFe Configurations and should be implemented in some form in all SAFe adoptions. 

Enterprise Intent Domain Model

The Enterprise Intent domain model is based on SAFe guidelines and Model-Based System Engineering practice. This domain model will be used as a guide for all discussions on artifacts created for the SAFe Portfolio, Large Solution and/or Agile Release Trains.

The Enterprise Intent domain model contains

• Enterprise Specification Artifacts
• Architecture and Systems Engineering Artifacts
• Lean-Agile Artifacts
• Verification and Validation Artifacts

The Solution Intent Domain Model consists of the four domains with three primary relationships. All of these will be described in detail in the following sections. 

• The Enterprise/System Specification artifacts will drive the creation and update of Architecture & Design artifacts.
• The Lean-Agile artifacts are created to implement the System Specifications in alignment with the Architecture and Design artifacts. 
• The Verification and Validation artifacts are created to validate the System Specifications as they are implemented by the Lean-Agile artifacts. 

How to get started with an Enterprise Intent Model

Approaching this as an agile delivery model there should be a recognition that this is not a big upfront design that would hold up ongoing development activities, but rather an evolutionary process that could first recognition how current artifacts fall into the four domains and the relationships. Follow on steps would be to identify missing artifacts or redundant/unnecessary artifacts. From an Enterprise Intent view the most likely missing artifacts are the Portfolio level artifacts tying the solution development to Enterprise Strategy and OKRs. 

The initial step of reconciling the current artifacts should be non-threatening by recognizing these facts. 

• It consists of familiar artifacts: Enterprise Intent is a living collection of artifacts, documents, models, backlogs, and related materials that describe the current and future business functions that support the SAFe Portfolio’s Value Streams
• Get started with what you have:  The Enterprise Intent should start with the set of artifacts that describe the current systems that may consist of system requirements, use case, various types of models, architecture specifications, and other documents and consider any missing constructs as Enterprise Intent Technical Debt
• It is in a constant state of change: With the need to update the Enterprise Strategy, OKRs, Portfolio Vision and the delivery of new or changed business functions and address system technical debt the Enterprise Intent will be continuously updated as the Development Value Streams are moving new functionality through the Continuous Delivery Pipeline

I was completing a self-retrospective after delivering the SAFe Lean Portfolio Management course and part of that was the satisfaction I felt that the students had obtained the LPM Competency with the wealth of information and a set of practices and techniques to implement LPM. I then turned my attention to preparations to deliver SAFe for Architects (S4Arch). With Enterprise Architect role as a significant course component of S4Arch, I realized there was not a clear view of how the artifacts in LPM would be used as the Enterprise, Solution and System architects perform their roles.

How would those LPM students use their new knowledge to interact with the enterprises/organizations they were returning to? Taking this a step further, I wondered how I would connect these two courses if a participant took both courses? 

This problem took me back to a recent engagement where the creation of a Solution Intent Concept of Operations was needed to move the understanding of Solution Intent from concept to operational model.  To describe a Concept of Operations for the SAFe Solution Intent we have to start with some foundation – a Domain Model. The Solution Intent domain model I am using is adopted from IBM ELM tools that is based on SAFe guidelines and Model-Based System Engineering practices. This domain model will be used as a guide for the all artifacts created for the SAFe Portfolio, Large Solution and/or Agile Release Trains.

The Solution Intent domain model contains

• System Specification Artifacts
• Architecture and Systems Engineering Artifacts
• Lean-Agile Artifacts
• Verification and Validation Artifacts
• Relationships between these artifacts between the desired state and the known current set of artifacts and practices. 

The Solution Intent Domain Model consists of the four domains with three primary relationships. All of these will be described in detail in the following sections. The System Specification artifacts will drive the creation and update of Architecture & Design artifacts. The Lean-Agile artifacts are created to implement the System Specifications in alignment with the Architecture and Design artifacts. The Verification and Validation artifacts are created to validate the System Specifications as they are implemented by the Lean-Agile artifacts. 

Another aspect of the domain model is how they act while the Solution Intent is progressing from Variable to Fixed and representing Current state and Future State of the Solution. We need to reconcile these sets. To do so, we note the following:

• The Enterprise Specifications, Design and Architecture and Validation Artifacts are persistent artifacts. These artifacts delivery system compliance requirements. 
• The lean-agile artifacts are transient, in that they are created to describe the work that moves the Solution Intent from Variable to Fixed and move the Solution from the Future state to the Current state. 

With those foundational concepts I will move onto the question of LPM artifacts in the Solution Intent. As a thought exercise, we will begin with the Lean Portfolio artifacts and Portfolio Epics in the Portfolio Kanban Funnel – and thread up through various artifacts, and how follow-on artifacts and concurrent artifacts arise. Along the way, we will uncover a “Definition of Ready” that encompasses both the Lean-Agile and the System Specification artifacts.

First, I will start with the allocation of the artifacts that were generated in the Strategy and Investment exercises (Lesson 3) that form the basis of how a Portfolio will generate value/profits for the enterprise. The result is a set of Epics that are identified and in the Funnel state of the Portfolio Kanban. The key used in all future graphics will be new artifacts identified in RED.

A notation that Enterprise Architects will already be engaged at this point with identification of missing architecture elements in the Solution Vision and the necessary Enabler Epics. 

The following slide show demonstrates how artifacts are created and matured through the Portfolio Kanban stages of a SINGLE EPIC resulting in the movement from a Future State vision to a Current State that supports the Enterprise Strategy through Strategic Themes (OKRs.) This is a representative set of artifacts to communicate the process with the specifics to be determined for each Portfolio. A single enterprise may have different compliance requirements in each portfolio which would drive differences in each Solution Intent. 

I will highlight the Done State for the Epic – the Lean-Agile Artifacts are Closed and have been removed as they are no longer relevant. The Enterprise Specification, Design and Architecture and Verification/Validation artifacts representing the Current Solution Intent.

I am requesting your thoughts and questions to mature and refine this ConOps as well as your interest in other aspects to elaborate in future blogs.