Skip to content

We are Alive!

August 11, 2014

I love Robin Williams! Not merely for what he did as an artist (actor, comedian, etc.), but for the quintessential truth he endlessly echoed in everything he did — We are Alive! He fully embraced the mystery called life through caring, being aware, expressing appreciation (for the bad, the good, the happy, the sad, etc.), being so intuitive and improvising in every situation, …, so free!

Reminded of David Foster Wallace

The really important kind of freedom involves attention, and awareness, and discipline, and effort, and being able truly to care about other people and to sacrifice for them, over and over, in myriad petty little unsexy ways, every day.

And as Robin Williams struggled with his own daemons — as much as we each struggle with our own daemons — he and his whole life were cathartic to/for others…

You’re only given a little spark of madness. You mustn’t lose it.
(Robin Williams)

Thank You dear Soul for reminding us each of our own little “spark”!

What will your verse be?

Seize the day!

Real lose… love somethign more than you love yourself!

When did you know? … I don’t regret…

His wife, Susan Schneider…

This morning, I lost my husband and my best friend, while the world lost one of its most beloved artists and beautiful human beings. I am utterly heartbroken. On behalf of Robin’s family, we are asking for privacy during our time of profound grief. As he is remembered, it is our hope the focus will not be on Robin’s death, but on the countless moments of joy and laughter he gave to millions.

The White House…

Robin Williams was an airman, a doctor, a genie, a nanny, a president, a professor, a bangarang Peter Pan, and everything in between. But he was one of a kind. He arrived in our lives as an alien – but he ended up touching every element of the human spirit. He made us laugh. He made us cry. He gave his immeasurable talent freely and generously to those who needed it most – from our troops stationed abroad to the marginalized on our own streets. The Obama family offers our condolences to Robin’s family, his friends, and everyone who found their voice and their verse thanks to Robin Williams.

The Scaled Agile Framework (SAFe) Distilled

July 5, 2014

The Essential Scaled Agile Framework (eSAFe) focused on the SAFe and the Dual-Track Value Co-Creation metaphor, and then introduced the eSAFe — SAFe through the Dual-Track Value Co-Creation metaphor. Many people in the Agile community struggle when discussing Scale and introducing concepts from the SAFe because they naturally delve into an exhaustive exploration of the SAFe’s nuances. Herein is a way to distill the SAFe by focusing on an Overview, Foundation, and Detail.

Overview. The Scaled Agile Framework (SAFe) is a “proven knowledge base for implementing agile practices at enterprise scale.” The SAFe identifies roles, teams, activities, and artifacts for scaling agile practices from the team, to teams of teams, to the enterprise level.

Foundation. Agile is an umbrella term for various techniques, practices, methods, and frameworks with roots in Agility. Agility (or more specifically, Boydian Agility) is a value system (mindset) that emphasizes people, results, collaboration, and responsiveness, which fosters the “ability to be agile”.

Detail. The SAFe organizes roles, teams, activities, and artifacts into three levels of scale: Team, Program, and Portfolio. The SAFe describes these three levels of scale using three essential dimensions: Value, Team, and Timebox.

Portfolio Level. At this level of scale, focus on aligning programs with the enterprise business strategy. Programs organize around a portfolio backlog of initiatives (Epics) and around long-lived Value Streams (flows of value).

Program Level. At this level of scale, focus on aligning teams within a program. A long-lived team-of-teams organizes around a program backlog of work (Features) and executes (cadence and synchronization) in Program Increments (PIs) to contribute value to a portfolio — the essence of the SAFe’s Program Level involves a team-of-teams (ART) contributing value (Features) against Portfolio Level initiatives (Epics) and value creation (Value Streams).

Team Level. At this level of scale, focus on teams delivering value within a program. Stable teams organize around team backlogs of work (Stories) and execute in Iterations (cadence) to contribute value to a program — the essence of the SAFe’s Team Level involves teams (Agile Teams) contributing value (Stories) within a Program Level team-of-teams (ART) contributing value (Features) against Portfolio Level initiatives (Epics) and value creation (Value Streams).

Summary. The table below summarizes the three levels and their various aspects: Team, Timebox, Value, Value-Orientation, Business Roles, “Balance” Roles, and Technology Roles. To instantiate the SAFe in our enterprise and business context, consider the various aspects at each level.

eSAFe-Summary-20140705-00

