Hello and welcome to my page, the meeting point of my activities. My name is Fede Andino and I’m working at something that I’ve named Culture Crafting. It’s not something very solid yet.
There’s a classic book. the Cathedral and the Bazaar. In it, there are two models presented for something that is built: a Cathedral, an organized vision of a particular mind and a Bazaar, an organic aggregation of ideas and people over time. My art is not a cathedral, nor yet a bazaar but rather a well-attended Inn at the crossroads of IT work, Management, Mindfulness, Agile, Lean and Storytelling. In time, it is my hope that it may be a bazaar or its even better cousin, the Souk: a vibrant place with a lot of tradition. But it is not there, yet. It’s just a cozy inn, at this time.
In this site I’ll post my work ideas, my pics and videos and also all the social networks that I’m currently working on.
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:
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.
· 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.
· 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:
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.
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.
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.
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.
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:
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.
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.
Integration issues: Integrating core systems with agile systems can be complex, especially if they use different technologies or have different data models.
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.
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.
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.
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?
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.
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:
This we could very simple summarize at the product level with:
How we created the product
Where we are nowBut let’s make it more interesting with a little of Hero’s Journey. Let’s reframe the Three Acts:
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.
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.
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!
Let’s say that you’re a consultant. Or a salesperson. An executive. A teacher.
Someone who starts tomorrow at a new job.
What do all these activities have in common?
At some point, you will introduce yourself.
Now, you might think that is as simple as saying your name. But that’s not so; after all, there’s no second chance for a first impression, so if you botch it, you’re already losing some power in the eyes of the beholder.
Worse, it might not be what you say, but how you say it. So many people mistake a particular cadence and pronunciation for intelligence and expertise. Yes, a mistake, but one that will color their perceptions of you.
Luckily, we have access to a particular type of introduction that, repeated until it faded into the background of our mind, has power: the Origin Story.
There’s a reason Marvel, DC and Universal keep pushing new hero movies, with the Origin Story at the forefront: often it is both the most powerful, defining and profitable use of their highly focused storytelling.
How can we leverage this into our storytelling practice?
There are two ways that I teach to do this: a simple way and a more involved way.
Let’s go today with the simple way. This is based on our storytelling practice at IBM, which is heavily based on Shaw Callahan’s Putting Stories to Work. This way is a variation of the Solution Story Archetype and it is told within 3 minutes, so a pretty quick intro.
It goes like this:
1-The Idea: This is the beginning of the story. We should mention your name quick, but in passing, you want the audience to focus on your particular characteristics, which don’t include your name. Focus on a dream, an idea, or something that makes you stand out.
“Hi everyone, my name is Ivan and from a very early age, I was into meditation. I read as much as I was able and spent some time in a Zen temple.”
2-The Fight: any superhero worth their salt needs some conflict. Be careful not to over-emphasize this, but frame the conflict around your idea.
“But when I worked at office jobs, everyone thought that the same meditation, which made me happy and creative, was basically a hippie thing. I was at a Fortune 500, but every time I tried to take a break, it was non-productive time. This was a significant source of unhappiness to me.”
3-The Leap of Faith: at some point, you took action. You took that which made you different and had the courage to move ahead. Now, be gentle here: you need to let the actions speak for themselves.
“So I had to choose: follow what my experience told me or what I was told day after day. I quit my job and created the first consultant firm for Corporate Wellness in the city.”
4-The Payoff: this makes people interested in you. It should be something relatable. If your story is becoming an academic in an obscure field, people will struggle to connect to it. Make it simple.
“So now I can work at the same companies that before, but on my terms, making the office space better for everyone; by doing what I love.”
It’s easy, right? 1-2-3-4.
There are some tricks to it.
Before rolling this out, please do:
Start by writing it out. It can be larger than the example, but remember: only 3 mins of spoken lines in a relaxed voice.
Once you have it, edit it and try it out.
Keep the tone light and friendly. Get a joke or a smile when you can, don’t force it.
Time yourself telling it. Record it and listen to it.
Now, once you have a story that you think is good enough, practice it. You want to practice it to the point you can tell it off-the-cuff. You never know when it is going to be your turn. They have invited me into meetings “just as a listener” and suddenly I was telling who I was to boards of Directors. You don’t want to fumble or change the story once you’ve started. A confident rhythm and delivery is key.
This is a very simple, pre-made general Origin Story. We’ll cover soon the more complex, customized to your audience story.
One of the more complex challenges that we face in transformations is where the Agile Lead of the client is not fluent in Agile. Since we need to work with the Agile Lead / COE Lead head-to-head, it’s a key position for us.
In a perfect scenario, the Agile Lead is a mature Agile practitioner, but sometimes we have people who have received the ownership of the Agile dimension of the transformation with no experience. So, how can we transform this into an opportunity? How can we overcome the sponsor’s dysfunctional choice?
Before we can answer that, we need to distinguish the Agile Lead that we have to work with: are they an Agile Discoverer or an Agile Strikebreaker?
Challenge: support them to gain experience swiftly
Opportunity: Sounding Board
Tactical actions: Focus on both certification and hands-on laboratories
Agile Discoverer is an archetype that we run once in a while. It’s a lead that the enterprise sponsor thinks has the knowledge of agile and they don’t, or the right attitude. Either way, they do not have the experience necessary to help in the transformation.
This is an excellent opportunity: we can help them both gain the experience in Agile and in a transformation at the same time. Another advantage that this kind of Agile Lead has is that, being part of the organization but being relatively new to Agile, he or she can be a great sounding board for the opinions of the rest of the organization.
What can we do to empower the Agile Discoverer?
Pathfinding: We can create career paths and archetypes that map the ideal Scrum Master, ART, PO, etc. In that way, we can build up their general knowledge and also help them map certifications and courses.
Roleplaying: By existing a large experience gap, we can help them as consultants by showing them an embodied Agile perspective that they can gradually step into.
T3 (Train The Trainers): Being an Agile Lead, we probably expected them to coordinate and facilitate training. By focusing on a T3 approach, we can speed up their experience and quickly get to where we know if we’re going to need third-party facilitators.
The Agile Discoverer dysfunction is not a terrible situation; yes, it will probably require more work, but it is well worth it.
Challenge: attrition-based death of a company
Opportunity: Non-Violent Communication
Tactical actions: Reduce and contain damage while extracting yourself
An Agile Strikebreaker is a different dysfunction. This is not someone who has received a responsibility without having the means to uphold it. This is someone who is actively against Agile principles, and yet is theoretically their champion. Maybe there is a particular sponsor that wants the transformation poisoned and has prevailed to nominate them. Maybe they’ve lied about their qualifications or mindset and now it’s too late and they are the Agile COE Lead. But what it boils down is that they will undermine Agile principles and mindset while claiming to uphold them.
You can expect things like:
Asking for a commited, multiepic release plan with fixed dates
A focus on nonessential metrics
Manipulation of indicators that show agile maturity
Redefinition of roles and methodologies away from their accepted meaning to conform to a customized Agile which will tend to Waterfall
The result of this is not only complex for you; but for the company. Most Agile specialist are very in-demand. If you want to force them to work in a manner that is anti-ethical to their principles, they will leave en masse. This will soon reduce any profit that the company can generate and stall every single part of the transformation.
You also need to exercise great care in communication. Since the Agile Strikebreaker cannot let you advise to generate more agility, he or she will try to force and redefine every aspect of what you propose. From bitter experience, I know how difficult is to work with someone who lies through their teeth. A framework that allows you to remain professional and focused, like Non-Violent Communication, can be a great help.
Ultimately, what you can do with the Agile Strikebreaker boils down to the relationship that the sponsors have with you and with the Strikebreaker. If they are unaware that the situation is like this, there is a possibility that they are open to change. Here, clear reasoning and concepts are key; It should articulate the major thrust of the argument for a change in terms of the losses that the company will face if in the future, not only for the transformation but for any project undertaken under the guise of the “agility” which the Agile Strikebreaker espouses.
If the sponsor is aware of the situation, the best course of action is to limit the damage and slowly extricate yourself of the situation. It doesn’t matter why they poisoned the transformation. Perhaps it was an internal power struggle. Perhaps they signed and then they realized it was too much effort. The bottom line is that you are trying to swim with a heavy anchor attached to you. I have found that the best way to deal with these situations is to elegantly remove yourself from it.
Do you have other strategies to deal with Discoverers and Strikebreakers?
Let’s focus on the first step: finding a partner that has done it before.
Why? Why should you need a partner for a transformation?
There are several reasons for having a partnership in a Digital Transformation process:
You will not probably have the number of people who can leverage the Transformation within a reasonable amount of time.
You won’t also have dedicated resources, unless your business IS DTs (in which case, you are the partner)
Even if you have people who have been through a DT before, you need the experience that only comes after having done many DTs.
Ready-made content and training will reduce cost and duration of the DT.
But the more important reason is that a suitable partner can help you envision the transformation itself and how can you measure its impact, value and effort, reducing the resistance you’re going to face.
Because you’re going to face resistance. There’s no such a thing as a frictionless organization.
So, let’s say that you buy this. This is how you start:
First, of course, you create consensus on the leadership of the organization. I’ve seen more DTs that I can count derailed by having just the support of the sponsor. Everyone doesn’t need to agree on everything, but there should be a broad consensus that a Transformation it is both desirable and necessary.
Then, we move onto metrics: How are we going to know if we’ve achieved the DTs? Are we going to look primarily at methodologies? Are we going to be focused on Value? Time 2 Market? What are our driving concerns and pain points? We don’t actually need to list the metrics involved, but we need to have a rough consensus of what type of metric are they. They will guide our search in the next step.
The result that you want will dictate the search for the right partner. Looking for a focused, Journey-to-Agile short impact transformation? Then a good specialist provider in Agile Coaching can be a good bet. Bigger Enterprise Cultural Transformation? Find the experts with a wide base of people and experience in Enterprise Agility.
Once you have someone you think might be a good fit, you can do this to gauge their compatibility: ask them to tell you a story. In the past, when has a DT clicked for them? What were the challenges of the Client? Do they seem familiar to you?
You are trying to craft your own Origin Story and to see if the potential partner’s a match, you need to see if they have what it takes to help you.
Your Origin Story is the first artifact of the transformation. It will answer the first question anyone in the organization will ask themselves: Why, oh why, are we doing this?
And we’ll soon broach some structure ideas for the OS. But for now, you should be set to look for a partner.
At my first corporate job in the 1990s, I used to work on several projects with someone nicknamed The Futurist.
The Futurist was called that because, at the beginning of each project, he would calmly tell you: “You know, this project will go this way, it will probably crash because of this and we’ll be back here in three months.”
This was usually spot on. It wasn’t an ironic nickname. The Futurist’s prediction came to pass.
So, a couple of months, I asked him: “Then, why we do it at all?”
His answer: “This is the way projects are done.”
That answer never satisfied me. When I worked alongside The Futurist, he would work on things that he knew that were useless. In the projects, they would discuss everything perfunctorily and then push on ahead. When questioned, the usual answer was: how do you get experience if you don’t work, then?
Almost a lifetime later, this answer still rings hollow to me.
Experience, theoretically measured by seniority, is just not a matter of simply doing work. You can keep working and be able to forecast a project’s fate, like The Futurist could, but I wouldn’t call that experience. The Futurist had worked for a long time, but that work hasn’t translated into experience and seniority.
This translation’s not automatic. It takes time and effort.
We can think of the generating of experience as four steps; four steps that should be the base for all Retro ceremonies within Scrum, but even outside Scrum, they are precious.
The Four Steps are:
Do The Work: you need to put the time into doing things. You need to fail fast. You need to test your hypothesis. This means two things: getting your hands dirty and getting things done.
Reflecting Together: Every once in a while, reflect as a team. Yes, self-reflection is a vital part of your personal journey. But as long as you are in a team, working towards a common goal, reflection needs to be refined and validated between you all, like anything else.
Getting Feedback: Even if you do your reflection, feedback is the blood that drives improvement. Metrics, pulse surveys, business results. Crave them.
Implementing Changes: So, you have your feedback. You brainstorm, you reflect, you know what to do. It is vital that you do it. While seemingly a trivial thing, I’ve lost count of the number of groups that I’ve seen that know what to change, but never get around to change it. Don’t be like them.
These Four Steps are deceptively simple. What’s hard is the discipline needed to always implement them. But if you achieve it, you move beyond The Futurist into the Changer of Ways, the most important of the archetypes for a Transformation. In order to become that, change yourself.
Learn. Become experienced. Don’t accept things as they are, but always strive to learn. Don’t accept the future just because you see it. The big difference between The Futurist and the Changer of Ways is not the knowledge of what is coming. In that, they are matched.
The difference is on the experience and seniority needed to know that change is possible. And to get there, you need to create both those qualities out of the alchemy of work, reflection, feedback and change.