Last week’s article on Two-speed IT brought a lot of interest. But also one repeated question. Ok, you have an hybrid model between Agile and Core ways of working. How do you keep both in sync?

Well, by having a sync-layer and a new role: the Communication Manager.

In Two-Speed IT, a communication manager is a role responsible for developing and implementing communication plans to ensure effective communication between the core IT team and the agile IT team. The communication manager works to establish communication channels and protocols and ensures that all team members are aware of the communication plan and understand their roles and responsibilities. He or she is the main role of the Sync layer.

The communication manager plays a critical role in ensuring that communication is clear and effective between the core and agile IT teams. They are responsible for establishing communication channels, such as email, instant messaging, or video conferencing, and ensuring that all team members are aware of these channels and how to use them. The communication manager also establishes protocols for communication, such as frequency and format, and ensures that all team members understand these protocols and follow them.

CMs are also responsible for monitoring communication channels to ensure that they are working effectively and that team members are communicating with each other in a timely and efficient manner. They also provide feedback to team members to ensure that communication is effective and efficient, and to identify areas for improvement.

The communication manager is typically a highly skilled professional with experience in communication, project management, and IT. They have excellent communication skills, both written and verbal, and are able to communicate effectively with a variety of stakeholders, including business leaders, IT professionals, and end-users.

Overall, the communication manager plays a critical role in ensuring that communication is clear and effective between the core and agile IT teams in Two-Speed IT. By establishing clear communication channels and protocols, and monitoring communication channels to ensure that they are working effectively, the communication manager helps to ensure that the benefits of the Two-Speed IT approach are realized.

The CM populates a layer with a mixture of Agile roles (Scrum Master, PO, etc.) and traditional roles (PM, PMO, etc.) which is used for synchronicity. By enabling a series of intersecting communications between GANTTs, Epics and holding Quarterly Planning meetings, the CMs in an organization keep the work on path.

But which are the other roles of Two-speed it?

The Agile IT Team: The agile IT team is responsible for developing and implementing new systems and technologies that are more flexible and adaptable to change. To achieve this, they need to work collaboratively with business units and stakeholders to understand their needs and requirements. The agile IT team is responsible for communicating the status of their projects, sharing updates on their progress, and collaborating with the core IT team to ensure that the new systems are integrated with the existing core systems. The main Agile roles are Scrum Master, Product Owner, Team Member and Kanban Coach.

The Core IT Team: The core IT team is responsible for maintaining the stability and reliability of the organization’s foundational IT systems. They need to communicate with business units and end-users to understand their needs and requirements, and provide support to resolve any issues or problems that arise. The core IT team is responsible for communicating the status of their projects, sharing updates on their progress, and collaborating with the agile IT team to ensure that the new systems are integrated with the existing core systems. The main roles are Business Analyst, Programmer, Tester, Project Manager.

Together with the CMs, and roles that vary depending on which flavor of methodology you are using (i.e. Agile Coaches, PMOs, etc.) but which can be slotted into one of the three layers:

1. Agile IT
2. Core IT
3. Sync layer

I hope this helps to clarify this aspect of Two-speed IT!

I’ve been writing quite extensively around and about the SAFe framework. Of course, finding out about SAFe is as easy as going to https://scaledagileframework.com/ .

Now is especially a good time, since SAFe 6.0 has just launched.

So why I have spent as much time as I have writing this article? Because the SAFe site, while full of information is… extremely full of information. Not to mention acronyms; SAFe uses acronyms the way you breathe after a lengthy immersion underwater. It is a complex, established methodology.

This complexity obscures the main questions you should be asking, for a Digital Transformation: What is SAFe? What are the challenges in a SAFe transformation? How does an SAFe Enterprise looks like?

And the main question: should I use SAFe?

Join me into this exploration into SAFety.

What is Safe agility?

Safe agility, often referred to as “SAFe Agile” or “Scaled Agile Framework,” is a set of principles, processes, and practices designed to help large organizations adopt and scale Agile methodologies to improve software and systems development. SAFe Agile provides a structured approach for implementing Agile practices across multiple teams and departments, enabling them to work together effectively and deliver complex projects more efficiently.

The framework is based on several core principles, including Lean, Agile, and Systems Thinking, and it provides guidance on roles, responsibilities, artifacts, and events necessary for implementing Agile at scale. Some of the key components of SAFe Agile include:

·     Agile Release Train (ART): A cross-functional group of teams that work together to deliver a continuous flow of value by developing, testing, and deploying software increments.

·     Program Increment (PI): A timebox of usually 8-12 weeks, consisting of multiple iterations (usually 2-week Sprints), where ARTs work together to achieve their objectives.