Business. Who best represents the business perspective and is a subject-matter-expert (SME) about value? At the Portfolio Level, this is perhaps a portfolio manager or product-line manager. At the Program Level, this is perhaps a program manager or product manager. And at the Team Level, this is perhaps a product owner or analyst. The key is having a value orientation and being a SME about the business.

Technology. Who best represents the technology perspective and is a SME about technology? At the Portfolio Level, this is commonly an enterprise architect (perhaps working with a business enterprise architect). At the Program Level, this is perhaps a system architect. And at the Team Level, this is perhaps the developers and testers who build and ensure quality. The key is having a technology orientation and being a SME about the technology options to meet business goals and objectives.

Integration and Execution. How are business and technology perspectives integrated? How do the integrated perspectives execute? Integrated business and technology teams that operate on a rhythmic cadence and synchronize with other integrated teams gives the whole enterprise its integrity. Otherwise, things become far too messy (or complex) to achieve a return on adopting, scaling, and sustain agility!

Balance. When different perspectives are integrated, we naturally experience conflict in the form of tension or friction. How is conflict handled and how are tensions or friction catalyzed towards a win-win for all? A coach can help facilitate a healthy resolution. At the Team Level, a scrum master or project manager may be the coach. At the Program level, a program-level scrum master or program manager may be the coach. And at the Portfolio Level, a director or other organizational executive may be the coach. The key is having someone who can help facilitate resolution.

Again, this is one way of introducing concepts from the SAFe without having to delve into exhaustive exploration of the SAFe’s nuances. Would love to hear your thoughts.

The Essential Scaled Agile Framework (eSAFe)

July 5, 2014

The Scaled Agile Framework (SAFe) is a “proven knowledge base for implementing agile practices at enterprise scale.” The SAFe identifies roles, teams, activities, and artifacts for scaling agile practices from the team, to teams of teams, to the enterprise level.

While some people champion the SAFe, other people criticize the SAFE — yet one common question emerges: What is the essence (a distillation) of the SAFe? Please see the Scaled Agile Framework for a more exhaustive exploration of the SAFe’s nuances.

Agile is an umbrella term for various techniques, practices, methods, and frameworks with roots in Agility. Agility (or more specifically, Boydian Agility) is a value system (mindset) that emphasizes people, results, collaboration, and responsiveness, which fosters the “ability to be agile”. Given the origins of Agile, there is much debate regarding scaling Agile.

The SAFe

The SAFe organizes roles, teams, activities, and artifacts into three levels. The core values of the SAFe are Alignment, Quality, Transparency, and Execution. The foundation of the SAFe is expressed in its “House of Lean”: Value (The Goal), Respect for People, Continuous Improvement, Flow, Management/Lean-Agile Leaders (The Foundation).

Levels

The three levels of the SAFe are:

  • Portfolio Level: Level of scale focused on aligning programs with the enterprise business strategy.
  • Program Level: Level of scale focused on aligning teams within a program.
  • Team Level: Level of scale focused on teams delivering value within a program.

Portfolio Level

Programs organize around a portfolio backlog of initiatives (Epics) and around long-lived Value Streams (flows of value).

eSAFe-Portfolio-20140704-00

The Portfolio Level of the SAFe includes the following artifacts:

  • Portfolio Vision: A highest-level solution definition. A System is a Solution to a Problem.
  • Strategic Theme: A business objective that connects a Portfolio Vision to the enterprise business strategy.
  • Budget: An investment in an Agile Release Train (ART).
  • Epic: An enterprise initiative. A Portfolio Epic relates to multiple ARTs. A Program Epic relates to a single ART. An Epic spans Program Increments (PIs).
  • Business Epic: A business initiative, generally focused on value.
  • Business Epic Kanban: Captures the evolution of Business Epics, generally under the auspices of Program Portfolio Management (Business Owners and executives).
  • Architectural Epic: A technology initiative, generally focused on a solution.
  • Architectural Epic Kanban: Captures the evolution of Architectural Epics, generally under the auspices of the technology office (Enterprise Architect and System Architect).
  • Portfolio Backlog: Prioritized Epics (and NFRs) as a holistic portfolio solution for achieving business success.
  • Nonfunctional Requirement (NFR): A System quality (attribute) or a constraint (restriction).

The Portfolio Level of the SAFe includes the following roles and teams:

  • Business Epic Owner: A steward of Business Epics through the Business Epic Kanban, who also works with ARTs to realize their business benefits.
  • Enterprise Architect: A steward of Architectural Epics through the Architectural Epic Kanban, who also works with ARTs to realize their technology benefits.
  • Program Portfolio Management: The steward of the Portfolio Vision, responsible for investment funding, program management, and governance.

