All public logs

Combined display of all available logs of go-ELSE. You can narrow down the view by selecting a log type, the username (case-sensitive), or the affected page (also case-sensitive).

• 00:48, 24 January 2024 Ppugliese talk contribs created page 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:48, 24 January 2024 Ppugliese talk contribs created page 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:48, 24 January 2024 Ppugliese talk contribs created page Product solution architecture 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:48, 24 January 2024 Ppugliese talk contribs created page 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:48, 24 January 2024 Ppugliese talk contribs created page 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:48, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:47, 24 January 2024 Ppugliese talk contribs created page 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:47, 24 January 2024 Ppugliese talk contribs created page 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:47, 24 January 2024 Ppugliese talk contribs created page 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:46, 24 January 2024 Ppugliese talk contribs created page Agile Transformation Leadership Team Approaches (Created page with "TODO : Need an intro to the general purpose of this pattern (MR 22-12-21) Agile Transition Team - Need to check this link <ref>https://www.scruminc.com/agile-transformation/</ref> Executive Action Team<ref>https://www.scruminc.com/eat-executive-action-team/</ref> (Scrum@Scale) (Sutherland, 2021) <ref>https://www.agilegenesis.com/post/establishing-a-scrum-action-team-eat</ref> Lean-Agile Centre of Excellence<ref>https://www.scaledagileframework.com/lace/</ref> (Scal...")
• 00:46, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:45, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:45, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:45, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:45, 24 January 2024 Ppugliese talk contribs created page 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:45, 24 January 2024 Ppugliese talk contribs created page 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:45, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:44, 24 January 2024 Ppugliese talk contribs created page 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:44, 24 January 2024 Ppugliese talk contribs created page 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:44, 24 January 2024 Ppugliese talk contribs created page 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:44, 24 January 2024 Ppugliese talk contribs created page 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:44, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:43, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:42, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:42, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:42, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:42, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:42, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:42, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:41, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:40, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:40, 24 January 2024 Ppugliese talk contribs created page 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:40, 24 January 2024 Ppugliese talk contribs created page 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:40, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:39, 24 January 2024 Ppugliese talk contribs created page Defining Products (Created page with "__NOTOC__ == Introduction == Let’s consider a small organisation using Scrum. Let’s assume for now there is just one team working on a certain product this company is creating. The Developers have everything in their hand, they have all the competences necessary to “get the job done”. Of course, this makes their work very flexible and adaptive: if there is anything they need to change in their development, they can simply meet shortly, decide what to change and i...")
• 00:39, 24 January 2024 Ppugliese talk contribs created page Product Ownership (Created page with "__NOTOC__ == Introduction == Product Ownership is very much linked with how we define a Product. In simple organisations, this might be an easy exercise, but in complex organisations that have what we’ll call “Composite Value Streams", Products are the result of complex interconnections of parts of one or more organisations: sequences, synergies, … of different pieces. We can consider a Value Stream as the journey from an idea to realised custome...")
• 00:39, 24 January 2024 Ppugliese talk contribs created page Leadership (Created page with "__NOTOC__ == Introduction == Scaling Agile requires support from leadership at all levels to see a real and sustained enhancement of the capability of their organisation or part of their organisation. Leaders have a duty of care to cultivate an environment or system of work to unleash the human capital in their organisations. They should see fostering an effective agile culture and all that goes with it as one of their primary responsibilities. There are many Leadersh...")
• 00:38, 24 January 2024 Ppugliese talk contribs created page Craft (Created page with "__NOTOC__ == Introduction == Agile Principle: "Continuous attention to technical excellence and good design enhances agility." Sustained delivery of value requires that quality is built into the product as it evolves. As we scale, we find that the impact of technical debt is greatly amplified by the number of teams involved and the increasing complexity of the product and the organisation developing it. == Principles == * Use the Definition of Done as an enabling co...")
• 00:38, 24 January 2024 Ppugliese talk contribs created page Teams (Created page with "__NOTOC__ == Introduction == The Team is one of the most fundamental concepts in agility: a small group of people working together to achieve a common goal. As the size of the product development increases, we might need to increase the number of people involved, hence having a team that is too big to function effectively. This means that at scale, there will be multiple teams working together. How can they organise themselves so that they retain their agility and are as...")
• 00:38, 24 January 2024 Ppugliese talk contribs created page General (Created page with "__NOTOC__ == Introduction == This section introduces overarching principles for scaling agility at an organisational or programme level. These are higher-level or meta principles - the principles in other categories provide more detail. == Principles == * Evolutionary over revolutionary change * Scale only when you need to * Start small and scale success * Organise around value streams * Minimise unnecessary complexity * Leadership supports rather...")
• 00:37, 24 January 2024 Ppugliese talk contribs created page The Coaching Perspective (Created page with "= Why Agile Coaching? = Agile teams are usually able to make local improvements to their performance, often with the assistance of a Scrum Master. Unfortunately, many Scrum Masters focus solely on their teams to the detriment of improvements to the ecosystem within which the teams work. As we scale beyond a single independent team, we see a non-linear change (increase or decrease) in value delivered due to waste and impedance from many factors including: * Product stru...")
• 00:37, 24 January 2024 Ppugliese talk contribs created page The Teams' Perspective (Created page with "__NOTOC__ == Introduction == “In the long history of humankind (and animal kind, too) that those who learned to collaborate and improvise most effectively have prevailed.” – Charles Darwin The evolutionary pressure in the world has never been more volatile and uncertain. Surviving and thriving requires organisations to respond rapidly, adapt and navigate complex challenges. An Agile organisation addresses these challenges by nurturing and supporting Agile teams...")
• 00:37, 24 January 2024 Ppugliese talk contribs created page The Product Perspective (Created page with "__NOTOC__ == A Product+Owner == The Product Owner is most definitely the most misunderstood role in Scrum. There are good reasons why this happens, as a proper implementation of that role usually requires a change in how the organisation is structured. We start by considering a small organisation using Scrum where just one team is working on a particular product this company is creating. The Developers have everything in their hands; they have all the competencies nece...")
• 00:36, 24 January 2024 Ppugliese talk contribs created page The Leadership Perspective (Created page with "__NOTOC__ = Agile Leadership at Scale = The genesis of the Agile movement emerged from the challenge of trying to solve problems in the complex world of software development. Today's complex, fast-moving business environment requires a different leadership style that incorporates many of the ideas from Lean and Agile. It is possible for a few Agile teams to “fly under the radar” and use their agility to improve their performance within an unfavourable, less than ag...")
• 00:36, 24 January 2024 Ppugliese talk contribs created page The Change Perspective (Created page with "__NOTOC__ == Adapt or Die! == Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. A fundamental leadership responsibility is to help organisations navigate OODA loops (Observe, Orient, Decide, Act) to learn and adapt continually. Any scaling endeavour will require adaption from current structures, be...")
• 00:35, 24 January 2024 Ppugliese talk contribs created page Actionable Principles (Created page with "As we, the authors of ScaleAgility, joined forces to put some clarity and structure on scaling agile, we discussed the best way to approach the topic. We noticed the scaling market is full of proposals that are often very comprehensive “bodies of knowledge”, often contradicting each other and all claiming to “work” when applied in practice. From our perspective of external observers, we recognise that many of what are usually called “frameworks” for scaling...")
• 00:35, 24 January 2024 Ppugliese talk contribs created page Where does it come from? (Created page with "==Elevator Pitch== :''For people who lead and support organisations or are responsible for complex products or services, who want to enhance the capability of their organisation or part of their organisation to respond to changing customer needs, and require multiple collaborating teams to do so, ScaleAgility guidelines provide a set of principles for sustainable scaling with options and examples.'' : ''Unlike other scaling approaches, these guidelines are non-prescrip...")
• 00:35, 24 January 2024 Ppugliese talk contribs created page Why ScaleAgility? (Created page with "We observe a very high rate of failure of large-scale agility programmes, going by names such as Agile Transformations or scaled product delivery. Scaling agility requires fundamental changes to an organisation as it is much more than a process change. Applying a new framework rarely results in sustained and positive change, with additional processes dragging progress and old habits reasserting themselves. To increase the probability of success, ScaleAgility incorporate...")
• 00:34, 24 January 2024 Ppugliese talk contribs created page What is ScaleAgility? (Created page with " At its heart, ScaleAgility is a '''Principle-Guided Evolutionary Improvement''' process that applies a set of '''[https://scaleagility.org/mediawiki/index.php/Actionable_Principles Actionable Principles]''' to understand the '''Current Context''' and '''Guide''' the direction of change. The result is an ever-evolving set of '''Emergent Practices''' adapted to support the organisation as it develops over time. In summary: ''ScaleAgility is a continuous improvement app...")
• 00:34, 24 January 2024 Ppugliese talk contribs created page Purpose of ScaleAgility (Created page with "ScaleAgility aims to increase the probability and level of success for large-scale Agile transformations and products. Although it offers an alternative approach to those offered by Scaling frameworks, ScaleAgility is not incompatible with many of the patterns contained within them. It acts as a guide to analyse and understand the current context and set your organisation on a journey of continuous improvement and fostering of emergent practices. * Engage and empower...")