·     DevOps and Continuous Delivery Pipeline: A set of practices and tools that enable teams to integrate, test, deploy, and release software rapidly and reliably.

·     Lean Portfolio Management (LPM): A strategic approach for aligning an organization’s vision, strategy, and investment priorities, while effectively managing the flow of work.

·     Innovation and Planning (IP) Iteration: A dedicated timebox for teams to focus on innovation, planning, and continuous improvement activities.

·     SAFe Core Values: Built-in Quality, Program Execution, Alignment, and Transparency, which are the foundation for the framework and guide decision-making.

SAFe Agile has been adopted by many large organizations to help them scale their Agile practices, improve collaboration, and deliver value more rapidly. However, it’s important to note that SAFe is just one of several frameworks available for scaling Agile, and organizations should carefully consider their specific needs and contexts when choosing the right approach. Right now, SAFe is the one people know the most; so if finding skilled resources is an issue, SAFe might be the right choice based on availability of knowledge and experience.

Why should you use safe agility?

Organizations may choose to adopt SAFe Agile for a variety of reasons, depending on their specific needs and objectives. Here are some common reasons why organizations might choose to use SAFe Agile:

·     Scalability: SAFe Agile provides a structured approach for scaling Agile practices across large organizations with multiple teams, departments, and layers of management. It helps address the challenges that arise when coordinating the work of multiple Agile teams working on large, complex projects. 

·     Alignment and collaboration: SAFe Agile promotes alignment and collaboration between teams and stakeholders at various levels of the organization. This helps ensure that the organization’s vision, strategy, and investment priorities are in sync and that everyone is working towards the same goals.

·     Faster time to market: By implementing Agile Release Trains (ARTs) and Program Increments (PIs), SAFe Agile enables organizations to deliver value to customers more frequently and predictably. This can help organizations reduce time to market and stay ahead of their competitors.

·     Improved quality: SAFe Agile emphasizes built-in quality, ensuring that quality is considered at every stage of the development process. This can result in reduced defects, lower rework, and improved overall product quality.

·     Better risk management: SAFe Agile encourages early and continuous integration, testing, and feedback, which allows organizations to identify and address risks sooner in the development lifecycle. This can lead to more effective risk management and better decision-making.

·     Flexibility and adaptability: SAFe Agile promotes a culture of continuous learning and improvement. This helps organizations become more adaptable and responsive to change, allowing them to better cope with the uncertainties and rapid pace of today’s business environment.

·     Lean Portfolio Management: SAFe Agile’s Lean Portfolio Management (LPM) practices help organizations prioritize and allocate resources more effectively, ensuring that they are investing in the most valuable initiatives and maximizing their return on investment (ROI).

While SAFe Agile can offer many benefits, it’s important to note that it’s not a one-size-fits-all solution. Organizations should carefully evaluate their specific needs, context, and existing Agile practices to determine whether SAFe Agile is the right fit for them.

How to transition organizations from traditional to SAFe

Transitioning an organization from traditional methods to SAFe Agile requires a well-planned approach that considers the organization’s unique context, culture, and existing processes. Here’s a high-level outline of steps to facilitate this transition:

1.    Assess the current state: Begin by evaluating the organization’s existing processes, structures, and culture. Identify the strengths, weaknesses, and opportunities for improvement that will help tailor the SAFe Agile implementation. 

2.    Create awareness and build leadership support: Educate organizational leaders and stakeholders on the benefits and principles of SAFe Agile. Secure their commitment to provide the necessary resources and support for a successful transition.

3.    Identify and train change agents: Identify internal champions and change agents who will help drive the transition to SAFe Agile. Provide them with training and resources to effectively support and promote the adoption of the new framework.

4.    Develop a transition plan: Create a detailed plan outlining the steps, timelines, and resources required to transition from traditional methods to SAFe Agile. This plan should include milestones, goals, and metrics to track progress and measure success.

5.    Train and coach: Invest in training and coaching for employees at all levels, including executives, managers, and team members. Ensure that key roles, such as Release Train Engineers (RTEs), Product Owners, and Scrum Masters, receive specialized training to effectively perform their responsibilities within the SAFe framework.

6.    Implement SAFe Agile incrementally: Start with a pilot project or a single Agile Release Train (ART) to test and refine the SAFe Agile implementation. Use lessons learned from the pilot to refine the approach before scaling it across the organization.

7.    Adapt organizational structures and processes: Modify existing organizational structures and processes to align with SAFe Agile principles and practices. This may involve reorganizing teams, updating governance structures, and revising performance metrics and incentives.