The Portfolio Level of the SAFe includes the following activities:

  • Value Stream: A long-lived flow (process) of value.
  • Agile Release Train (ART): A solution-based long-lived team-of-teams (virtual organization) to realize value in a values stream.

The essence of the SAFe’s Portfolio Level involves initiatives (Epics) focused on value creation (Value Streams).

Program Level

A long-lived team-of-teams organizes around a program backlog of work (Features) and executes (cadence and synchronization) in Program Increments (PIs) to contribute value to a portfolio.

eSAFe-Program-20140704-00

The Program Level of the SAFe includes the following artifacts:

  • Program Vision: The stakeholders’ view of the solution (Needs and Features).
  • Program Roadmap: The intended evolution of the solution over time (PIs).
  • Program Backlog: Prioritized Features (and NFRs) for advancing an ART’s solution.
  • Feature: A behavior of a System that fulfills one or more user needs. A Feature fits in a PI.
  • Business Feature: A business system service that fulfills one or more user needs.
  • Architectural Feature: A technical system service that is foundational to implement Business Features.
  • Architectural Runway: Technological architecture.
  • Program PI Objectives: An ART’s business and technical goals for a PI.

The Program Level of the SAFe includes the following roles and teams:

  • Business Owner: Responsible for value delivered by an ART.
  • Product Management: Responsible for the Vision, Roadmap, and Program Backlog.
  • System Team: Responsible for the technology environment, and integrating Components into a System.
  • Release Management: Responsible for releasing/launching a System.
  • Shared Resources: Responsible for contributing specialized expertise not on an Agile Team.
  • DevOps: Responsible for deploying a System across technology environments (especially Staging and Production).
  • User Experience (UX): Responsible for contributing user experience guidance.
  • System Architect: Responsible for the architecture of a System.
  • Release Train Engineer (RTE): Responsible for program (ART) execution.

The Program Level of the SAFe includes the following activities:

  • Program Increment (PI): A time-box in which an ART delivers an increment of value, with routine synchronization. Within an ART, PIs are sequential.
  • Release Planning: An ART’s consideration of the work and commitment to a PI.
  • System Demo: An ART’s demonstration of progress.
  • Inspect & Adapt: An ART’s reflection on its execution with a focus on continuous improvement.

The essence of the SAFe’s Program Level involves a team-of-teams (ART) contributing value (Features) against Portfolio Level initiatives (Epics) and value creation (Value Streams).

Team Level

Stable teams organize around team backlogs of work (Stories) and execute in Iterations (cadence) to contribute value to a program.

eSAFe-Team-20140704-00

The Team Level of the SAFe includes the following artifacts:

  • Team Backlog: Prioritized Stories (and NFRs) for advancing an Agile Team’s portion of an ART’s solution.
  • Story: A small and simple chunk of value representing an intended System behavior (User Story) or other type of work (Technical Story). A Story fits in an Iteration (Sprint).
  • Spike: A type of Story used to gain knowledge.
  • Refactor: A type of Story used for improving a System without changing the behavior of the System.
  • Task: An action required to deliver a Story. A Story commonly requires many Tasks to complete.
  • Component: A part of a System that implements one or more Features.
  • Team PI Objectives: An Agile Team’s business and technical goals for a PI.
  • Sprint Goal: An Agile Team’s business and technical goals for an Iteration/Sprint.

The Team Level of the SAFe includes the following roles and teams:

  • Agile Team: Atomic unit (Product Owner, Scrum/Agile Master, Developers, and Testers) that contributes (defines, builds, and tests) to a single ART.
  • Product Owner: Responsible for the Team Backlog.
  • Developer: Responsible for developing Components and doing other work.
  • Tester: Responsible for testing Components.
  • Scrum/Agile Master: Responsible for helping a self-organizing and self-managing cross-functional Agile Team achieve its goals.

The Team Level of the SAFe includes the following activities:

  • Iteration: A time-box in which an Agile Team delivers an increment of value, with routine synchronization. For a team, Iterations are sequential.
  • Iteration Planning: An Agile Team’s consideration of the work and commitment to the Iteration/Sprint.
  • Team Demo: An Agile Team’s demonstration of progress.
  • Iteration Retrospective: An Agile Team’s reflection on its execution with a focus on continuous improvement.
  • Innovation | Planning (IP) Iteration: A time-box for program-level planning and team-level innovation.

