User contributions for Ppugliese

24 January 2024

• 00:5300:53, 24 January 2024 diff hist +1,103‎ N Optimise the system of work for the majority of cases rather than the exceptions ‎ Created page with "__NOTOC__ ==Description == Ensure that organisational systems, services, processes, policies and rules are tuned to effectively and efficiently support the most common scenarios. Avoid adding unnecessary impedance and delay to these common scenarios with guardrails to catch exceptions. Start with the most simple solution and validate if exception scenarios occur, rather than second-guess with additional processes, policies and rules. == Rationale== Many processes are..." current
• 00:5300:53, 24 January 2024 diff hist +2,134‎ N Leadership supports rather than drives the work ‎ Created page with "__NOTOC__ == Description == Leaders seek to engage the collective capability of the organisation's people by actively cultivating the system of work (environment), helping everyone to establish the purpose of the work (the “why”) and removing impediments to performing excellent work and achieving personal satisfaction. == Rationale == L. David Marquet describes the role of leaders so: “In healthy organizations, leade..." current
• 00:5200:52, 24 January 2024 diff hist +4,725‎ N Minimise unnecessary complexity ‎ Created page with "__NOTOC__ == Description == To keep the system of work (e.g. structure and processes) simple, you might need to reduce unnecessary complexity before you start to scale. Scaling an overly complex system is likely to result in inefficiencies and reduced effectiveness of the scaled system, e.g. scale teams aligned to value streams not specialists. Keep the scaled system simple, applying appropriate scaling approaches as needed and as simply as possible. Make small incremen..."
• 00:5200:52, 24 January 2024 diff hist +3,377‎ N Organise around value streams ‎ Created page with "__NOTOC__ == Description == The design of the way product teams are structured should be optimised for the customer and business value streams in preference to designing them around departmental or delivery domain capabilities. This principle is predicated on the assumption that the value streams themselves have first been optimised for customer and business needs. A value stream provides a container within which teams can self-manage, coordinate and observe the results..."
• 00:5200:52, 24 January 2024 diff hist +2,861‎ N Start small and scale success ‎ Created page with "__NOTOC__ == Description == Start with a single team and grow in an evolutionary style, building on success rather than initiating the work with multiple teams in parallel. A great foundation can be established by a single team, practising collaborative group design, and building out an executable architecture focused on rapid learning and producing early value. This principle primarily applies at a formative stage when there is still a choice as to whether scaling is r..."
• 00:5200:52, 24 January 2024 diff hist +2,281‎ N Scale only when you need to ‎ Created page with "__NOTOC__ == Description == If you need to scale, do it as little as possible. Before adding many teams, make sure that your first few teams are highly effective –– you might not even need to add additional teams. == Rationale == A story about a telecommunications company’s failing consumer cloud product turned around by going back to basics and applying a rigorous and evolutionary approach to scaling: * Initial situation. The product was developed by multiple s..."
• 00:5200:52, 24 January 2024 diff hist +1,320‎ N Evolutionary over revolutionary change ‎ Created page with "__NOTOC__ == Description == Revolutionary change has a high risk of failure, therefore change should be evolutionary. == Rationale == Revolutionary change, where a significant change is made in a transactional fashion, has a far higher risk of failure than multiple small incremental changes. An evolutionary approach to change introduction is recommended, with the following considerations: * Ensure those impacted by a change are part of the change process as opposed to..."
• 00:5100:51, 24 January 2024 diff hist +1,492‎ N Limit Team Mental Workload ‎ Created page with "__NOTOC__ == Description == Ensure that all teams are working with a Mental Workload that they can cope with on a sustained basis. Each team will have a practical limit to the breadth and depth of solution and business domain complexity that they can deal with and maintain a sustained high quality outcome. Factors to balance when considering the practical mental workload limit for a team: * Inherent business domain complexity *Level of Product Owner support * Numbe..."
• 00:5100:51, 24 January 2024 diff hist +2,295‎ N Favour teams with maximised cognitive diversity ‎ Created page with "__NOTOC__ == Description == Build teams with people who think differently and have different perspectives (i.e., cognitive diversity), regardless of the team’s technical focus. == Rationale == Teams with maximised cognitive diversity outperform other teams, all other things being equal. Scott E. Page, in his book “The Difference”<ref>Page, S. E. (2007). ''The difference: How the power of diversity creates better groups, firms, schools, and societies'' (3. print.,..."
• 00:5000:50, 24 January 2024 diff hist +1,278‎ N Maximise Team autonomy ‎ Created page with "__NOTOC__ == Description == In developing large products where many Teams are involved, reducing the amount of coordination needed to ensure Teams' coordination is paramount. It is, therefore, fundamental to find ways to maximise the autonomy of each Team in a Team of Teams. This can be achieved in several ways: * The creation of Teams with broader problem and Favour Teams with broader Solution Accountabili..."
• 00:5000:50, 24 January 2024 diff hist +2,678‎ N Self-managed Team of Teams ‎ Created page with "__NOTOC__ == Description == When an agile team implements self-management well, all the internal planning, coordination and integration is run within the team. This can be very effective and results in highly productive teams that run themselves with little external effort needed. Creating a similar effect at scale but at a multi-team level is essential. The alternative is an external coordination structure required to ensure the teams work properly aligned. == Rational..." current
• 00:5000:50, 24 January 2024 diff hist +2,001‎ N Self-managed teams ‎ Created page with "__NOTOC__ == Description == When an agile team implements self-management well, all the internal planning, coordination and integration is run within the team. This can be very effective and results in highly productive teams that run themselves with little external effort needed. In order for the team to decide what they work on as well as how, the team should have a guiding mission and clarity of purpose that motivates and guides their work. == Rationale == This is a..."
• 00:5000:50, 24 January 2024 diff hist +3,709‎ N Favour Teams with broader Business Domain Competence ‎ Created page with "__NOTOC__ == Description == At the core of agility, the basic idea is to adapt our development to deliver customer value more effectively and quickly. Therefore, the organisational form should be designed to support this mode of operation. This means two things: # Team membership is independent of organisational structure. Teams are shaped around Customer Value rather than within organisational departmental boundaries. A team should contain members from across the or..."
• 00:5000:50, 24 January 2024 diff hist +5,720‎ N Favour Teams with broader Solution Accountability ‎ Created page with "__NOTOC__ == Description == Teams with broader solution accountability, i.e. the capability to operate in as many parts of the system under development as possible, are beneficial in a scaled environment. == Rationale == In the development of large products, it is very difficult for individuals and teams to have a whole system understanding, hence the tendency of many companies to create teams with specialised knowledge. And the consequence of this is a reduction of ac..."
• 00:4900:49, 24 January 2024 diff hist +2,434‎ N Maximise team empowerment and localised decision making ‎ Created page with "__NOTOC__ == Description == Put the decision authority where the information is richest and most current. This is important to avoid escalations, delegations and information hand-offs. Team empowerment and localised decision-making are supported by shaping the teams. They are aligned to business services, features and value streams instead of technical components, services or platforms. In addition, ensure that effective empowerment is supported by boundaries that clear..."
• 00:4900:49, 24 January 2024 diff hist +3,746‎ N Invest in quality ‎ Created page with "== Description == At scale, it is even more essential that we continuously invest time and effort in the quality of the emerging integrated product so that the team of teams can maintain a sustainable pace. Quality is a complex concept that can include many dimensions, most of which are "Internal" in that customers should be unaware of them, at least until there is an issue at which point they become "External": * Extensibility - the product's openness to extension an..."
• 00:4800:48, 24 January 2024 diff hist +1,515‎ N Technical leaders as coaches, mentors and community leaders ‎ Created page with "__NOTOC__ == Description == Technical leaders should view their role as building teams' technical capability over technical design, delivery and decision-making. Technical leaders are encouraged to reduce the proportion of telling and directing, and instead act as coaches and mentors. In addition, they should catalyse group learning to engage and share the diversity of experiences and ideas across teams. == Rationale == * Motivation, engagement and empowerment of team..."
• 00:4800:48, 24 January 2024 diff hist +1,806‎ N Maximise learning: Craft skills development ‎ Created page with "__NOTOC__ ==Description== Continuous development of Craft skills (business and delivery domain) is an intensional part of all work to collaborate and create value stream outcomes. This is reflected in outcome goals at all levels, along with the necessary support within the environment, time and ways of working. This principle acknowledges that developing and improving knowledge, capability, and practices is an essential element to sustain an organisation in a complex a..."
• 00:4800:48, 24 January 2024 diff hist +1,826‎ N Product solution design is driven from within development teams ‎ Created page with "__NOTOC__ ==Description== Push design authority to the teams. Conversely, avoid making design decisions externally and then imposing them on teams. ''TODO *** Suggested change to title: Product solution design is driven from within development teams - Design is a broader term that includes UX and other design challenges'' ==Rationale== Devolving design authority to the teams will have the following impacts: * Increase motivation, autonomy and engagement of teams *..."
• 00:4800:48, 24 January 2024 diff hist +1,409‎ N Support autonomy with clear boundaries ‎ Created page with "__NOTOC__ == Description == Ensure that there are explicitly agreed boundaries and constraints around the teams that make clear what they can and what they can not decide and act on independently. Team autonomy should be “Bounded”. Examples of boundaries and constraints include: * Definition of Done - shared DoD elements that concern inter-team touch points and cross-cutting standards * Architectural standards * Brand and design guidelines * Platform standards * Sec..."
• 00:4800:48, 24 January 2024 diff hist +1,757‎ N Collective responsibility for complete product development ‎ Created page with "__NOTOC__ ==Description== Whilst a single team may focus on a subset of the value stream, all teams are collectively responsible for the cohesion and success of the overall product. This applies to both the collective elements that form the product as well as the end-to-end lifecycle from idea to customer outcome. ==Rationale== As we scale, there is a risk that teams generate elements of the system that are inconsistent with the local optimisation of design decisions. T..."
• 00:4800:48, 24 January 2024 diff hist +2,286‎ N Amplify Speed and Quality of Learning Cycles ‎ Created page with "__NOTOC__ == Description == Understand and work to reduce the elapsed time taken to understand the impact on the overall product system due to changes made by individual contributors. The value of "Learning" is a function of both the speed of the feedback and its quality. As an example, the scope for practices such as Continuous Integration and Continuous Delivery should incorporate the overall product system. A team may continuously integrate within a team-limited sub..." current
• 00:4700:47, 24 January 2024 diff hist +1,551‎ N Regular small changes: Scale the number of changes rather than the size ‎ Created page with "__NOTOC__ == Description == A product should be evolved through many small incremental changes rather than fewer but larger modifications. This enables the product as a whole to never be far from a working version. ==Rationale== Small changes enable faster feedback loops that increase the rate of learning and reduce the cost and scale of “failure”. Debugging issues that may cross team boundaries are simplified, and remediation waste is reduced. A short engineering-..."
• 00:4700:47, 24 January 2024 diff hist +1,601‎ N Maximise the Scope of Product Increment ‎ Created page with "__NOTOC__ For each team, the scope of the Product Increment should be as close as is practicable to releasable end-to-end value. == Description == The Scrum Guide describes the Increment as a concrete stepping stone toward the Product Goal, i.e. to realisable value to customers and stakeholders. The Definition of Done provides the guardrails to ensure that the incremental work of the team(s) will be of sufficient quality to release. Where a product is a composite of the..."
• 00:4700:47, 24 January 2024 diff hist +2,084‎ N Use the Definition of Done as an enabling constraint ‎ Created page with "__NOTOC__ == Description == Where multiple teams have a collective responsibility to increment a Product Increment, they should work to a shared Definition of Done (DoD) to improve transparency, inter-team collaboration, sustained quality and predictability. * The DoD applies to the Product Increment. * There may be team-specific DoD elements where there is high diversity between the team's respective delivery technologies. However, ensure that there are appropriate sh..."
• 00:4600:46, 24 January 2024 diff hist +6‎ Leadership ‎No edit summary
• 00:4600:46, 24 January 2024 diff hist +2,966‎ N Leadership - Further Explanation and Models ‎ Created page with "__NOTOC__ == Self-Determination Theory<ref>Ryan, R. M., & Deci, E. L. (2000). Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being. American Psychologist, 55, 68-78</ref> == === Autonomy === A Team should be aligned to an end-to-end value stream such that they can autonomously deliver “Done” increments of value that are as close to releasable as practical. This strategy reduces the inter-team dependencies and han..." current
• 00:4500:45, 24 January 2024 diff hist +2,775‎ N Are lean practitioners ‎ Created page with "__NOTOC__ == Description == Lean Thinking is an essential part of the toolbox for modern leaders. At its heart, Lean Thinking is about a commitment and focus on growing the organisation's people and building a culture of continuous improvement into the organisation's DNA. Build the people first, and then build the products and services. == Rationale == Great Agile and agility are founded on many of the principles found in Lean. Lean or Lean Thinking is the Western nam..." current
• 00:4500:45, 24 January 2024 diff hist +1,723‎ N Provide an impediment removal service ‎ Created page with "__NOTOC__ == Description == One of the essential duties of leadership is to resolve issues that are outside of the boundary of teams' autonomy and empowerment. This has the dual aim of optimising teams' flow of value delivery and recognising and resolving systemic issues caused by the organisational environment. == Rationale == Agile teams discover problems impacting their work as a natural part of doing the work. Some of these problems can be removed or resolved by th..." current
• 00:4500:45, 24 January 2024 diff hist +1,115‎ N Own your own approach ‎ Created page with "__NOTOC__ == Description == Leaders seek to understand their own context and that of their organisation and choose to evolve an approach that fits the context. This is in direct contrast to an overly simplistic application of models developed in entirely different industries, which will likely be sub-optimal at best. == Rationale == A typical example is choosing to apply the fashionable “Spotify” model without really understanding the context, application range and..." current
• 00:4500:45, 24 January 2024 diff hist +3,566‎ N Create a Learning Organisation ‎ Created page with "__NOTOC__ == Description == Agile leaders perceive their organisations as intricate human systems, acknowledging the complexity of their behaviour, interactions and development, necessitating a systemic approach. A systematic approach has been referred to by Peter Senge as a Learning Organisation. Leaders should focus their efforts on creating an organisation where individuals can work effectively together when responding to market..."
• 00:4500:45, 24 January 2024 diff hist +2,606‎ N Involve those affected by change ‎ Created page with "__NOTOC__ == Description == In order to increase the likelihood of successful change, leaders engage those affected by the change and also those stakeholders with critical perspectives, data and understanding of the current context. The aim is to increase the quality of the intended changes and reduce the resistance by avoiding imposing change on underinformed and underinvolved people. Significant collateral benefits include increased trust, [https://amycedmondson.com/..."
• 00:4500:45, 24 January 2024 diff hist +2,405‎ N Create clarity of purpose ‎ Created page with "__NOTOC__ == Description == Leaders ensure that there is excellent clarity of purpose throughout the organisation. With this term, we refer to the full spectrum of longer-term strategic objectives through to shorter-term goals, with the level of detail increasing for shorter-term goals. In order to Maximise engagement, this clarity should ideally be created and communicated through a collaborative process informed by a combination of detailed and broader perspective..." current
• 00:4400:44, 24 January 2024 diff hist +3,025‎ N Catalyst for change ‎ Created page with "__NOTOC__ == Description == A fundamental responsibility of leadership is to support their organisation to successfully navigate OODA loops (Observe, Orient, Decide, Act)<ref>https://en.wikipedia.org/wiki/OODA_loop</ref> to continually learn and adapt. PDSA/PDCA are also applicable, however, starting with "Observe" matches the change journey outlined. Any scaling endeavour will include the need to adapt from current structures, products and services, behaviours, systems..."
• 00:4400:44, 24 January 2024 diff hist +3,815‎ N Cultivate learning between teams ‎ Created page with "__NOTOC__ == Description == The role of leadership is to foster an environment and incentive for teams to share learning. Teams are the centre for knowledge generation. However, natural tribal instincts tend to drive a "Not invented here" culture, leading to reinvention and wasted effort. In addition, hard-won knowledge stays within team boundaries leading to relearning waste in other teams. Leaders work to catalyse and support an environment that encourages and reward..."
• 00:4400:44, 24 January 2024 diff hist +3,886‎ N Maximise engagement ‎ Created page with "__NOTOC__ == Description == Leaders have a responsibility to maximise the engagement of the organisation's human capability to harness the potential creativity and cognitive abilities. This will enhance the organisation's chances of surviving and thriving, and it will also improve the culture, morale and staff retention. == Rationale == The regular engagement survey from Gallup shows that 70% of employees are not engaged. <ref>https://www.gallup.com/workplace/313313/..."
• 00:4400:44, 24 January 2024 diff hist +2,349‎ N Foster a high trust environment ‎ Created page with "__NOTOC__ == Description == Trust is the foundation that enables teams to create great results for the organisation. Without trust, teams can't reach their potential. Trust is an essential element of Psychological Safety which was found by Google's Project Aristotle to be the number one factor differentiating the highest-performing teams. Trust can be defined as “Choosing to make something important to you vulnerable to the actions of someone else.” <ref>https:/..."
• 00:4400:44, 24 January 2024 diff hist +2,576‎ N Create the environment for people to thrive ‎ Created page with "== Description == Leaders critically consider and continually improve how the organisation's environment enables its people to sustainably generate value for customers and stakeholders. In an Agile organisation, value generation is serviced by self-managing teams, allowing leaders to switch their focus from directing people's work to catalysing the continued evolution and improvement of the organisation. In this context, "Environment" includes: * Psychological Safety..." current
• 00:4300:43, 24 January 2024 diff hist +1,812‎ N One Product Owner may have multiple Teams ‎ Created page with "__NOTOC__ ==Description == While one Team must have one PO as a reference person prioritising their work, one PO might work with multiple Teams if needed and if possible. ==Rationale== One of the most common misunderstandings in Scrum is to assume that there is a 1:1 relationship between Teams and Product Owners, i.e. that every Team must have a different Product owner. While the Scrum Guide is very clear that “The Product Owner is one person, not a committee”, ther..." current
• 00:4200:42, 24 January 2024 diff hist +2,937‎ N Collective accountability in case of Product Ownership Group ‎ Created page with "== Description == While a single Product Owner is the recommended configuration, sometimes it's difficult to achieve, especially when starting from a very scattered organisational structure with many "owners" for various parts of the value stream. In general, it is better to minimise the number of Product Owners (Principle: Minimum Viable Product Owners) and work to reduce them as much as possible. Where multiple Product Owners are involved in a Value Stream, they sho..." current
• 00:4200:42, 24 January 2024 diff hist +2,116‎ N Outcome is the primary measure of success ‎ Created page with "__NOTOC__ == Description == Product leadership (the Product Owner) and organisational leadership should focus on tracking and measuring outcomes in order to achieve Product and Business goals. Assessing and understanding what impact the product is achieving, customer behaviour changes, and product usage, with meaningful measures that illustrate progress towards business and product outcomes. ==Rationale== This principle is moving the emphasis from measuring team(s) outp..." current
• 00:4200:42, 24 January 2024 diff hist +907‎ N Each team "sees" exactly one Product Owner ‎ Created page with "== Description == The Product Owner provides direction to the Team in the form of a Product Goal and a prioritised Product Backlog. In order to guarantee consistency a Team has to receive the direction from a single person. == Rationale == * This is clearly defined in the Scrum Guide * The opposite is not true: a Product Owner could work many different Teams. The 1:1 relationship between Teams and Product Owners is a common misunderstanding that has dire consequences i..." current
• 00:4200:42, 24 January 2024 diff hist +1,435‎ N Limit Product Owner Mental Workload ‎ Created page with "== Description == Scale the number of Product Owners to prevent overloading the product ownership function. == Rationale == There are practical limits to the Mental Workload that a single Product Owner can effectively and sustainably support. Although a single Product Owner is the ideal model, as complexity and scale increases, a limit is reached whereby it becomes necessary to share the load across multiple Product Owners. The mental workload for the role of produc..." current
• 00:4200:42, 24 January 2024 diff hist +1,073‎ N Minimum Viable Product Owners ‎ Created page with "__NOTOC__ == Description == Aim to create a product organisation with the least amount of Product Owners in order to maximise the “Scope of Accountability” of each Product Owner and allow for decisions that have a more holistic impact on the value-chain. == Rationale == A system of work with fewer Product Owners will: * Increase the relative “Scope of Ownership” for each Product Owner * Reduce the complexity of collaboration and coordination overhead * Reduce de..." current
• 00:4200:42, 24 January 2024 diff hist +2,478‎ N The Product Owner is accountable for sustained end value ‎ Created page with "__NOTOC__ ==Description== A Product Owner should have visibility, ownership and decision-making authority for an end-to-end value stream from customer demand/need through to realised customer value (“Scope of Accountability”). In larger products where it is not practical for a single Product Owner to have accountability for the full value stream, aim so that each Product Owner is accountable for an end-to-end slice of the value stream. Product Owners should be En..." current
• 00:4100:41, 24 January 2024 diff hist +2,698‎ N Reduce factors increasing product complexity ‎ Created page with "__NOTOC__ == Description == In large Composite Value Streams there are several other parameters impeding the path to a single Product. While these are real constraints of the current organisation, these dimensions contribute to the overall complexity of the organisation and it is imperative for the leadership to work to remove these obstacles. == Rationale == Every organisation is characterised by a certain level of complexity. Inspired by the work of Fredrick, we could..." current
• 00:4000:40, 24 January 2024 diff hist +2,464‎ N Align towards business synergies ‎ Created page with "__NOTOC__ == Description == Where a Value Stream is too large to be supported by a single Product Owner and Team, use Business perspectives to inform splitting by independent but valuable subsets of the Value Stream. Example: A company with a Composite Value Stream builds several Apps for different markets. On one hand, it makes sense to view the entire set of Apps as one Product, which would be directed by a single Product Owner. However, if this proves too challenging..." current
• 00:4000:40, 24 January 2024 diff hist +1,890‎ N Avoid Components ‎ Created page with "__NOTOC__ == Description == Where a product needs to be scaled across multiple teams and possibly Product Owners, the product should be decomposed in such a way as to retain the ability for teams to deliver slices of end-to-end value autonomously. As far as practical, avoid shaping teams and product ownership around vertical slices through the Value Stream. The recommended alternative strategy is to Align towards business synergies. == Rationale == Although it migh..."
• 00:4000:40, 24 January 2024 diff hist +2,195‎ N Architectural cohesion ‎ Created page with "__NOTOC__ == Description == When a Value Stream is too large to be managed by a single Product Owner and Team, it should be broken into smaller parts, each of which should be as cohesive as possible whilst still aligning with business synergies. The Team working in that part needs to be able to: # Do the work with the least possible amount of technological and functional dependencies on other parts (low coupling) # Be able to validate their work in a fast and effective..."
• 00:4000:40, 24 January 2024 diff hist +3,093‎ N End-to-End Product ‎ Created page with "__NOTOC__ == Description == When defining the scope of a product, it should ideally encompass an end-to-end value stream (single or composite). Likewise, the definition of the "Product Group" (the product development organisation) that serves the product will also span the end-to-end value stream. End-to-end in this context means that the scope of the value stream spans all activities from idea or request through to market success (internal or external consumers). == R..." current