The FLEKS model

FLEKS is a Hybrid Project Management Model, which aims at providing a way to manage projects, develop products and deliver the highest possible value within the context of a project and its stakeholders.

Businesses and projects are embedded in a complex and ever-changing environment. Organizations need to adapt constantly and quickly in order to survive and succeed. In a variety of contexts this environment can be summarized by the acronym BRIGHT (blur, risky, interconnected, global, hi-tech, timely). FLEKS is built around four pillars flexibility, integration, communication and people. 

The FLEKS model comprises six elements: mindset, principles, layers, events, value flow and roles. FLEKS advocates five different attitudes to facilitate the development of the desired mindset: focus, tailoring, teamwork, learning and adaptation. FLEKS has some principles considered sine qua non to help the management process in the challenge to lead people, create value and conduct projects to its goals: value management, progressive management, integration and balance, situational leadership, continuous improvement, plans and exceptions, roles and responsibilities, and open communication. FLEKS defines three management layers (Business, project and product) to draw a distinction between roles and responsibilities which are collaborative and interdependent. The layers also allow a better understanding of what are the main elements responsible for creating value. 

FLEKS is an iterative, incremental and recursive value creation process. Throughout the management layers and the value flow, several events are prescribed and must take place to ensure the process starts and finishes properly. The events can be divided into three main groups:

• Business: those carried out on the Business Management Layer: need analysis, solution ideation, value design, business case and project startup
• Project: those carried out on the Project Management Layer: project planning, update meeting, release review and closure meeting
• Product: those carried out on the Product Management Layer: release planning, iteration planning, iteration meeting, iteration review and iteration retrospective.