The essence of the SAFe’s Team Level involves teams (Agile Teams) contributing value (Stories) within a Program Level team-of-teams (ART) contributing value (Features) against Portfolio Level initiatives (Epics) and value creation (Value Streams).

Dual-Track Value Co-Creation

My transformation work with clients to adopt, scale, and sustain Agility pre-dates — but is fully consistent, aligned with, and goes beyond — the SAFe and is rooted in a Dual-Track Value Co-Creation metaphor or pattern. This is not an abstract or theoretical pattern, but an empirically derived pattern that guides practice — a few case studies include Cars.com and AutoVIN. two public case studies. Also, please see Scaling Agility with Conscious Agility & SAFe, DAD, LeSS, Agility Path, or ScrumPLoP for more information.

The Dual-Track Value Co-Creation metaphor, which is called a Framework when implemented for a specific enterprise, embraces the worldview that any enterprise focuses on generating Value (the ends) through its parallel Co-Creation efforts (the means) of Discovery and Delivery.

eSAFe-DTVCC-20140704-00

Discovery involves an ongoing or continuous effort to discover what is of value. Delivery involves an ongoing or continuous effort to deliver value. An enterprise’s Discovery and Delivery efforts (team and team-of-teams) are parallel paths bound by an enterprise’s Strategy and Infrastructure. The actual “form” of value is based on the enterprise and its business context, which may include products, services, experiences, result, etc. offered to users, customers, stakeholders, etc.

The metaphor is founded on the notion of Value and Co-Creation as well as Discovery (discover what is of value) and Delivery (deliver value) — fully rooted in human dynamics/nature (commitment, authority, accountability, etc.). The actual elements of an enterprise-specific Framework are derived from various bodies of experience (BoEs) or bodies of knowledge (BoKs) that are relevant to the enterprise and its business context. All elements within the Framework are integrated based on the dynamics among the people who constitute the enterprise.

Cycles

Discovery may be organized into continuous cycles that charter Delivery cycles, generally guided by a vision, roadmap, and business case. Delivery may be organized into continuous cycles that deliver value. The integration points between Discovery paths and Delivery paths is dynamic and generally focuses on fostering observations, orientation, decisions, and action. These four elements are the pillars of Boydian Agility.

Each cycle is an effort from beginning to end as a sequence of time-boxed periods (plan, execute, demonstrate, retrospect) wherein work is done and a result is incrementally evolved. The first time-box may be used to open a cycle, followed by any number of time-boxes to incrementally evolve the result, and a final time-box may be used to close the cycle.

The specifics of the first/open and final/close time-boxes as well as the specifics of how Discovery paths and Delivery paths integrate will naturally change based on the dynamics of the people, enterprise, and context.

Discovery

Each Discovery path is owned by a Discovery Team, which focuses on discovering what is of value. This team is composed of any number of sub-teams based on the needs of the enterprise, context, and its related Delivery paths. Some sub-teams may integrate the various aspects of value produced by related Delivery paths while other sub-teams may integrate the Discovery path with the enterprise (Strategy and Infrastructure).

Delivery

Each Delivery path is owned by a Delivery Team, which focuses on delivering value. This team is composed of any number of sub-teams based on its related Discovery paths. Each sub-team integrates a Define-perspective for defining aspects of a result, a Build-perspective for constructing aspects of the result, and a Test-perspective for ensuring the aspects of the result meet their definition.

Strategy and Infrastructure

A Strategy Team unifies all of the Discovery and Delivery paths within an enterprise, and an Infrastructure team provides a foundation for all of the Discovery and Delivery paths within the enterprise. These teams may be composed of any number of sub-teams based on the dynamics of the people, enterprise, and context.

The Enterprise

An enterprise will generally have one Strategy Team with Discovery Teams, Delivery Teams, and Infrastructure Teams that are as dynamic (forming and adjourning as appropriate) as the enterprise requires based on its context — within the constraints of Value and Co-Creation; that is, Discovery and Delivery are organized (co-creatively) around value. That is, teams may be as stable or unstable, long-lived or short-lived, and have sub-teams as necessary — which ultimately results in teaming (versus teams) and communities (of practice). Furthermore, the necessary integration points foster the needed “stability” to foster wholeness for the enterprise and its constituents.

The most basic or foundational/quintessential enterprise involves one Strategy Team with each Discovery Team having one Delivery Team (which may have sub-teams) and a shared Infrastructure Team integrated via various integration points.

The eSAFe: SAFe through Dual-Track Value Co-Creation