8.    Foster a culture of continuous improvement: Encourage a mindset of continuous learning and improvement throughout the organization. Regularly review progress, collect feedback, and adjust the implementation approach as needed.

9.    Measure and evaluate progress: Track key performance indicators (KPIs) and metrics to evaluate the success of the transition. Use these insights to inform ongoing improvements and adjustments to the SAFe Agile implementation.

10. Iterate and scale: Continue to refine the SAFe Agile implementation, incorporating feedback and lessons learned from earlier stages. Gradually scale the framework across the organization, launching additional ARTs and value streams as needed.

Transitioning from traditional methods to SAFe Agile can be a complex and challenging process. It requires a long-term commitment from the organization’s leadership and employees, as well as a thoughtful and strategic approach to managing change. By following these steps and remaining adaptable to the organization’s unique context and needs, organizations can successfully adopt SAFe Agile and realize its benefits.

What are the major challenges with SAFE Agile? 

While SAFe Agile can be beneficial for many organizations, implementing and sustaining the framework can present certain challenges. Some of the major challenges associated with SAFe Agile include:

·     Organizational resistance: Adopting SAFe Agile often requires significant changes to the existing organizational structure, processes, and culture. This can result in resistance from employees and management who are accustomed to traditional ways of working. 

·     Complexity: SAFe Agile is a comprehensive framework with multiple layers, roles, and processes. This complexity can be overwhelming for some organizations, especially those that are new to Agile methodologies. It may also lead to bureaucracy and reduced agility if not implemented effectively.

·     Training and coaching: Successfully adopting SAFe Agile requires a considerable investment in training and coaching for employees at all levels of the organization. Finding the right trainers, coaches, and subject matter experts can be challenging and costly.

·     Loss of team autonomy: SAFe Agile introduces higher-level structures and coordination mechanisms, which can sometimes result in a perceived loss of autonomy for individual Agile teams. This can lead to reduced motivation and engagement if not managed carefully.

·     Balancing flexibility and standardization: SAFe Agile aims to provide a standardized approach to scaling Agile, but organizations must also maintain flexibility to adapt to their specific contexts and needs. Striking the right balance between standardization and customization can be difficult.

·     Maintaining Agile principles: As organizations scale Agile practices using SAFe, it’s crucial to remain true to the core principles of Agile, such as collaboration, transparency, and continuous improvement. There is a risk of losing sight of these principles as the focus shifts towards managing large-scale processes and structures.

·     Ensuring long-term commitment: Implementing SAFe Agile requires a long-term commitment from the organization’s leadership and employees. Failing to secure and maintain this commitment can result in suboptimal implementation and reduced benefits.

Overcoming these challenges requires a thoughtful and strategic approach to implementing SAFe Agile. Organizations should invest in training and coaching, foster a culture of continuous improvement, and remain adaptable to change. It’s also essential to ensure that the core values and principles of Agile are maintained throughout the scaling process. What does that means? It means that we’re talking about mindsets: Traditional Mindset vs. Agile Mindset.

The traditional mindset and the SAFe Agile mindset differ significantly in terms of their approach to project management, software development, and organizational culture. Here are some key differences between the two mindsets:

·     Focus on process vs. value delivery: Traditional project management methodologies, like Waterfall, emphasize strict adherence to processes, detailed planning, and a sequential approach to development. In contrast, the SAFe Agile mindset prioritizes delivering value to customers through iterative, incremental, and adaptive processes.

·     Predictive vs. adaptive planning: Traditional methodologies rely on upfront planning, where project scope, timelines, and resources are defined in detail at the beginning. The SAFe Agile mindset embraces adaptive planning, where plans are adjusted continuously based on feedback, learning, and changing conditions.

·     Siloed vs. cross-functional teams: In traditional approaches, teams often work in silos, with each team focusing on a specific phase of the project. SAFe Agile promotes cross-functional teams that collaborate throughout the development process, resulting in more efficient and effective problem-solving.

·     Fixed roles vs. shared responsibilities: Traditional methodologies assign specific roles and responsibilities to individuals, while the SAFe Agile mindset encourages shared responsibilities, collaboration, and self-organization among team members.

·     Change resistance vs. embracing change: Traditional mindsets often view change as a risk, and any deviations from the initial plan may be considered problematic. In contrast, the SAFe Agile mindset welcomes change, viewing it as an opportunity to improve and adapt to evolving customer needs and market conditions.

·     Contract negotiation vs. customer collaboration: Traditional approaches may prioritize contract negotiation and adherence to predefined requirements. On the other hand, SAFe Agile emphasizes collaboration with customers and stakeholders to better understand their needs and deliver valuable solutions.

