BVSSH stands for Better Value Sooner Safer Happier, which are the primary outcomes of an Agile transformation. Indeed, Agile is not an end in itself, but a means to deliver better results. In their book, Sooner Safer Happier: Antipatterns and Patterns for Business Agility, Jonathan Smart and his colleagues introduce the outcomes of an Agile transformation. They then reference the principles of a successful Agile transformation as patterns and anti-patterns.
- BVSSH: Better Value Sooner Safer Happier
- Guidelines for a successful Agile transformation
- Key success factors for a successful Agile transformation
- What’s next? Learn more about Agile Leadership, Agile at Scale, Lean and DevSecOps
- Do you want to learn more about the topic? Here are some valuable references
BVSSH: Better Value Sooner Safer Happier
To begin with, let’s review the outcomes of an Agile transformation.
Better
Better stands for Quality that is a crucial outcome of an Agile transformation. It encompasses both production quality, with fewer production incidents, and development quality, with fewer defects and reworks. Additionally, it involves being proactive rather than reactive, with better resilience in production and faster means time to recovery. The code also has a better capacity to evolve with an improved architecture and less legacy code. Quality is built into the flow rather than inspected at the end of development.
Value
Value is another important outcome of an Agile transformation. It involves meeting and even delighting the expectations of clients or users of the product. Without a doubt, this is how businesses reach their objectives.
Sooner
Sooner, the time to market, is also a significant outcome of an Agile transformation. It means a shorter time to learn, remove risks, adapt, and pivot ideas and deliver solutions. For sure, achieving this requires optimizing the flow to deliver fast, efficiently, but still safely to clients and users.
Safer
Safer covers Governance, Risk, and Compliance (GRC). It includes the security of information and data privacy, compliance with regulations, and the resilience of the solution. Whatever the threat, whether a cyberattack or a global issue. Truly, the challenge is to have control without compromising speed.
Happier
Lastly, employees also benefit from an Agile transformation that improves their work environment. The authors even go further, embracing citizens and the environment with a positive impact on society and the world. Clearly, benefits in other dimensions listed above should not come at a cost to human beings and the planet.
Of course, all these dimensions balance each other. So there is an equilibrium to reach between them.
Patterns
The book Sooner Safer Happier: Antipatterns and Patterns for Business Agility provides about 30 patterns for a successful Agile transformation. Therefore, we will review a simplified version of these concepts that support a successful Agile transformation. We will consolidate them into two groups :
- The guidelines
- The Key Success Factors
Guidelines for a successful Agile transformation
Outcomes oriented transformation
Agile is a means to deliver better outcomes, not a purpose in itself. The expected outcomes of an Agile transformation are Better Value, Sooner, Safer, and Happier. Therefore, the Agile transformation should be driven by these expected outcomes from the start, rather than just deploying a body of knowledge.
Additionally, the “why” of the transformation is essential. All the more that improving these outcomes is already part of the purpose of all organizations. In other words, it is an opportunity to leverage intrinsic motivation as the driver of the transformation and avoid the trap of a mandatory transformation. Indeed this is a situation where people just comply, missing the main benefits and sustainability, or resist.
Descaling before scaling
Before considering to scale Agile, it is essential to rethink your organization. Truly, building Agile on top of bureaucracy and complexity is not relevant. This requires courage and empowerment to change long-lasting ways of working.
You don’t scale a complex system by aggregation or imitation but by decomposition to an optimal level of granularity followed by recombination in context.
Besides the experimentation approach mentioned above, it is crucial to identify and break dependencies to decrease bottlenecks and coordination needs. As a result, this increases the autonomy of teams.
VOICE your own transformation
The approach to business agility is not one-size-fits-all. The author explains that each organization is unique, so you should build your way to business agility. To do so, the book proposes a framework to structure your way to agility.
VOICE stands for the dimensions of this framework that we will review below :
- V = Values & Principles
- O = Outcomes & Purpose
- I = Intent-Based Leadership
- C = Coaching & Support
- E = Experimentation
Values and Principles
Values and principles are the behavioral guardrails that apply to any context in a company. Of course, they are specific to your organization. While principles apply across contexts, the way to meet them may differ. Thanks to coaching and experimentation, teams take ownership of their transformation to find the best way to apply these principles to their context.
Outcomes and Purpose
The outcomes are the reason and the motivation for the transformation. As we described earlier, they are Better Value, Sooner, Safer, and Happier. Furthermore, it is essential to connect these outcomes and the “why” of the transformation. Then measure outcomes often in a short feedback loop.
Intent-Based Leadership
First of all, Leaders go first as we will develop below in the Key Success Factors of a good Agile transformation. For sure, they should role model desired behaviors like psychological safety and inclusion. This is the best way to support the transformation.
Secondly, Leaders of the organization should empower their people by building decentralized decision-making and fostering high autonomy within high alignment. This is usually a move in most companies away from command-and-control, micro-management, and in some cases, a culture of fear.
Coaching and Support
A transformation requires support to learn but also unlearn, to remove impediments from the road of the transformation. To do so, you need a team of coaches across the organization. To illustrate, they will leverage their knowledge and experience, adapt them to fit your organization, and support the whole company, including managers, to move in the proper direction to make it more Agile and get the outcomes.
Clearly, support of leaders at all levels is critical to support the transformation and the sustainability of change. This team of coaches should report to someone on the Executive Committee. So that organization impediments have their attention to be fixed quickly.
Experimentation
Organizations are complex adaptive systems, so change should be emergent with quick feedback to minimize the time to learning. As a matter of fact, change comes with experiments that test a hypothesis to validate for the organization or for a specific context. Moreover, each learning loop elaborates on the previous ones, building on learning and addressing the remaining uncertainties.
As learning grows and the organization gets confident, the perimeter of experimentation grows. Team, teams of teams as a value stream, then whole business units, and at last, organization levels.
Impediments are not in the path; impediments are the path.
Once the foundations are in place, it does not stop. Indeed the balance switches from learning to improving in order to reach mastery.
Invite for the transformation
As a result, the author stresses that you should empower the “how” as it is emergent. Indeed, a transformation will first rely on innovators, then early adopters, as Everett Rogers explains it in his model of diffusion of innovation. As a matter of fact, the corporate antibodies are strong at the start. Definitively, the key is to invite volunteers who are excited by new ideas and who have probably been working with part of Agile yet.
In addition, as Martin Fowler, an Agile Manifesto signatory, explains that imposing Agile on a team is totally contradictory to the principles of agile. In other words, self-determination is at the heart of agile thinking. Clearly, the teams should be able to choose their process and control the way it evolves. Apart from that, the sustainability of change requires it.
Small increment transformation
As part of the approach to address resistance to change and to properly adapt the Agile framework and the transformation approach to the organization, the author underlines the need to start small with small teams and small perimeters. Really, this decreases the risk, so it fits in the risk appetite of the company. In addition, makes it possible to shorten benefits: learning, building success stories, and delivering value to the organization.
Once you have conducted some transformations with innovators, you should still work with small experiments. As a matter of fact, the return of experience is based on unique context perimeters and with an appetite for risk. With early adopters comes the step to build some recurrent patterns. As a result, the organization does not reinvent the wheel each time. Truly, a collection of success stories is key to onboard early, then late majority.
Transform vertical slices of the organization
The author highlights that to avoid small Agile pockets and a lack of middle and senior involvement, it is important to transform a vertical slice of an organization. Indeed, a “confetti” transformation results in local optimization with a limited impact end to end.
If I agree with the rationale, I will challenge the timing. My experience is that it requires a lot of marketable successes to reach a high enough sponsorship on the business side to be able to transform a full vertical slice. Nevertheless, this should be the target, as this is where the outcomes are.
So the author advocates transforming a vertical slice of an organization with representatives from every level, including the Executive Committee, as soon as possible. This multidisciplinary IT and business perimeter is aligned by a value stream or a sub-value stream.
Key success factors for a successful Agile transformation
Leadership and Psychological Safety
Leadership will make it or break it.
The origins of word leadership are related to guiding on a journey. Without a doubt, Leadership is critical in an organization’s journey of deep change. As the origins of the word stress, leaders should lead from the front. In other words, they should role-model the change to happen. Not only to support the change, but also because they are a necessary part of the change.
Transformational Leadership
James Burnsin’s book Leadership introduced the notion of Transformational Leadership. And Bernard Bass further elaborated on the concept. The latest, described the four components for transformational leaders to inspire followers, so they can achieve extraordinary outcomes.
The four components are:
Role Model
The leader is a model about how to behave, a role model. When respected and trusted, followers take leaders as models. So these leaders should embody the values that are desired and demonstrate them with what they say and do consistently.
Vision
A clear vision of a future state that inspires followers thanks to a higher-level purpose.
Intellectual Stimulation
The leader challenges the followers, so they think about problems in new ways, challenge the status quo, and question assumptions. This requires a work environment open to new ideas, experimentation, and risk-taking to learn, not blaming in case of failure of an experiment. In other words, an environment of psychological safety.
Coach
The leader coaches and makes people grow by adopting the stance of a coach. Active listening to understand, not just to answer, is the very first step. This is the key to fully embrace the followers in all their dimensions: needs, motivations, strengths, and weaknesses.
The stance of the manager as a coach goes with notions like servant-leadership with the main purpose of the manager to help their staff achieve their full potential. Or the Intent-Based Leadership where the manager does not give orders. In other words, the solution and the way to proceed. But the manager gives the intent, leaving the staff with the autonomy to find the best way to meet the intent.
To elaborate on this model, there is more than role modeling as primary mechanisms to change a culture, as described by Edgar Schein in Organizational Culture and Leadership. To illustrate, there is what leaders pay attention to and what they reward. The author underlines communication as the main lever to do so. And all events and media to demonstrate the support of leaders to the transformation.
Psychological Safety
Amy Edmondson is the reference regarding Psychological Safety with her book The Fearless Organization.
She describes 3 steps to build Psychological Safety in an organization:
Set the stage
This is a change of mindset to understand that it is not about personal incompetence but about system inconsistency. It is also about reframing failure like in the Grow vs Fixed mindset. And seeing failure as a way to learn, not as the limit of competency. This is the prerequisite to remove blaming for unintentional failure and support innovation. And for operation to rally all staff around quality to serve better the rediscovered purpose of the organization.
Invite participation
At the start, people are usually used not to speak. Silence always wins and is the comfort zone. So leaders should request genuine inputs from all on a regular basis. In addition, once people speak, leaders should receive the feedback adopting a humble stance, listening actively, and asking questions to understand.
Respond productively
Once leaders have received the feedback, the leaders should acknowledge the value of the feedback or learning and thank the people for their contribution.
The greater the perceived power distance, the greater the need for the leader to solicit feedback.
Smart flow to outcomes, build the right thing
Value stream flow
Identify the value stream
Like in the Lean approach, the author explains that the first step is to identify the value to the customer and the value stream. In other words, the flow of value creation, from the moment the need is identified to the moment this same need is met.
Actually, visualizing the value streams makes it possible to highlight the efficiency and the area for improvement of this value stream. For instance, steps generating values and time waiting for steps actually adding value. A value stream should focus on delivering one product or service to customers. And its related value and should minimize dependencies with other value streams.
Determine and align related IT solutions and the teams
Once the value stream is identified, it is possible to determine related IT solutions and the teams building these solutions. Definitely, the target is to have alignment of both with the value stream.
In addition, to optimize the flow, you want to have the teams aligned with the value stream to be small (less than 10 in the book), long-lived, and multidisciplinary to minimize handoffs and dependencies for efficiency and speed. But also to enforce mastery of related solutions and commitment to quality and value. Let’s underline that the multidisciplinary teams take care of both run and build, the production and the new features. To elaborate, this alignment is essential to commitment as people do not think any longer regarding their role, for instance, IT or business, but as part of the value stream team.
Reduce work in progress
Furthermore, still like in the Lean approach with the pull step, the Work in Progress is managed thanks to visualization and kept to the minimum. The famous motto here is “stop starting, start finishing.” This reduces the lead time as explained in Little’s Law. But also the cost for inventory and the context switching, resulting in increased efficiency.
Value stream funding
At last, this alignment to a value stream goes up to the funding: with long-lived teams comes stable funding. Change in funding will be on a quarterly basis. Indeed, it is fast to move money, but onboarding and training people from one value stream to another is not so fast. Rather, the approach to unexpected events like mandatory actions to regulation is to arbitrate among the tasks the teams of the value stream have in their backlog.
Outcome Hypotheses
Agile comes with a shift of mindset from up-front, fixed, and big designed solutions to small outcome hypotheses with experimentations. To put it differently, there are several changes of paradigm. Her are the mains:
- from output to outcomes
- from following a fixed plan to maximizing value
The author describes this pattern over five aspects.
Emergence
First of all, the development of a product is emergent as the work is specific and is to be discovered each time. Nevertheless, there should be a North Star, a clear direction. It provides alignment to the teams and a big direction to enable empowerment.
Nested Outcomes
Outcomes, their related hypotheses, and the feedback loop are nested at multiple cadences: daily, weekly, monthly, quarterly (the main one), yearly, and multi-yearly. All these cadences articulate through OKRs (Objectives & Key Results). Thanks to transparency that is a golden rule with OKRs, all tasks and all contributions can be connected to the strategic outcomes.
Hypothesis of outcome
Formulating the product development as unique and as outcome hypotheses makes it clear that those are hypotheses. To put it another way, they are to confirm, and experimentation is required to do so.
Writing the outcome hypothesis with a format like the one following can be of help to support this point: “Due to […], we believe that […] will result in […]”.
Rolling Roadmaps and Fixed Dates
The author proposes a 12-month rolling roadmap of quarterly outcomes. As uncertainty grows with time and needs for detail decrease relatively to time, the near term is fine-grained, and outcomes for future quarters are coarse-grained.
Truly, as the author highlights, regulatory initiatives can be managed with this approach. Indeed, legislation is written in a way that enables options for implementation. To go further than the book, you can even negotiate with the regulator. As a matter of fact, they usually write the rules at the same time they think about them. Surely, the feedback of companies impacted by their regulation helps them fine-tune the law.
From PMO (Project Management Office) to VET (Value Enablement Team)
The role of the traditional Project Management Office (PMO) changes with the change of paradigms from projects to long-lived products, value streams, and related teams. The concern is not meeting milestones but maximizing the value through experimentation on hypotheses of outcomes. To underline that, the author proposes to rename the role from PMO (Project Management Office) to VET (Value Enablement Team).
Safety and Lean Control, build the thing right
Safety within Safety
Data leaks are the new oil spills.
With the accelerating pace of technological change and the constant cybercrime, risk is rising and diversifying. As a consequence, this is the mission of Safety that stands for Governance, Risk, and Compliance (GRC). It covers information security, data privacy, compliance to regulation, and resilience. Truly, this activity is no exception: there is a need for Psychological Safety for quality and innovation.
Not just Safety I, as described by Professor Erik Hollnagel, a specialist in safety issues. Indeed, Safety I makes sure that nothing goes wrong and avoids failure. Then, in case an issue happens, it investigates the root cause with an analysis. But quality requires more than removing negatives. As a matter of fact, it requires positives. Safety II works on things to go right and pushes good behaviors and practices for them to happen more often. At some stage, they become part of the habits and change the culture so people speak up and take initiative.
The author reminds the principles to reach Safety II and positives:
- The ability to speak up and say stop to bad ideas and practices. Or when they become irrelevant due to change in the context. Even if this breaks the status quo.
- The capacity to leverage the diversity of opinions, embrace dissidence to listen to different opinions, or points of view. With as a result the possibility to escape group thinking.
Organize Safety by Value Stream
The same way as for the rest of the organization, the approach with Safety is to have a Long-Lived Safety Team, cross-functional with all the specialties in Safety, aligned on each Value Stream. As a consequence, this provides the same type of benefits of efficiency, time to market, and quality. Just to mention the main ones.
Not only does this make the Safety team grow expertise about the value stream and understand the customer context and needs. But it also reduces the context switching and the need to coordinate between all the Safety expertises. There is also a switch of mindset of the Safety experts as they become part of the Value Stream.
Instead of being incentivized to say no, the Safety SME is now incentivized to lean in with the value stream to find a safe way to yes.
The Safety team is more efficient as they understand the business context. Then they get direct information ahead of time about new business initiatives. So they can identify areas for risk earlier.
In addition, having the Safety Team part of the Value Stream makes awareness and concern about Safety grow within the delivery and operating teams. This is all the more valuable that Safety resources are scarce and should focus on the riskiest areas. To elaborate, it gives them the big picture regarding Safety. And provides them with a consistent and long-term point of contact for all Safety topics. With time, they get used to working together and build trust and understanding.
Safety Chapters
To keep developing their expertise, share return of experience with peers, and keep in touch with the state of the art of their specialty, Safety experts contribute to chapters. As the author calls them, these communities of Safety also provide support. In addition they guarantee the consistency and relevance of solutions to address Safety.
Risk story templates
Without surprise, risks and safety requirements will be expressed as stories. Therefore, the prerequisite is to translate risk statements from policies and standards into risk story templates. They describe the risks in words that delivery and operation teams understand. To illustrate, the value expected, here the risk put under control, the acceptance criteria, and typical mitigation actions for this type of risk.
Furthermore, this is the opportunity to consolidate requirements from different policies (information security, data privacy, compliance to regulation, and resilience…) when they overlap.
Smart Safety Control
Product and Safety teams collaborate on a continuous basis. Quarterly with OKR cycle, the targeted outcomes make it possible to identify the impact on the Safety aspects. It is then possible for the coming quarter to estimate the level of involvement required from the Safety team. And how frequently they should interact with the Product teams: daily, weekly, or monthly. Surely, the product teams remain accountable for the safety of their product.
Risk Stories
Safety requirements are captured either as part of User Stories or as stories by themselves. Once properly fed in the backlog, teams manage risk stories like other pieces of work. Depending on the level of impact on Safety, the risk story may need the validation by the Safety team before closure.
Candidate Release Validation
The second point of control for the Safety Teams is the validation of the Release. In other words, the code to be released to production. If any mandatory risk stories are not closed, then the Safety Team can reject the Release. For sure, automation as part of DecSecOps enables the check of the Safety requirements by the flow as built in, rather than inspected at the end.
Leadership Support for Safety
Value stream leadership has a key role to play for Safety to be part of the requirements for their product. They should:
- Take ownership of risk and actively promote risk awareness and requirements across the teams.
- Partner with Safety leadership to make sure the Safety team has the capacity to fulfill its mission.
Risk Metrics and tooling
Risk Metrics are essential to visualize areas of risk and manage mitigation actions. As a matter of fact, this requires efficiency and transparency. In other words, a proper tooling with integration and automation to manage a large number of value streams with, for each, a pool of products.
Technical Excellence
Visualize type of works for continuous improvement
There are 4 main types of work for a delivery team:
- new features,
- fixing defects,
- risk stories and,
- improvement stories, like paying technical debt or refactoring proactively to prevent it occurs.
In order to save time for improvement stories, you have to visualize your flow and measure it. Then preempt time for your improvement stories. That’s the only way to balance between “urgent”, which will take all the bandwidth if not contained, and “important”. The author illustrates with Toyota where workers spend 40% of their time on improvement activities and propose 20% as a guideline. In my experience, a start with 10% of your activity is already a success. But if you can reach 20%, it is indeed a good number.
Measuring and Feedback Loops
The last element to pilot your continuous improvement is to measure how you progress with your actions. Like removing technical debt, and the impact of your actions, for instance, decreasing defects during development and incidents in production.
Software and architecture craftsmanship
To reach state of art, with technical work in software delivery, in other words, Craftsmanship, there is a need for technical coaching. This comes with a Software Engineering Center of Excellence and a community of practice. Infrastructure engineering is also covered, as infrastructure is now code in a cloud environment.
Architecture design is a concern and should embrace Agile principles. And this at both the application and enterprise levels, through coaching and a community of practice.
Architecture supporting the Flow
Monolithic IT systems are not structured in components and serve many value streams. As a result, these value streams, like the systems, are tightly coupled with an impact on quality, speed, and agility. Indeed, it requires that every value streams test and release at the same time.
To address monolithic IT systems, Martin Fowler introduced in 2004 the approach of the “Strangler Pattern,” named after the Australian strangler fig tree:
An alternative route [to huge rewrites] is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.
When designing or redesigning a modular architecture and breaking dependencies, it is important to think about Conway’s law that explains the way teams are organized structures the architecture. Build your team with the architecture you have in mind (the reverse Conway’s law). And take into account the cognitive load. So the pieces of software can be managed by an Agile team, as developed in Team Topologies by Matthew Skelton and Manuel Pais.
Develop Technical Careers: Distinguished Engineer Programs
To develop technical expertise for both software and infrastructure engineers, attract and retain talent in these areas, you need to have a real promotion and recognition path for technical specialists, as good and as prestigious as the manager path.
Rethink testing with automation and chaos engineering
Automation does not remove testers. But it makes it possible to automate repetitive checks. So that testers can use their creative minds to focus on other tests and provide expertise around testing to developers who may miss scenarios. Testing is evolving to be more upfront with systematic automation at the time a feature is developed. Or even before the development with a state of art test-first approach. Surely, this comes with a change of mindset on the developer side. So that they consider testing and related automation as fully part of the development.
Another aspect of change in testing is chaos engineering to build resilience. This approach is based on deliberately injecting failures with a controlled impact into a production environment to test the resilience of the system. As a result, it supports developers to consider better failure scenarios, taking into account all the complexity of the production. And how to build the architecture of the system to be fault-tolerant.
Learning Ecosystem
Tacit versus Explicit Knowledge
As an introduction to the last part of the book that is around knowledge, let’s stress out that knowledge can be explicit or tacit. To illustrate, explicit and formal knowledge, like repetitive tasks, are usually well-documented, easy to understand, and as a consequence, easy to transfer. In contrast, tacit knowledge that is a main part of knowledge, if not the main, is hard to identify and then to transfer. This is where pairing or community of practice are useful to share this kind of knowledge.
Environment for learning
A learning environment is all the more required nowadays, as knowledge becomes obsolete more quickly, and workers need to unlearn and relearn faster. To support the need for more learning, the first element is to build psychological safety. So workers are comfortable sharing knowledge for others to train or for continuous improvement.
The second element derived from psychological safety is to embrace the diversity of opinion and thought. So everyone can speak and be listened to actively and with respect. Lastly, the organization needs to have a culture of the growth mindset, not of the fixed mindset. To illustrate, the best way to define shortly the growth mindset and the fixed mindset is to explain their relationship to error. In the fixed mindset, errors stress someone’s limits of skills. On the contrary, in the growth mindset, errors are the path to learn.
Enforce learning at all levels leveraging feedback loops
Learning happens at individual, team, and organization levels.
Individual learning
Individuals can learn alone by reading assets on explicit knowledge, like documentations, or using other assets that may even have been created for training purposes, such as videos or self-learning tools.
Team learning
Team meetings like Agile daily meeting, sprint planning, demonstration, or retrospective are the first way to learn about the team work environment. Either the team processes, way of working and habits, or the content the team works on. Continuous Improvement sessions, for instance, the retrospective, are a special type of meeting where the team learns, resulting in the improvement of their way of working. Lastly, as mentioned above to transfer tacit knowledge, pair working, enabled by the visualization of the tasks the team is working on, makes it possible to transfer knowledge and improve practices.
Human Systems Dynamics
Another important aspect for learning in a team is how the team is built. To elaborate, the theory and practice of human systems dynamics, as developed by Glenda Eoyang, is useful to explain the parameters:
- Containers: this is the scope of the team. It should be defined to enforce focus with a clear mission (do one thing well) and minimal dependencies to support autonomy (do one thing only).
- Differences: multidisciplinary teams come with diversity of skills. But there should be more diversity with diversity of experience, knowledge, gender, and even cultural background. Truly, this is the condition for diversity of opinion and thought for innovation and continuous improvement.
- Exchange: Communication and feedback to support information flow and learning. Clearly, the Agile meetings mentioned above are of great help.
Note that these principles are also true for a value stream gathering all the skills, sharing the same culture, and focusing on a common strategy and related objectives.
Self-Organizing Teams
Efficient learning within a team requires teams with all the skills to perform their mission and be self-organized. Surely, this is the prerequisite for end-to-end learning and effective feedback.
Self-organization happens in containers with the proper level of diversity and where people feel free to discuss. In addition, this supports people multiskilling as they explore outside their specialization and develop new skills. To illustrate, this is the T-shape skill profile: one deep expertise and knowledge on other skills useful for the team.
Organization learning
Unconference and Liberating Structures
The author considers that the most difficult level for learning is at the organization level. To do so, he proposes 2 examples of large audience workshops, named Unconference. Potentially, you may also know them with the name Liberating Structures:
- In the Lean Coffee format, participants raise ideas, vote for them, then in a time-boxed format, brainstorm on these selected ideas.
- The author also mentions the Open Space as another format.
- We could have added the World Cafe. Definitively, there are main formats of large audience workshops behind the generic name Unconferences or Liberating structures.
Community of Practice and Chapter
The book mentions another way to develop knowledge at the level of the organization: the community of practice. They are on a voluntary basis and disappear if they are or if they become useless. In other words, if people stop attending them. A common working pattern is to have communities of practice facilitated by two co-chairs and a small group of active core contributors. They take care of the events and the backlog of topics to share. To proceed, an open invitation is sent to all, with an agenda. To support a cadence and give a rhythm, the invitation is recurrent, at least monthly. People may attend as listeners only, as this already supports learning.
To go further than the book, the Chapter is a more prescriptive format of a community of practice. It acts as a glue between people of different teams sharing the same expertise. To elaborate, the mission of a chapter is to steer sharing of knowledge, develop skills, enforce consistency, and conduct actions to build transversal assets for the teams.
Awards
The author reminds that a valuable input for learning is return of experience and success stories. Unfortunately, they do not surface by themselves at the level of the organization. In other words, you need to have an active process to collect them, then share them. To do so, the book proposes to organize awards to collect and market these returns of experience and success stories. In my experience, it is first at the level of each unit, or value stream transformed, that you should collect these stories.
Identify and Break Silos
A prerequisite for organizational learning is to identify and break silos. Surely, this is true for delivery as described above, but knowledge and learning are no exception. This is especially important when defining a value stream, even if the need is for the company as a whole. With the implementation of visuals about the value flow, comes the identification of the bottlenecks, long wait times, and other issues. This is a key input for learning and continuous improvement.
The author points out the good practice of shifting activities left. In other words, to start end-of-value-stream activities earlier and with collaboration between people expressing the need, people building the solution, then testing it, and people exploiting it. The concept of the “three amigos” with the Product Owner plus the Business Analysts, the developer, and the testers is a good example. This is also one of the principles with DevSecOps and the collaboration of developers, people operating the production, and lately added in the word DevOps, the security/compliance people.
Measure for Learning
Metrics on Outcomes for Learning
As we have underlined above, Agile comes with a change of paradigm. From output, what you deliver, to outcome, the impact of what you deliver on your objectives. Therefore, learning follows the same principle, so supporting metrics for learning are outcome and impact-oriented. Really, this is the key to support good behaviors and not just falling into the trap of being busy.
Visualization
To start with, you need data to learn. Dashboards make it possible to collect and interpret information. The author advises using a data engine to do so and collecting data from all the data sources across the organization and the value streams.
It is interesting to note that the book advises treating dashboards as a product. To illustrate, establishing hypotheses, running experiments, and then collecting feedback and analyzing how useful the dashboards are regarding the objectives for learning and improving.
In addition, a simple way to collect data to learn is through surveys. To start with, survey your clients about how you help them reach their objectives and how the dimensions of BVSSH, Better Value Sooner Safer, and Happier, should be adapted for more impact. Furthermore, you should survey employees for the same dimensions with a special focus for the Happier as they are especially concerned by this one.
The thing I have noticed is when the anecdotes and the data disagree, the anecdotes are usually right. There’s something wrong with the way you are measuring it.
Keep in mind with data, that what is important is the story that you can tell from the data and it should make sense. As highlighted by the quote above, pay attention to the stories from the field to confirm that the story built on data is consistent.
What’s next? Learn more about Agile Leadership, Agile at Scale, Lean and DevSecOps
- Agile Leadership
- Agile@Scale
- Lean
- DevSecOps, Craftmanship and Agile Architecture
Do you want to learn more about the topic? Here are some valuable references
- Value-Stream Mapping
- Overview from Lean.org
- Fundamentals from Lean.org
- Transformational Leadership
- Safety-I and Safety-II
- The CDE model (Container, Differences, Exchanges) from Human Systems Dynamics Institute
- Explicit and tacit Knowledge
- Community of Practice
- Shift Left Testing
- The Strangler Fig approach for application reengineering by Martin Fowler
- Chaos Engineering