Both, the SAFe and the Dual-Track Value Co-Creation metaphor, identify a set of concepts and are non-prescriptive in what concepts to instantiate in a specific context or how to instantiate concepts in a specific context. While the SAFe emphasizes or stipulates stable teams (and teams-of-teams), long-lived teams (and teams-of-teams), cadence, and synchronization, the Dual-Track Value Co-Creation metaphor does not stipulate anything beyond organizing around Value, Co-Creation of Value, Co-creative Discovery of Value, and Co-creative Delivery of Value.

Comparing the SAFe and the Dual-Track Value Co-Creation metaphor:

  • SAFe’s Team Level maps to Delivery.
    Each Agile Team is a Delivery sub-team of a broader Delivery Team. Each Delivery sub-team has an associated Delivery sub-team Backlog. The Delivery Team (which includes all the sub-teams) is associated with a Discovery Team.
  • SAFe’s Portfolio Level maps to Strategy.
    Program Portfolio Management is the Strategy Team with the Portfolio Backlog being a Strategy Backlog. Value Streams are Discovery paths.
  • SAFe’s Program Level maps to Discovery and Infrastructure.
    Product Management is a Discovery Team with the Program Backlog being a Discovery Backlog.
    Release Management is the Infrastructure Team.
    The System Team is a sub-team of the Discovery Team or another Delivery Team (associated with the Discovery Team).
    The Agile Release Train (Shared Resources, DevOps, User Experience, System Architect, Release Train Engineer) is a sub-team of the Discovery Team or another Delivery Team (associated with the Discovery Team).

Fundamentally, eSAFe involves a Portfolio-Level Strategy Team, Program-Level Discovery Team and Infrastructure Team, and Team-Level Delivery Team (of sub-teams) that are all stable, long-lived, and executing on a synchronous cadence (or executing on a cadence and are synchronized).

The Ownership Pyramid

May 23, 2014

Throughout our individual journeys, we encounter many people whose contributions readily go unnoticed. I’ve had the privilege of working with Peter Simon whose Ownership Pyramid is definitely worth exploring. Herein are a few questions that Peter addressed…

Ownership Pyramid_v1

What is the Ownership Pyramid?

The Ownership Pyramid is the result of an attempt to address a bigger socio-economic problem that has become apparent over the past 10 to 15 years. Whether it’s big government or big business, the end result has always been a stripping of an individual’s ability to own. As we enter a new age of politics and economics, the importance and understanding of ownership has been lost and needs to be restored. The Ownership Pyramid is a framework to guide people in understanding how to achieve and maintain ownership, without abusing its power.

What is the purpose of the Ownership Pyramid?

The Ownership Pyramid stemmed from my experiences in technology Project Management, where I experienced and was actually trained to collaborate with multiple application users and developers to gather requirements, but speak to each group separately, while trying to communicate a clear picture of what each group needed.

Looking back, project managers should have been called magicians, because after taking pieces of information from each group without anyone actually speaking directly to each other, it was expected that 6 months later, a product working to perfection was to magically appear. The only real magic performed was making project budgets disappear and changing project status colors from green to red. Presto! After pulling a rabbit out the hat during one too many stakeholder meetings, I felt it was time for a change in how the whole process works.

I wasn’t aware of Agile development or Agility at the time, but when I was first introduced to the Agile values, principles, practices, and frameworks, I embraced them and never looked back. Agility involves many paradigm shifts from the traditional model, but the one that stood out for me was the concept of the Product Owner (in Scrum, or Customer in Extreme Programming).

As a Libertarian, it hit me hard, and I became somewhat obsessed with the concept of ownership in general. Over time and through personal experiences, I realized how little ownership actually exists in society. Did the level of ownership change over time? How can ownership be measured within a society?

These were difficult questions to answer, but I thought that a fundamental framework could be valuable to guide a person in understanding ownership, maintaining ownership, and assessing whether ownership has been achieved or even existed. And that’s when the Ownership Pyramid concept was born. The Ownership Pyramid allows an individual to take steps to achieve greater ownership, assess their level of ownership, and practice actual ownership; with the widespread purpose of promoting and realizing humanities strengths through the process of achieving ownership.

What are the guiding organizing principles (how are the concepts organized)?

The Ownership Pyramid is structured to provide the steps for achieving ownership. Each building block of the pyramid is in an input/output relationship; meaning that the inputs in a particular level result in the outputs in the subsequent higher level. I tried to keep the structure as simple as possible, yet streamline it into a story with a continuous purpose and goal, the process doesn’t end when you reach Self-Assessment, rather it is only beginning.

