APPENDIX C: LEAN, DEVOPS AND AGILE SIAM
SIAM is most commonly applied to IT and digital environments, products and services. The IT world changes rapidly, both in terms of technology, and also in terms of ways of working. This has led to suggestions that SIAM also needs to evolve, with terms such as ‘Agile SIAM’, ‘Digital SIAM’ and ‘Lean SIAM’ being used in presentations and discussion forums.
The SIAM Foundation BoK provides some considerations for applying various concepts and principles from DevOps, Agile and Lean in a SIAM ecosystem. The fundamental principles of SIAM do not change, but how service providers work together, the level of automation, governance considerations and the type of collaboration that takes place may need to adapt to embrace these changes.
This appendix provides an overview of how principles within Lean, Agile and DevOps can be considered within the SIAM roadmap and incorporated into the SIAM ecosystem. If the customer organization, service integrator or service providers already have proven capabilities in these areas, that can add value across the whole ecosystem. The service integrator will need to consider when, where and how to apply these ways of working.
SIAM and Lean
Lean principles are often employed by organizations seeking reduced costs and increased speed and quality for their products and services. Lean seeks to optimize flow and create a supportive culture focused on stability, standardization and reduction of waste. If your organization is already using Lean principles, it can add value in a SIAM ecosystem because of its focus on end-to-end value chains, collaboration, cooperation and flow.
Discovery & Strategy: Lean considerations
In the Discovery & Strategy phase of a SIAM transition, a clear vision is essential. In Lean terms that means applying the practice of Nemawashi and Hoshin Kanri, where influencers and stakeholders are prepared for change, and where the strategic decisions are well considered and communicated to stakeholders.
Nemawashi
Nemawashi is a Japanese term (
) for an informal process of quietly laying the foundation for a proposed change or project, by talking to the people concerned, gathering feedback and generating support. It is considered an important element in any major change, before any formal steps are taken, and successful Nemawashi enables changes to be carried out with the consent of all stakeholders.
Nemawashi literally translates as “going around the roots”. Its original meaning was literal: digging around the roots of a tree, to prepare it for a transplant.48
Hoshin Kanri
Hoshin Kanri, another Japanese term (
), also called Policy Deployment, is a method for ensuring that the strategic goals of an organization drive progress and action at every level within that organization. This eliminates the waste that comes from inconsistent direction and poor communication.
Hoshin Kanri strives to get every stakeholder pulling in the same direction at the same time. It achieves this by aligning the goals of the organization (strategy) with the plans of middle management (tactics), and the work performed by all employees (operations).49
For both Lean and SIAM environments, strategic intent should be based on customer value. When undertaking the analysis activities during this stage it is useful to apply Lean techniques, such as value stream analysis and root cause analysis. These will support landscape mapping and help to ensure that any ‘as is’ design impediments in processes and services are understood.
Plan & Build: Lean considerations
In the Plan & Build stage, organizational change management (OCM) activities begin. Like SIAM, Lean principles emphasize the importance of engaging with those who will be working within the SIAM model. As much as possible, stakeholders need to be actively involved in decision making about the ecosystem.
When designing the SIAM model, a Lean approach would consider simplifying workflows by minimizing handovers and avoiding long cycle times in process activities. In a SIAM model where processes need to be adapted to cater for complex models involving multiple service providers, this can be challenging. Throughout the Plan & Build activities, a focus on Lean principles will help to avoid over complication of activities, duplication and missed tasks, and optimizing workflows.
Implement: Lean considerations
When transitioning to a SIAM model both big bang and phased approaches are possible. Lean principles suggest a focus on single-piece-flow and small batches of work to avoid creating dependencies based on a deadline. Lean organizations would be likely to support a phased approach to transition, which allows for re-work between phases, and knowledge building and improvements.
Run & Improve: Lean considerations
Improvement has a high priority in organizations following Lean principles. Within a SIAM model, organizations can also utilize a Lean approach to improvements. If techniques such as Kaizen are already in use in an element of the SIAM model, they can be extended across the ecosystem.
Kaizen
Kaizen is a concept referring to business activities that continuously improve all functions and involve all employees from the C-suite to the operational personnel. Kaizen (
) is the Japanese word for ‘improvement’. Kaizen also applies to processes that cross organizational boundaries and, as such, may be useful within a SIAM ecosystem.50
Kaizen refers to business activities that involve all stakeholders, or layers within a SIAM model. It seeks to continuously strive to improve ways of working, and as such, the service integrator could use Kaizen techniques when working with the service providers and the customer organization.
Like SIAM, Lean supports principles such as ‘fix first, argue later’ and discourages blame assignment, instead encouraging effort to be focused on root cause analysis, building quality and removing waste.
One Lean principle, Kaikaku, also prepares an organization for more large-scale changes.
Kaikaku
Kaikaku (
) is the Japanese term for ‘radical change’. In business, Kaikaku is concerned with making fundamental and radical changes to a production system, unlike Kaizen, which is focused on incremental changes. Both Kaizen and Kaikaku can be applied to activities other than business as usual (BAU).51
Kaikaku is most often initiated by senior management. In SIAM, it could be initiated by a strategic or tactical board decision. It is intended to deliver significant impacts. Like other Lean approaches, Kaikaku is about introducing new knowledge, strategies, approaches and improvements to operational delivery. This scale of improvement is likely to be prompted by external factors, such as strategic change, market conditions and technology change. In a SIAM model, this could be linked to changes in the ecosystem, such as the addition or removal of a service provider.
Lean principles would support a SIAM ecosystem with a focus on standardization and waste elimination, without compromising on quality, cost and lead times.
Andon Cord
The Andon Cord is a concept from the Toyota Production System (TPS). Originally, it consisted of a cord or button that workers could use to ‘stop the line’ and halt production, to warn managers of an issue or potential issue. When the cord is pulled, managers and team members ‘swarm’ to the issue and carry out an investigation, and where necessary, resolution.
The Andon Cord is effective in a high-trust environment where workers feel safe and know they will not be blamed or punished.
In a SIAM ecosystem, the Andon Cord would be a virtual concept, rather than a physical stop on a production line. Some multi-provider environments suffer because service provider staff do not feel confident about highlighting an issue, so manual workarounds or extra tasks are carried out unnecessarily. This can affect the quality of service received by the customer organization. The service integrator needs to work hard to create a high-trust culture where all service providers can feel confident to ‘pull the cord’, and where service providers work together to resolve issues that may be affecting them despite being outside of the scope of their contract.
SIAM and DevOps
Organizations utilizing an effective DevOps approach aim for a high degree of collaboration and mutual respect, as well as an appreciation of both the Dev and Ops considerations, goals and ways of working. Some organizations build multi-skilled teams including Dev and Ops competencies, and some keep the two disciplines separate and focus on collaboration.
DevOps values include a commitment to automation. Some organizations suggest that if a task is carried out more than twice, it should be automated (linked to the DevOps principle, “Improving daily work is more important than doing daily work”). This can also be applied to SIAM ecosystems, looking for ways to improve collaboration and integration between service providers.
Care must be taken, however, to build systems that still allow for service providers to be added and removed, when necessary, to retain the SIAM benefits of loose coupling.
The SIAM model needs to balance the benefits that DevOps ways of working can deliver with the complexity of the sourcing environment.
Discovery & Strategy: DevOps considerations
The governance model to support the SIAM ecosystem is an important output from the Discovery & Strategy stage of the SIAM roadmap. If the model also includes the use of DevOps principles, this approach will need to specifically consider boundaries and accountabilities. SIAM models often focus on the SIAM layers and the service groups, whereas DevOps maps structure at a technology or platform level, with links between application teams and platform teams.
Application teams often organize themselves using principles derived from Scrum or other Agile frameworks. In these structures, a hierarchy of decision points is designed to match the structure and architectural dependencies of the application. The SIAM governance model applied to DevOps teams needs to be aligned to current ways of working and decision making to preserve the autonomy of the teams.
Typically, DevOps teams have autonomy over a large portion of the application technology stack and processes, architecture and software deployment pipeline. They will typically engage in incident and problem management activities, as well as development activities. The SIAM model may need to reflect this way of working rather than forcing a rigid divide between Dev and Ops. This needs to be balanced against any separation of duties required for governance reasons. If the service desk is sourced by one of the external service providers in the SIAM model, consider how it will share knowledge with DevOps teams, and how DevOps teams will have visibility of issues.
In DevOps, application service provider teams own their product or service from inception to delivery. During Discovery & Strategy, this level of autonomy and accountability must be understood, and as much as is practical, be built into the model.
Plan & Build: DevOps considerations
If the SIAM model needs to align with DevOps ways of working, the Plan & Build stage is very important in establishing the key principles and concepts. The process models, governance model, collaboration model and tooling strategy all need to reflect how the ecosystem will work. The DevOps values of culture, automation, Lean, measurement and sharing can be used as a guide to help blend DevOps into the SIAM model.
Service providers that join the ecosystem need to have their DevOps capabilities assessed, and DevOps principles need to be covered during the onboarding process.
Autonomy versus control
Product and service teams that are used to working with DevOps need to be carefully integrated into SIAM models. The increased number of service providers involved in the ecosystem may mean that the team needs to share more information externally, which might be a new requirement contrary to the existing culture. If some teams continue to behave with complete autonomy and disregard for other service providers in the SIAM model, there can be negative consequences.
For example, a case brought negative media attention to a service provider of payment services when all the ATMs in Austria went down. The service provider had not been informed about a change made by a DevOps team that was part of the same SIAM ecosystem. That change caused the failure of the ATM network, and significant reputation damage to the customer organization.
Implement: DevOps considerations
A phased approach to a transition to SIAM is more aligned with DevOps principles, but this will also depend on the real-world conditions, requirements, contract end dates, etc. For existing products and services developed and supported by DevOps teams, knowledge transfer and handover activities are essential. Small teams may have a great deal of knowledge that can be lost in the handover to another service provider.
Run & Improve: DevOps considerations
DevOps principles focus on feedback, and learning and experimentation. If these are already embedded in all or part of the SIAM model, they can be used to help support improvement activities. If one service provider, the service integrator or the customer organization has strong capabilities in these areas, the service integrator can focus on propagating this approach across the ecosystem.
SIAM and Agile
Many organizations still apply traditional command and control structures, with management hierarchies where goals and decisions flow from top to bottom. These organizations typically use linear planning and control mechanisms. In comparison, an Agile organization consists of cross-functional teams in a people-centric environment. It aims to drive value through iterative and incremental product and service development, with frequent feedback from customers. A SIAM model needs to enable cross-functional teams working across the layers, functions, processes and services. It is important to consider the impact of this Agile approach on the SIAM strategy, structure, processes, people and technology.
Discovery & Strategy: Agile considerations
Within the Discovery & Strategy stage of the SIAM roadmap, stakeholders can learn from and use Agile principles and techniques to support their activities. A SIAM transformation often follows an iterative and incremental path, with some activities repeated based on new information.
A SIAM model needs to foster trust, eliminate micro-management and devolve responsibility within the boundaries of an agreed governance framework. If the customer organization or service integrator has agile capabilities, they can use these to define roles and structures for self-governing teams that will fulfil these objectives. Agile leadership focuses on enabling, not controlling, through a culture of experimentation and learning. This integrates well with the SIAM culture of collaboration and innovation.
Plan & Build: Agile considerations
Both SIAM and Agile environments put a great deal of emphasis on the importance of effective cross-functional teams. A cross-functional team, such as a working group or forum, may include personnel from all the SIAM layers.
Agile approaches can be used to establish effective team dynamics, flow and knowledge sharing using improvement iterations to reduce complexity and improve the feedback loop to the customer.
The right balance between self-managing teams and governance is an important consideration in any environment, but especially so when considering the balance between an agile approach and the governance framework with a SIAM model.
Implement: Agile considerations
Self-organizing teams in Agile and SIAM
Self-organization is a fundamental concept in Agile methods and approaches. A common misconception is that because of the resilience of self-organizing teams, there is little or no role for governance and control. However, it doesn’t mean letting people do whatever they want to do. Self-organizing does not mean no governance or control, it is defined and evident but exercised in a more subtle and indirect way.
Self-organizing teams are based on empirical control. The control is exercised by selecting the right people, creating an open environment, an evaluation system of group performance and encouraging providers to become involved early, not forcing or controlling them.
An Agile team’s job is to self-organize around the challenges, and within the boundaries and constraints put in place by the organization and management, which varies from organization to organization and environment to environment. Individuals self-organize around a problem that is presented to them, but operate within defined boundaries. It is important when building a SIAM governance framework to ensure that this opportunity is not restricted.
Run & Improve: Agile considerations
SIAM structural elements can be integrated with Agile approaches and methods. Agile practices, such as standups, retrospectives, visual techniques, reviews and sprint planning, are activities that can be used to help working groups and process forums to be effective. For example, retrospectives can be used to assess process performance and ensure there is ‘just enough’ process in the SIAM ecosystem.
Agile uses tools and techniques, such as the product backlog and backlog grooming, to document and prioritize activities. Backlog items are discussed by the team, focusing on how important something is, how long it will take to accomplish and how success will be measured. These techniques can also be applied to SIAM transformations to help facilitate conversations between stakeholders and develop realistic plans.
It is important to have frequent reviews and showcases at the end of each Implement increment. This allows stakeholders to inspect and adapt based on early feedback. In a SIAM model, both process forums and working groups can support these activities.
48 For more information, visit: https://kanbanzone.com/resources/lean/toyota-production-system/nemawashi/.
49 For more information, visit: www.leanproduction.com/hoshin-kanri.html.
50 www.kaizen.com/what-is-kaizen.html.
51 https://en.wikipedia.org/wiki/Kaikaku.