·     Command-and-control vs. servant leadership: Traditional management styles often involve top-down, command-and-control structures. The SAFe Agile mindset promotes servant leadership, where leaders empower, support, and enable their teams to make decisions and take ownership of their work.

·     Linear vs. iterative development: Traditional methodologies follow a linear development process, moving from one phase to another in a sequential manner. SAFe Agile utilizes iterative development, where work is broken down into smaller increments, and each increment is developed, tested, and delivered in a short time frame.

·     Focus on documentation vs. working solutions: Traditional approaches often prioritize comprehensive documentation over the delivery of working solutions. In contrast, the SAFe Agile mindset values working solutions and delivering customer value over extensive documentation.

·     Risk avoidance vs. risk management: Traditional methodologies aim to avoid risks by following predefined processes and detailed planning. The SAFe Agile mindset embraces risk management by identifying, assessing, and addressing risks early and continuously throughout the development process.

These differences reflect the fundamental shift in mindset required when transitioning from traditional approaches to SAFe Agile. Adopting the SAFe Agile mindset involves embracing change, fostering collaboration, and focusing on delivering value to customers through iterative, adaptive processes.

 This is very different than plain old Scrum, or Kanban. While SAFe incorporates both Kanban and Scrum, all this facets of its mindset manifest in a myriad roles.

Some of the SAFe roles are:

1.Team Level (the clear Scrum level):

·     Agile Team: A cross-functional group of individuals, typically consisting of 5-11 members, responsible for defining, building, and testing features and stories within an iteration. The team typically includes a mix of developers, testers, and other specialists required to deliver the work. 

·     Scrum Master: Facilitates the Agile team’s process, ensures effective communication, removes impediments, and supports the team in adhering to Agile principles and practices.

·     Product Owner: Represents the customer and stakeholders’ voice, manages the team’s backlog, and ensures that the team is working on the highest priority items to deliver value.

2.Program Level:

·     Release Train Engineer (RTE): Acts as the chief Scrum Master for the Agile Release Train (ART), facilitating communication, collaboration, and coordination between the teams, and ensuring that the ART delivers value as planned.

·     Product Management: Responsible for defining and prioritizing the Program Backlog, working closely with Product Owners and stakeholders to ensure alignment with the organization’s strategy and objectives.

·     System Architect: Guides the technical aspects of the solution, ensures architectural alignment across teams, and collaborates with stakeholders to address technical dependencies and risks.

·     Business Owners: Key stakeholders who have a vested interest in the outcomes delivered by the ART, providing guidance, prioritization, and feedback on the value delivered.

3.Portfolio Level:

·     Lean Portfolio Management (LPM): A group of leaders responsible for strategy, investment funding, and governance, ensuring that the portfolio delivers maximum value while minimizing risks.

·     Epic Owners: Drive the definition, analysis, and prioritization of epics (large initiatives), working closely with the LPM team to ensure that the organization is investing in the most valuable initiatives.

·     Enterprise Architect: Provides guidance and support on the overall architectural vision, ensuring consistency and alignment across the entire portfolio, and promoting the reuse of architectural components.

In addition to these primary roles, SAFe Agile also includes other supporting roles, such as:

·     DevOps Team: Collaborates with the Agile teams to ensure a continuous delivery pipeline, focusing on integration, testing, deployment, and release of software increments.

·     System Team: Provides technical support, enabling environments, and tools to help the Agile teams in their development efforts.

·     UX Designer: Collaborates with Agile teams to create user-centric designs, ensuring that the solutions delivered meet user needs and expectations.

Depending on the organization’s size and context, some of these roles may be combined or adapted as needed. It’s essential to ensure that each role is well-defined and supported by the necessary training and resources for effective SAFe Agile implementation.

All these roles combine into the juggernaut that is PI sessions. PI (Program Increment) sessions are mammoth affair that last two-three days and involve most of the Enterprise, once per quarter.

So, having going over all this complexity, what does a SAFe Enterprise looks like?

An organization that has successfully implemented SAFe Agile exhibits certain characteristics across its processes, structures, and culture. These characteristics indicate that the organization has embraced the core principles and practices of the Scaled Agile Framework. Here’s what such an organization typically looks like:

·     Aligned teams and value streams: The organization has identified its value streams and formed Agile Release Trains (ARTs), which are cross-functional teams that work together to deliver value incrementally. These teams are aligned with the organization’s strategic goals and priorities.

·     Program Increment (PI) cadence: The organization follows a regular cadence of Program Increments (PIs), which include PI Planning, execution, and Inspect and Adapt (I&A) events. This cadence provides predictability and enables continuous improvement.