The base of the pyramid is crucial, I place great importance on Respect and Forgiveness. Without these inputs, the entire pyramid eventually collapses as ownership is lost. To begin, understanding of the human spirit, nature, and potential is critical in progressing towards achieving ownership. Next is setting a course and absorbing enough information to begin formulating processes to produce the desired output. Finally the resulting product is created and continuously perfected using self-assessment techniques. The Self-Assessment is the final and most important step; if one can be strong enough to assess themselves as a human being they are able to discern value from cost and lead in a direction that is best for them and others impacted by their process, product and actions.

The Ownership Pyramid can be thought of as a base process that can spawn processes within processes, all seeking the same resulting goal. For example, the pyramid can be used to solve a problem, then used to create the concept for a product, then be used to develop the product — all while fostering ownership.

There’s an intersection point in the pyramid as well. Where the People come together, so do each of their pyramids. When each of the people effectively utilizes the pyramid, a masterful team emerges; at times we are fortunate enough to witness this achievement in sports, business, and relationships.

How do you use the Ownership Pyramid (in practice)?

The Ownership Pyramid can be used in a variety of industries. My expertise is in product delivery, specifically software applications. Because these types of delivery processes are highly dependent on the level of ownership within a team, I use the Ownership Pyramid as a means to assess the team’s strengths and weaknesses, and each individual’s sense of ownership relating to the overall goals of the team. For example, if the team members lack respect for each other, there are most certainly larger obstacles waiting around the corner.

Why “Ownership” not “Leadership” (especially when there is some much being talked about and done around leadership today)?

I’m really glad you asked this question. I personally believe that today’s concept of leadership is a dangerous mindset to promote. The idea that there are born leaders has been repeated to us for so many years now, its almost embedded in our DNA that their are those among us that will lead and all others must follow. When people are expecting a leader to be named, it can lead to a lack of commitment from the “followers” and a sense of hopelessness in having control over one’s destiny.

In too many circumstances, today’s definition of Leadership negates the concept of ownership; you don’t have to look far to see where ownerless leaders have taken over industries and governments. A leader lacking ownership can be identified when witnessing people using leadership as a control grab for their own benefit, at the expense of the group as a whole; when a corporate or government policy causes harm to the masses, and no one is held responsible.

Many of the today’s concepts regarding leadership reside under the pyramid. A leader lacking ownership is an enforcer, the leader achieving ownership is a coach, a promoter, a mentor. I do believe we are all leaders in our own way, and the Ownership Pyramid thrives on this underlying concept. Some lead quietly, while others are able to reign in a crowd through public speaking. We all have our strengths and weaknesses, so its important as leaders to recognize that we are human, and because of that we all have human potential. I believe the characteristics of a leader will evolve from someone who dictates and enforces to someone who looks to help all people realize fulfillment and leadership through ownership.

This can be applied to a parent and child relationship, to a teacher and student relationship. Again, where the People intersect, if ownership has been achieved by all members of the team, then everyone on the team is a leader of their respective role and responsibility. And they in turn can coach others in their respective fields to understand and practice the steps to attain ownership.

Another way to conceptualize the ownership-leadership relationship, is by perceiving the pyramid as an engine, with one of the many outputs being Leadership; unfortunately today, the engine behind leadership is missing in today’s leadership concept.

An important tangent to leadership is Identity. Identity, like leadership, is also an output of the pyramid, and in many instances is missing from today’s leader. Foundational steps (respect and forgiveness) lead to direction, focus, effort, knowledge which involve responsibilities being combined among People and their roles; culminating to reach Identity. Each step in the pyramid, along with iterations through the pyramid, ultimately leads one closer to understanding their Identity; and at the intersection among People, one’s identity becomes clearly visible. Combining a sense of Identity with Leadership ultimately results in a true understanding of Ownership, and that will allow for Self-Assessment to be incorporated into one’s daily process, enabling that person to maximize their agility and human potential. Committing to practicing the principles of the Ownership Pyramid is the beginning of a journey, a journey worth taking.

Agility Schmagility & Agile Schmagile

May 10, 2014

Reminded of Piet Hein’s The Road to Wisdom?

The road to wisdom? — Well, it’s plain and simple to express: Err and err and err again but less and less and less.