On their website (https://fleksmodel.com/fleks-model/) you can download the FLEKS Model Guide and the FLEKS Canvas.

The FLEKS model can be positioned in the one-time projects/programs block in my Bird’s eye view on the agile forest. For the latest updated version of my Bird’s eye view on the agile forest article see: https://hennyportman.wordpress.com/2020/10/11/new-birds-eye-view-on-the-agile-forest/

Structural Agility, a next tree

The quest to find more trees for my agile forest continues. Structural Agility is again a way of working that fits in the culture targeted box of my The bird’s eye view on the agile forest overview and complements ‘frameworks’ like Scrum, SAFe, Less, disciplined Agile, et cetera.

Structural Agility (author Jardena London) supports business agility and rests on the core concept that structure enables flow; specifically, the flow of information, energy, and resources inside an organization. Understanding how Structural Agility enables flow begins with three key terms: structure, boundaries, and rules.

• Structure is anything that creates boundaries and rules to organize people and activity towards a shared purpose.
• Boundaries are the borders where things start and end, and help the human mind see complexity more clearly.
• Rules are a set of formal and informal directives that support the boundaries.

Structural Agility uses nine principles that are based upon three existing disciplines: Living Systems, Systems Thinking, and Dynamic Tensions (polarities or tensions between processes, practices, business outcomes, mindsets, emotions, and so on):

1. We view organizations as living, human ecosystems, inherently interconnected and able to flourish
2. Continuous design allows the organization to evolve
3. Agility only exists when we create conditions for it, instead of directing activity
4. We thrive by leveraging dynamic tensions
5. We enable flow through hierarchies which are naturally in service to each other
6. Adaptations for how we organize emerge from within the organization
7. At every level, the organization has a way to shed and spawn from within itself
8. Intentional development, both individual and collective, fosters organizational evolution
9. Shared identity allows for trust and self-organization.

More information and a download of the Structured Agility article can be found on https://businessagility.institute/learn/structural-agility-using-structure-to-enable-the-flow-of-value/

See the latest, updated version of my Bird’s eye view on the agile forest.

Flow framework, a new twig in the agile forest

The goal of the Flow framework^tm (developed by Mike Kersten) is to bring Scrum and Agile concepts to the business while providing a higher level of abstraction than agile teams work with day to day. The framework scales the three ways of DevOps – flow, feedback, and continuous learning – to the entire business. User stories and story points are layered over by the four Flow items: features (new business value), defects (quality), risk (security, governance, compliance), and debt (removal of impediments to future delivery). Flow distribution makes priorities visible. Using the Flow Framework if a scaling framework, such as SAFe, LeSS or Nexus, is in place, could lead to greater success.

• From project & cost centers to product value streams
• From siloes & proxy services to flow metrics & business results
• From fragmented value streams to integrated value stream network

The corresponding book:

To order (managementboek.nl): From project to product

To order (amazon.com): From project to product

For more information: https://flowframework.org/

Youtube: Project to Product: How Value Stream Networks Will Transform IT & Business – Mik Kersten

In my bird’s eye view I positioned the Flow framework in the product targeted box. I see the Flow framework as a sort of add on for SAFe, LeSS, Nexus, et cetera.

See my blog for the complete Bird’s eye view on the agile forest article.

Is Scream a new tree in the Agile forest?

Via my network I received the first version of the Scream Guide; a comprehensive guide (22 pages) to organizational screaming, written by Michael Küsters.

Scream is a framework built as an imitation of Scrum, giving unwitting observers the appearance that the organization might be using Scrum. Scream is a framework for cementing the status quo, preserving existing mindsets and creating an illusion that things are improving. Scream is lightweight and easy to do, but difficult to get rid of.

Scream is intended as a humorous reflection opportunity of anti-patterns you might observe and not meant to be implemented.

Scream uses the pillars of obfuscation, asymmetric information and moving targets and the following value definitions:

• • “Courage” means accepting more work than can be done
  • “Commitment” means doing it in unpaid overtime
  • “Openness” means still taking another task whenever asked
  • “Focus” means juggling many balls without being caught dropping any
  • “Respect” means not complaining about any of the above when talking to managers.

The Scream Team consists of a Product Owner (responsible for maximizing the workload of the Development Team), the Development Team (consists of people who do the work that they are told to do), and a Scream Master – plus their manager (a strong, demanding manager who suppresses autonomy, creativity and personal growth within the Scream team). Scream Teams appear self-organizing and cross-functional when indeed the entire show is run by the manager.

Prescription is an important element of Scream, and Scream events (sprint, sprint planning, daily scream, sprint review and sprint retrospective) are used to interrupt work, control team members and maximize the dependency on outside management interference.

After detailed descriptions of the roles, events, artifacts and rules you get a list of supporting practices. E.g. Scream practice supports a number of special sprints: kick-off sprint, sprint zero, document sprint, refinement sprint, testing sprint, integrating sprint, hardening sprint, deployment sprint, release sprint, stabilization sprint and innovation sprint.

Conclusion: Scream isn’t a new tree in the agile forest. It is fun to read and every sentence is an agile antipatern. This guide will definitely help to mature your own chosen agile framework tree implementation.

To download: www.agilegothenburg.org/blog/2019-posts/the-scream-guide-is-out

To refresh your memory have a look at the latest Bird’s eye view on the Agile forest.

See for the corresponding article: a-bird’s eye view on the agile forest article

The Business Technology Standard

The Business Technology Standard (or BT Standard, 4th edition) is an open-source management framework to plan, build and run information technology in today’s technology-driven business world.

It gives a comprehensive picture of how to manage the overall business technology organization with pragmatic governance without compromising speed and agility. Using the Business Technology Standard on top of practices such as SAFe and DevOps for agile development and ITIL for service management, enables holistic management of different technology management functions.

The Business Technology Standard consists of three complementary and consistent models and perspectives for unified information and digitalization management:

• Operating model to define value creating flows and disciplines
• Capability model to define disciplines and associated capabilities
• Roles and responsibilities model to define identities, roles and responsibilities.

The Business Technology Standard introduces several unique elements addressing the current challenges many organizations are facing with the digital development such as:

• Value streams to cope with business diversity and differences in speed, agility and culture
• Minimum viable governance to balance flexibility and governance in decision-making
• Multi-speed development flows to respect development method differences (gate based development, sprint-based development and change request based development)
• Unified roles to clarify the roles and responsibilities in a unified way.

On the corresponding website you can click on every elements of each model to get detailed information. You can download the BT Standard too (pdf, 135 pages): https://www.managebt.org

I added this framework in my ‘Bird’s eye view on the Agile forest’ article. See: https://hennyportman.wordpress.com/2019/11/17/a-birds-eye-view-on-the-agile-forest-article-published-on-pm-world-journal/

FLEX, Flow for Enterprise Transformation

The first post in 2020 is again a post about an agile framework. The forest is still growing and this will not be the last one. The next one is already under review too.

FLEX, Flow for Enterprise Transformation, developed by Al Shalloway, is designed to be used as a guide for organizations to achieve business agility. It is a platform which lays out the steps required for improving the way a company adds value to its customers, both external and internal. It can be used with Other agile frameworks like SAFe, Nexus, LeSS, Disciplined et cetera. FLEX is designed to work at the organization level, regardless of the size of the organization involved or if only part of the organization is involved. It is designed around flow-thinking, Lean-thinking, the theory of constraints, and organizational development integrated with how people learn and change habits.

FLEX incorporates four shifts in thinking. These are systems-thinking, shifting from frameworks to the work itself, focusing on flow, and attending to organizational development with Lean.

FLEX contains the following components: objectives, practices, agreements and principles, transformation philosophy and natural laws. People make agreements that are organized around working together, not merely follow an approach. The following basis agreements are translated into guardrails (a guardrail includes a variety of questions to check if you are keeping the agreement): drive from business value, collaborate across boundaries, make all work visible, increase predictability, keep WIP within capacity and improve continuously.

There are 4 new roles required when going to scale: business architect, application development manager, technology delivery manager (TDM), and value stream network architect.

As a starting point the following five-step approach to a roadmap can be used:

1. See where you are
2. Understand the challenges you are having
3. Lear a few key principles and practices that will help you overcome these challenges
4. Define to begin using FLEX’s starting template and tailoring it for your organization
5. Begin and continuously improve

For more information visit: portal.netobjectives.com/pages/flex/

In September 2019 PMI acquired FLEX from Net Objectives. Will PMI create a new agile framework incorporating FLEX, Disciplined Agile and Brightline Transformation Compass? If so, it will generate some open space in my agile forest with the risk that new agile frameworks originate.

Due to the fact that they positioned FLEX as a guide to achieve business agility and to be used together with other frameworks I position FLEX in the culture-targeted box in my Bird’s eye view on the agile forest.

For the complete Bird’s eye view on the agile forest article see: Portman, H. (2019). A bird’s eye view on the agile forest; PM World Journal, Vol. VIII, Issue X, November.

Brightline Transformation Compass

I just finished the draft version for the second print of my book Scaling agile in organizaties (in Dutch) and I counted 65 frameworks and approaches (25 more than the first print). I thought I covered all, but I found a few new ones.

One of them is the Brightline Transformation Compass, a comprehensive system for transformation developed by Behnam Tabrizi, PMI.

This approach helps to create the right mindset within your organization needed for a successful agile transformation. It gives you a compass that is built around 5 critical, mutually reinforcing building blocks for effective transformation and a three-step approach for transformation.

The five compass building blocks:

1. North Star: A crisp, inspiring articulation of the vision and strategic objectives for the transformation to give your employees a clear direction.
2. Customer Insights & Megatrends: Embedding a deep understanding of the customer in every change you make, and in every employee – the customer you may have today, and the customer you want tomorrow, as well as the “megatrends” affecting them. Core principles are involving the real customer, find leading customers and conduct the research yourself.
3. The Transformation Operating System: A flat, adaptable and cross-functional organizational structure that enables sustainable change. It consists of five components: Flat, cross-functional Rapid Response Teams, a lightweight governance & strong program management, a collaborative and appropriate risk appetite, well-defined KPIs and venture-style investment rounds.
4. Your Volunteer Champions: A mechanism to harness many thought leaders from across your organization to drive transformation (identify, recruit, motivate and empower).
5. Inside-Out Employee Transformation: A set of tools to make the transformation personal for your employees – to connect their aspiration to the North Star and to your customers based on the SEE-model. The aim of the SEE-model is to find the intersection between your strengths, the elements of the transformation that evoke personal meaning and actions that make you feel elated.

The three-stage methodology for transformation (inspire, mobilize and shift):

• Inspiring your organization for change: build your transformation organization with Rapid Response Teams initiated and ready to start.
• In mobilizing key elements to drive the change: define the blueprint for your transformed organization and build a plan to get there.
• In shifting the organization to effect transformation: execute on the transformation to meaningfully alter performance and instill the mindset and culture within the organization to continue transforming on an ongoing basis.

This approach is independent of the framework or methodology you are using. It can be used on top of SAFe, LeSS, Disciplined Agile, Nexus and many more to create the right mindset and will improve the chance of a successful agile transformation (more than 70% fail).

For more information on the Brightline Transformation Compass: www.brightline.org

This is definitely an approach that fits in the culture-targeted box in my Bird’s eye view on the agile forest.

For the complete Bird’s eye view on the agile forest article see: Portman, H. (2019). A bird’s eye view on the agile forest; PM World Journal, Vol. VIII, Issue X, November.

The Toyota flow system

The Toyota Flow System (TFS, developed by Nigel Thurlow, Professor John Turner, and Brian Rivera, 2019) can be described as a system of patterns, practices and techniques to enable organizations and institutions to achieve desired outcomes in a complex world. This model uses the popular representation of a house, from the Toyota Production System model (TPS), to outline an evidence-based approach to achieving business transformation.

The TFS is a system of understanding, and not a one-size-fits-all framework. The TFS model aims to sustain the flow of value to the customer, who is the center of the TFS universe.

As we dig deeper into the helixes, we find the philosophies, tools and knowledge (practice and theory) behind each component.  For Distributed Leadership, leadership is viewed as being bottom-up, top-down, as well as horizontal. Complexity Thinking involves identifying the level of complexity that is present in a problem or environment and calls for viewing systems as open and complex adaptive systems (CAS). Finally, Team Science utilizes empirical research to incorporate teamwork into current practices rather than operating as command-and-control groups with no teamwork present.

For more information have a look at: Introducing the Toyota flow system 

In my Bird’s eye view on the agile forest, I positioned this approach in the block business as usual / indefinite. For more information on this picture see: A bird’s eye view on the agile forest 

Bimodal Portfolio Management

Introduction

At the moment, many organizations are in the middle, or on the brink of, a radical change to more business agility. I receive quite often the question how to cope with both an agile portfolio as well as a more traditional portfolio with temporary projects and programs. Existing frameworks supports either an agile IT portfolio or a more traditional portfolio, but I haven’t seen frameworks which supports both.

If I look at existing traditional and agile IT portfolio management frameworks, I asked myself if combining these frameworks can bring an answer for those organizations who need to manage an agile as well as a more traditional portfolio?

In this article I will start with a brief explanation of the existing portfolio management frameworks by explaining the principles and the process (Management of Portfolios, Standard for Portfolio Management, Disciplined Agile Portfolio Management, Agile Portfolio Management, Evidence-Based Portfolio Management, and SAFe Lean Portfolio Management).

In the second part of this article I focus on Bimodal Portfolio Management where I combine the best of these worlds and offer a solution for both worlds in the form of a Bimodal Portfolio Kanban (see figure), Bimodal Portfolio Management Principles and Bimodal Portfolio Roadmaps.

To download the article: Bimodal Portfolio Management (article, 190626) v1.0

 

The Agile Fluency model

The Agile Fluency model, developed by Diana Larsen and James Shore in 2012 and substantially updated in 2018, is a framework to help teams understand their current position and to help them develop an individual road map. Agile teams pass through four distinct zones of fluency as they learn (fluency evolves). Diana Larsen defines fluency as things that you do automatically without thinking. Each zone brings specific benefits:

1. Focusing teams produce business value (agile fundamentals). The team thinks and plans in terms of the benefits their sponsors, customers, and users will see from their software.
2. Delivering teams deliver on the market cadence (agile sustainability). The team can release their latest work, at minimal risk and cost, whenever the business desires.
3. Optimizing teams lead their market (innovative business agility, agile’s promise). The team understands what their market wants, what your business needs, and how to meet those needs.
4. Strengthening teams make their organizations stronger (possible future of agile). The team understands its role in the larger organizational system and actively works to make that system more successful.

A team’s fluency comes from the ability of team members to self-organize so that individual skills are applied to the right problems at the right times. A team is fluent in a zone when it’s fluent in all of the zone’s proficiencies, including predecessor zones.

The appropriate zone for your teams depends on your organization and can be different from team to team. It is not a ranking system, but is about understanding and working towards the appropriate level of fluency for your needs at a particular point in time. Delivering or Optimizing are often the best targets, but Focusing and Strengthening can also be good choices. Fluency is more a matter of habits than skills.

Video: The Agile Fluency Model Explained: A Brief Guide to Success with Agile

The Agile Fluency Model whitepaper

Agile Fluency Simulation — an educational, exciting board game

This model definitely fits into the culture-targeted block of my bird’s eye view on the agile frameworks forest (see also the complete article):