·     Collaborative culture: The organization fosters a culture of collaboration, open communication, and transparency among team members, across teams, and with stakeholders. This encourages the sharing of ideas, knowledge, and feedback, leading to better decision-making and problem-solving.

·     Lean-Agile leadership: Leaders in the organization practice servant leadership, empowering their teams to take ownership of their work and make decisions. They support continuous learning, innovation, and process improvement.

·     Adaptability and responsiveness: The organization is able to adapt and respond to changing customer needs, market conditions, and new information quickly and effectively. It embraces change as an opportunity to learn, grow, and deliver better solutions.

·     Focus on customer value: The organization prioritizes delivering value to customers and continuously seeks to understand and meet their needs. This focus on customer value drives decision-making and resource allocation.

·     Continuous improvement: The organization promotes a mindset of continuous learning and improvement, regularly reviewing and adjusting its processes, structures, and culture to optimize performance and outcomes.

·     Lean Portfolio Management (LPM): The organization practices Lean Portfolio Management to align strategy, funding, and execution across the portfolio. This ensures that investments are focused on delivering maximum value while minimizing risk and dependencies.

·     DevOps and Continuous Delivery: The organization has integrated DevOps practices and established a continuous delivery pipeline, enabling faster, more reliable, and more frequent releases of software increments.

·     Metrics-driven decision-making: The organization tracks key performance indicators (KPIs) and metrics to evaluate its performance, identify areas for improvement, and inform decision-making.

An organization that has successfully implemented SAFe Agile will exhibit these characteristics, demonstrating its commitment to the principles and practices of the framework. This enables the organization to achieve better alignment, collaboration, adaptability, and ultimately deliver greater value to its customers.

Should you go SAFe? The Fede’s Five Question for SAFety

Having said that, we go back to the first question. Should you go SAFe?

This is a question that’s difficult to answer in a yes/no manner. So I have five questions that I use, Fede’s Five if you will. They are not a binary, but the five of them together will help clarify things.

1.    Size does matter: If your Enterprise is not above 300+ people, there is very little incentive to go to SAFe. While there are lightweights applications of SAFe, it is designed for a very large number of people in multiproduct Enterprises. Plain Scrum or the Spotify/ING model might be better suited. If you have the numbers, SAFe has the roles for them.

2.    Multiproduct: SAFe thrives on the Lean Portfolio Management system, that created streams for multiple products. If you have just one main product, either LeSS or Spotify might be better (more on those models soon!). But if you have a multiproduct situation, SAFe will help tremendously to organize the streams.

3.    Your products are not mostly push-demand oriented: if your business model is based on SLAs and L3 service, SAFe’s PI planning and long-term roadmaps might hinder more than help. But for stable institutions that seek to become more Agile, like Banks, SAFe can be the right medium.

4.    You have people working on culture and mindset: Any Agile transformation will produce some resistance. I don’t care if you’re the most charismatic individual, you will need people thinking and dealing with the changing mindset via coaching, interventions, workshops, etc. If you do not have people working on that, a less-impactful transformation at first can help convince stakeholders of the need for them.

5.    Finally, you have some experience in Agility in your Enterprise, don’t you?: SAFe runs on Kanban, Lean and Scrum, while adding its own twists. In the case you haven’t got to a comfortable level with any of these methodologies please run a PoC with them first. Trying to learn and implement all three while juggling SAFe also is doomed to fail. But if you have, SAFe provides a stable, proven framework for the next level of transformation.

There you have it: my approach to SAFe in…well, not a nutshell, but certainly less than what is the usual length of text. I hope this has been useful and let me know in the comments if there’s anything you would add or change!

Lately, we’ve been working on several transformations which use the concept of Two-speed IT. It has slowly gained acceptance as a valid alternative to full-scale Enterprise Agility (on which I’ll write something soon).

But being that there isn’t that much information on the subject, I wanted to do a quick write-up.

So, what’s a Two-speed IT approach to Enterprise Architecture?

The Two-Speed IT approach to enterprise architecture is a concept that was introduced by Gartner in 2014. The approach involves dividing an organization’s IT systems into two separate categories: the core systems and the agile systems.

Core systems are the foundational IT systems that support an organization’s critical business functions. These systems are typically stable, reliable, and have a long lifespan. They require a high degree of security, control, and standardization to ensure consistency across the organization. These systems are often expensive to build and maintain, but they are essential to an organization’s success.

Agile systems, on the other hand, are designed to be more flexible and adaptable to changing business needs. These systems are developed using agile methodologies and are designed to be more responsive to new ideas and market changes. They are often less expensive to build and maintain than core systems, but they may not have the same level of security and control.