In 2009, we encountered “Agility Schmagility,” (Julian Keith Loren @jkloren) which inspired clarifying our approach to agility (Agility Distilled). Now, in 2014, we again encounter “Agile Schmagile,” (Tweet this!) (Nassim N. Taleb @nntaleb per Elinor Slomba @artsint via a tweet) which likewise inspires clarifying our approach to agility and even more-so antifragility (Conscious Agility with @brad_barton and @mark4ro — and Anti-fragility Distilled coming soon!) — Antifragile / Antifragility is a post-agile / post-agility concpet. The road goes on and we may contribute . . . http://twitter.com/artsint/status/464010573584162817

Scaling Agility with Conscious Agility & SAFe, DAD, LeSS, Agility Path, or ScrumPLoP

May 3, 2014

As many organizations continue to confront the challenges of achieving greater agility (Agility Model and Manifesto for Agility) at scale in a VUCA (volatility, uncertainty, complexity and ambiguity) world, various options have emerged (and are gaining recognition), including:

While each of these approaches advances a particular world view, they don’t particularly provide a means for adopting, scaling, and sustaining agility.

Conscious Agility

Conscious Agility — which emerges from Conscious CapitalismBusiness Agility, and Antifragility with experience fully rooted in decades of practice across many industry domains — is a design-thinking approach for business ecosystems that integrates awareness with intuition, orientation, and improvisation so that individuals and collectives may benefit from uncertainty, disorder, and the unknown.

Conscious Agility intentionally uses the concept of a fresh Canvas, a description of reality that reflects how stakeholder work together (are being and doing) within an ecosystem. Each Conscious Agility initiative begins with a fresh canvas which:

  • First gains shape, perspective, and breadth (for example, as a sketch);
  • Then contrast and depth (for example, shading the sketch); and
  • Finally detail and focus (for example, texturing the shaded sketch).

And within a Conscious Agility initiative, the contents of these approaches (SAFe, DAD, LeSS, etc.) may be appropriately used to evolve the canvas.

See Conscious Agility: A Brief Introduction for more information.

Conscious Agility for . . .

Alternatively, Conscious Agility could be used more explicitly while focusing on one of these approaches (SAFe, DAD, LeSS, etc.) — Conscious Agility for SAFe (CA-SAFe) or Conscious Agility for DAD (CA-DAD) or Conscious Agility for Lethe approaches (SS (CA-LeSS) — while offering a proven options for adopting, scaling, and sustaining agility.

For example, SAFe clearly acknowledges that “SAFe does note implement itself and indeed makes no attempt to describe the significant organizational change management, cultural impacts, implementation strategies, and training and services provisioning that are typically required for successful implementation” but offers brief “recommendations for implementation,” Conscious Agility or Conscious Agility for SAFe (CA-SAFe) would fill this void and guide an implementation team in exploring the various elements from the Team, Program, and Portfolio levels that might be implemented as well as consider the significant organizational change management, cultural impacts, implementation strategies, etc. required for successful implementation.

Keeping the “Human Element” Paramount

Additionally, not only does Conscious Agility offer a means for adopting, scaling, and sustaining agility, but it also offers the ability to

  • Integrate aspects from any of the above approaches (among others) together
  • Explicitly recognize and appreciate the nuances of the context in which adopting, scaling, and sustaining is to occur.

And Conscious Agility’s uniqueness in being agnostic and embracing an all-inclusive viewpoint, integrating relevant perspectives yet keeping the “human element” paramount, makes it only that much more essential for successfully adopting, scaling, and sustaining agility.

The Agile Model, Agility Model, and Manifesto for Agility

April 5, 2014

We live in a VUCA (volatility, uncertainty, complexity and ambiguity) world where we are challenged to be thriving on chaos in an age of discontinuity — where the past is plagued with incoherence & inconsistency, the present is plagued with chaos & ambiguity, and the future is plagued with unpredictability & uncertainty!

The Agile Model (Nick Horney and Tom O’Shea), our notion of Agility (The Agility Model) (Si Alhir), and The Manifesto for Agility are well aligned.

The Agile Model

The Agile Model focuses on “five characteristics needed for organizations to be capable of anticipating and responding to changing demands and adapting to new requirements . . . in real time.” That is, these critical capabilities across three enterprise domains (people, processes, and technology).

For the Agile Model, “pay attention to multiple dynamics” . . .

Anticipate Change: Interpret the potential impact of business turbulence and trends along with the implications to the enterprise. — Visioning, Sensing, and Monitoring

. . . “address issues” . . .

Generate Confidence: Create a culture of confidence and engagement with all stakeholders especially associates in effective and collaborative teams. — Connecting, Aligning, and Engaging

. . . “ensure there is a shared mindset . . . urgency for getting stuff done . . . positive accountability for doing so” . . .

Initiate Action: Provide the fuel and the systems to enable things to happen proactively and responsively, at all levels of the organization. — Bias for Action, Decision-Making capability, Collaborating

. . . “ensure openness” . . .

Liberate Thinking: Create the climate and conditions for fresh innovative solutions by empowering, encouraging, teaching and expecting others to be innovative. — Bias for Innovation, Focusing on Customers, and Idea Diversity

. . . “identify critical metrics for success . . . learn . . . to improve.”

Evaluate Results: Maintaining a strong focus and feedback system to continuously learn and improve from actions and changing dynamics. — Creating Expectations, Real time Feedback, Fact Based Measures

The Agile Model is holistic: “A comprehensive approach, meaning each driver is a vital force only when combined with the others. Applying one or two drivers in the absence of the others is an incomplete solution and will not result in Agility.”

The Agility Model

The Agility Model focuses on “Responsiveness and the ability to continuously Re-orient as we Observe, Orient, Decide, and Act. Agility is not merely about Speed . . . not merely about Reactiveness . . . is about Responsiveness!”
For the Agility Model, the essence of Agility is expressed using three aspects (as patterns).

The Results/Value-oriented pattern:

To maximize Value, foster Focus, leverage Feedback, and foster Balance. This must blend opportunity-seeking with stability-creating.

Focus on results, which can only be achieved by iterating and leveraging feedback within context such that people balance competing forces.

The Context-aware pattern:

To foster Focus, lead through collaboration (contribution and confirmation). This is opportunity-seeking.

Lead within context, which can only be achieved by collaborating with people such that they contribute to and confirm results; leadership is essential for focusing on results.

The People/Team-centric pattern:

To foster Balance, empower people. This is stability-creating.

Empower people who are able to achieve results within context; empowerment is essential for balancing competing forces.

These patterns are interdependent:

These patterns are interdependent. Without Leadership through Collaboration, we jeopardize Focus; without Empowerment, we jeopardize the ability to Balance; without Iterating, we jeopardize the degree of Feedback; and ultimately we jeopardize Value!

The Manifesto for Agility

The Manifesto for Agility emphasizes that “Agility is a value system (mindset) that emphasizes people, results, collaboration, and responsiveness.”

The Agile Model, Agility Model, and Manifesto for Agility

TAM-TAM-MfA2014040500

The Agile Model and the Agility Model consider Agility or Responsiveness as emergent properties from the capabilities/drivers or aspects/patterns while the Manifesto for Agility identifies Responsiveness explicitly.

The Agile Model’s People domain relates to the Agility Model’s People pattern.

The Agile Model’s Anticipate Change capability relates to the Agility Model’s Context pattern. The Agility Model’s concept of leadership is congruent with the Agile Model’s concepts of potential impact, turbulence, trends, and implications.

The Agile Model’s Generate Confidence, Initiate Action, and Liberate Thinking capabilities relate to the Agility Model’s People pattern. The Agility Model’s concepts of empowerment is congruent with the Agile Model’s concepts of engagement, enablement, empowering, encouraging, and teaching.

The Agile Model’s Evaluate Results capability relates to the Agility Model’s Results patterns. The Agility Model’s concepts of focus and feedback are congruent with the Agile Model’s concepts of focus and feedback.

The Agile Model’s Generate Confidence, Initiate Action, and Liberate Thinking capabilities relate to the Agility Model’s patterns interdependence.

  • That is, “leadership through collaboration” (The Agility Model, Context-Results pattern interdependence) is essential to “create a culture of confidence and engagement” (The Agile Model, Generate Confidence).
  • That is, “empowerment . . . ability to balance” (The Agility Model, People-Results pattern interdependence) is essential to “create the climate and conditions for fresh innovative solutions” (The Agile Model, Liberate Thinking).
  • That is, “iterating . . . feedback” (The Agility Model, Results pattern interdependence on iterating for feedback) is essential to “provide the fuel and the systems to enable things to happen” (The Agile Model, Initiate Acton).

Fundamentally, Agility is realized by

  • anticipating change, generating confidence, initiating action, liberating thinking, and evaluating results; or by
  • fostering focus by leading through collaboration in context, leveraging feedback by iterating on results, and fostering balance by empowering people.
Follow

Get every new post delivered to your Inbox.

Join 41 other followers