The Two-Speed IT approach recognizes that different parts of an organization may have different needs and priorities when it comes to IT systems. By dividing IT systems into two categories, an organization can better align its IT strategy with its overall business strategy. The approach allows organizations to balance the need for stability and security with the need for innovation and flexibility, and to adapt to changing business requirements more quickly and efficiently.

Why would you use Two-speed IT?

There are several reasons why an organization should consider using a Two-Speed IT approach. The approach involves dividing IT systems into two separate categories: core systems and agile systems. The core systems are focused on stability and control, while the agile systems are focused on innovation and flexibility. Here are some reasons why an organization should consider using a Two-Speed IT approach:

1. Balance the need for stability and control with the need for innovation and adaptability

By dividing IT systems into two categories, an organization can balance the need for stability and control with the need for innovation and adaptability. Core systems are designed to be stable and reliable, while agile systems are designed to be flexible and adaptable. This allows an organization to maintain the stability and reliability of its core systems while still being able to respond quickly to changing business needs with the Agile systems.

2. Increase innovation and agility

Agile systems are designed to be more responsive to changing business needs, which can help an organization to innovate and adapt more quickly. By using agile methodologies, such as Scrum or Kanban, organizations can develop new systems and technologies more quickly and efficiently. This can help to keep the organization ahead of the competition and improve its ability to respond to changing market conditions.

3. Improve time-to-market

Agile systems can be developed more quickly and efficiently than traditional systems, which can help an organization to get products and services to market more quickly. This can be particularly important in industries where time-to-market is a critical factor, such as technology or fashion.

4. Reduce costs

Agile systems can be developed more quickly and efficiently than traditional systems, which can help to reduce costs. Agile systems typically require fewer resources and can be developed using lower-cost technologies. This can help an organization to reduce its IT costs and improve its overall profitability.

5. Align IT with business goals

The Two-Speed IT approach allows an organization to align its IT systems with its overall business goals. By identifying the areas of the organization where agility and innovation are most needed, the organization can focus its resources on developing systems that will support these goals. This can help to improve the organization’s overall performance and competitiveness.

How would you go about implementing it?

Implementing a Two-Speed IT approach can be a complex and challenging undertaking for organizations. The approach requires the development of two separate IT systems: one that is focused on stability and control, and another that is focused on innovation and flexibility. The goal is to balance the need for stability and control with the need for innovation and adaptability. In this article, we will discuss the steps involved in implementing a Two-Speed IT approach.

Step 1: Identify Business Goals and Priorities

The first step in implementing a Two-Speed IT approach is to identify the business goals and priorities. This involves a thorough analysis of the organization’s overall strategy, business processes, and IT systems. The goal is to identify the areas of the organization where agility and innovation are most needed, as well as the areas where stability and control are critical. This analysis should involve input from key stakeholders, including business leaders, IT professionals, and end-users.

Step 2: Develop a Two-Speed IT Strategy

Once the business goals and priorities have been identified, the next step is to develop a Two-Speed IT strategy. This involves defining the roles and responsibilities of the different teams involved in the approach, as well as the processes and methodologies that will be used. The strategy should be aligned with the organization’s overall business strategy and should take into account the needs of different business units and departments.

Step 3: Create Separate Teams for Core and Agile Systems

The Two-Speed IT approach requires the development of two separate teams: one for core systems and one for agile systems. The core team is responsible for maintaining the stability and reliability of the organization’s foundational IT systems, while the agile team is responsible for developing and implementing new systems and technologies that are more flexible and adaptable to change.

Step 4: Adopt Agile Methodologies

To implement the agile component of the Two-Speed IT approach, organizations should adopt agile methodologies, such as Scrum or Kanban. These methodologies are designed to facilitate collaboration, flexibility, and innovation, and are well-suited to the development of new, innovative systems and technologies.

Step 5: Invest in Training and Development

Implementing a Two-Speed IT approach requires specialized skills and expertise, particularly in the area of agile methodologies. Organizations need to invest in training and development to ensure that all team members have the skills and knowledge necessary to work effectively within the Two-Speed IT framework. This may involve hiring new staff or providing training for existing staff.

Step 6: Integrate Core and Agile Systems

Once the core and agile systems have been developed, the next step is to integrate them. This involves ensuring that the systems can communicate with each other and that data can be shared across systems. This integration should be carefully planned and executed to minimize disruption to business operations.

Step 7: Monitor and Refine the Two-Speed IT Approach

Implementing a Two-Speed IT approach is an ongoing process that requires constant monitoring and refinement. Organizations should track key performance indicators (KPIs) to evaluate the effectiveness of the approach and make adjustments as necessary. This may involve making changes to team structures, methodologies, or technology solutions.

What are the key issues in implementing in, in my experience?

Implementing a Two-Speed IT approach can present several challenges to organizations. Some of the major challenges include:

1. Resistance to change: Traditional IT departments may be resistant to change and may be hesitant to adopt agile methodologies, which can slow down the implementation of agile systems.
2. Cultural differences: The Two-Speed IT approach requires different teams with different cultures and ways of working to collaborate effectively. Core IT teams may be more focused on stability and control, while agile teams may prioritize flexibility and innovation.
3. Integration issues: Integrating core systems with agile systems can be complex, especially if they use different technologies or have different data models.
4. Governance and oversight: Balancing the need for agility with the need for governance and oversight can be challenging. Organizations need to ensure that agile teams are following appropriate processes and procedures to maintain the quality and security of their systems.
5. Skill gaps: Developing and implementing agile systems requires specialized skills and expertise that may not be present in the organization. Hiring and training staff to work with agile methodologies can be time-consuming and expensive.
6. Budget constraints: Implementing a Two-Speed IT approach can require significant investments in recent technology, training, and staffing. Organizations need to balance these investments with other priorities and budget constraints.

Overcoming these challenges requires a thoughtful and strategic approach to implementing a Two-Speed IT approach. Organizations need to prioritize communication, collaboration, and alignment between teams, and ensure that all stakeholders are engaged and committed to the approach.

Conclusion

Implementing a Two-Speed IT approach can be a challenging but rewarding process for organizations. By dividing IT systems into two separate categories, organizations can balance the need for stability and control with the need for innovation and adaptability. To be successful, organizations need to carefully plan and execute the implementation of the Two-Speed IT approach, investing in training and development, adopting agile methodologies, and monitoring and refining the approach over time. With a thoughtful and strategic approach, organizations can realize the benefits of a Two-Speed IT approach, including increased innovation, flexibility, and agility.

So, what are your thoughts? Is it a viable alternative to full on Enterprise Agility models like SAfe for your Enterprise?

Let me know in the comments!

As you probably know by now, I work as a Strategy Consultant in Digital Transformations. I also love both Agile methodologies, with their empirical approach and Storytelling. So, how can we combine them and leverage all the strengths of such a combination?

By using Data-driven Storytelling.

Digital transformation has become a buzzword in today’s corporate landscape. It refers to the adoption of digital technologies to improve business processes, customer experiences, and organizational culture. However, digital transformation is not just about technology implementation; it is also about creating a data-driven culture that leverages data insights to make informed decisions. And the most effective way to communicate these data insights is through storytelling.

Storytelling through data is the practice of using data to tell a story that resonates with your audience. Data storytelling involves presenting complex data sets in a way that is easy to understand and can drive action. With the right storytelling techniques, data can build trust, persuade stakeholders, and inspire change.

Here are some reasons storytelling through data is important for digital transformations:

• Humanizing data: Data can be overwhelming, especially for non-technical stakeholders. Storytelling through data allows you to present data in a way that is relatable and easily understood by everyone. By weaving data into a narrative, you can make it more meaningful to your audience.
• Identifying patterns and trends: Through data storytelling, you can identify patterns and trends that might not be apparent at first glance. By presenting data in a visual format, you can highlight important insights that might be missed in a spreadsheet or report.
• Driving action: Data alone is not enough to drive change. Storytelling through data can help you inspire action by presenting data in a way that motivates stakeholders to take action. By connecting data insights to real-world outcomes, you can create a sense of urgency and purpose.
• Building trust: Trust is essential for successful digital transformations. Storytelling through data can help build trust by presenting data in a transparent and unbiased way. By providing context and explaining the limitations of your data, you can establish credibility and build trust with your audience.
• Fostering collaboration: Digital transformations require collaboration across departments and teams. Storytelling through data can help break down silos and foster collaboration by presenting data in a way that is accessible to everyone. By encouraging stakeholders to share their own data insights, you can create a culture of collaboration and innovation.

In conclusion, digital transformation is not just about technology implementation; it’s also about creating a data-driven culture that leverages data insights to make informed decisions. Storytelling through data is an essential part of this process, as it allows you to humanize data, identify patterns and trends, drive action, build trust, and foster collaboration. By mastering the art of data storytelling, you can unlock the full potential of your digital transformation initiatives and create a more data-driven organization.

Once, I was about to speak to many people, in a corporate environment, about Mindfulness. Someone in the audience raised their hand just as I had presented myself. I stopped and asked them what did they wanted to add.

—This is not one of the meditation-type thingies, right? The person asked me.

—I’m afraid it is, I answered as honestly as I could.

—Oh, I thought it was an affirmation-and-prayer thing; the person told me and got up to leave.

This is the first time I crashed against that dragon, the amorphous nature of the term Mindfulness. I’m not the first one: scholars like Chiesa or McMahan have stumbled onto the same issue. So, as a brief definition, I wanted to propose a quick definition of what Mindfulness is:

Mindfulness is a systemic, organized management of attention and awareness through meditation that stems from Buddhist techniques and focuses on emotions, physical sensations, thoughts, or a combination of those three elements.

So, why is it a system, organized management of attention and awareness?

Because you’re not letting things happen at random. Usually, within the mindfulness techniques, you restrict awareness to a particular sphere of inputs. If you’re focusing on your thoughts, for example, even if the instruction is ‘watch your thoughts come and go as clouds in the sky’, you are not focusing on your body.

Why do I restrict this definition to those that came from Buddhist meditation techniques?

Because most Mindfulness today, especially in the corporate world, is based on John Kabat-Zin’s MBSR program. This program is a medical adaptation of the Vipassana approach to Buddhism. If you have ever done a body scanning, a mountain visualization, Mindful Eating, Mindful Movements, etc, you have just done the same technique that Buddhists have been doing for the last 2.500 years, in a different context.

And why do I put this three focuses (four, if you mix them) on emotions, physical sensations and thoughts? Where is our spirit, our self?

Well… in neither Buddhism nor in cognitive psychology, there is a category like a capital-S Self or spirit. Since Mindfulness’ conceptual framework is Buddhist or Psychology-based, any technique or meditation that is called mindful will inherit one of those two frameworks.

Does that mean that spirituality has no place in a mindful practice? No, not at all. But once spirituality and religion enter the picture, we move away from scientific, corporate approaches to Mindfulness towards religious and/or spiritual practice.

Does this definition make sense to you?

Please let me know in the comments below.

#mindfulness #corporatemindfulness #meditation

(This is a continuation of our #storytelling series, specifically https://federicoandino.com.ar/2022/08/23/storytelling-crafting-an-origin-story/)

You have crafted an elevator pitch Origin Story. Something that you can actually pull off the cuff, that can help you drive your brand.

But what can you do when you need to craft a longer story, not for improvised storytelling, but deliberate storytelling?

Let me introduce you to the greatest crossover in structures of the last hundred years: the three-act structure x the hero’s journey.

We’ll cover each more in-depth in the future, but let’s start with something actionable: crafting a longer-form Origin Story based on it.

We have to cover three acts, so the basic structure is:

1. Beginning
2. Conflict
3. Resolution

This we could very simple summarize at the product level with:

1. Idea
2. How we created the product
3. Where we are nowBut let’s make it more interesting with a little of Hero’s Journey. Let’s reframe the Three Acts:

1. The Opp: You saw it. This is when you explain what makes the product or your brand different. It can be context; it can be the product itself. But this is you being bitten by a radioactive spider. It is what defines the story.
2. The Struggle: unlike the “how we created the product” story, here the focus is on what the challenges were. Was that it was so new? Did you face shortages in production? Was your particular brand seen as disruptive? The focus here is not only on the challenges, but in the overcoming of them. We want to tell the story of us triumphing, but that only has value in relation to the challenge itself.
3. The Product: After all the struggle, how did your product or brand change? You cannot have the same thing as when you began. It will surely have changed. Perhaps some products or some brands triumphed almost at the gate, but those were inheritors of other attempts. If you share not the product but the experience of the creation, it is easier to become invested on it.This is a very easy 1-2-3 structure, but it remains a classic for a reason. Keep it and you will see how your own Origin Story takes form.

Once you get it into the structure, check these six points to make sure your story will connect to your audience:

• Tone: keep it light, keep it entertaining.
• Truth: don’t exaggerate or lie. One person who catches you and there goes your audience.
• Fails: Keep those occasions when you failed in. It makes the eventual success sweeter.
• 1st Person: telling a story this way resonates a lot more than the third person, since it sounds like a report. Telling in the 2nd person is trickier, but an interesting approach.
• To the point: trim the fat. We should summarize things that repeat themselves. We should highlight things that require special attention.
• Short: don’t beat around the bush. Keep the story moving. Aim at five minutes of total time.
• Record yourself, first on voice and then on video. See how it plays. And if you like, share your Origin Story on the comments! Next time, we’ll focus on the Hero’s Journey and how it can help (or hinder) Storytelling. See you soon!