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).

• 08:07, 24 January 2024 Ppugliese talk contribs moved page Why ScaleAgility? to Why ELSE? without leaving a redirect
• 08:02, 24 January 2024 Ppugliese talk contribs created page References (Created page with "<nowiki>__NOTOC__</nowiki> TODO: This has been copied from GDOCS, it probably needs updates and links? Brooks, F. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. 0-201-00650-2 Brown, B. (2015). SuperSoul Sessions: The Anatomy Of Trust. Video. <nowiki>https://brenebrown.com/videos/anatomy-trust-video</nowiki> Brown, B. (2019). The Anatomy of Trust. Uncrushed. <nowiki>https://www.uncrushed.org/content/2019/7/1/the-anatomy-of-trust-bren...") Tag: Visual edit
• 08:00, 24 January 2024 User account K reader talk contribs was created by Ppugliese talk contribs and password was sent by email
• 07:57, 24 January 2024 User account Kseger talk contribs was created by Ppugliese talk contribs and password was sent by email
• 00:58, 24 January 2024 Ppugliese talk contribs created page Product Ownership Group (Created page with "Where possible, even at scale there should be a single Product Owner being accountable for a product development and for achieving sustained end value. However, the experience of the agile community shows that there is a limit in the amount of Teams a single Product Owner can serve. Beyond that limit, there is the need of having a group of people sharing the role as a Product Ownership Group. There are severa...")
• 00:58, 24 January 2024 Ppugliese talk contribs created page Mental Workload (Created page with "Mental Workload is a concept in psychology describing the quantity of cognitive resources needed to perform a certain task. The current research is mostly focused on Mental Workload for individuals, though there are some initial studies related to Mental Workload for Teams. This concept is, in our opinion, very important in large-scale development: to have Teams capable of working on end-to-end products, they need to keep control of their development activities: the la...")
• 00:58, 24 January 2024 Ppugliese talk contribs created page Cognitive Load (Created page with "Cognitive Load is a concept that models the cognitive effort humans need to apply to learn new information[https://www.sciencedirect.com/science/article/abs/pii/B9780123876911000028]. For what we need in the context of scaling, a simplified description of the concept is that learning requires effort, and the actual amount of effort depends on two main aspects: * The Intrinsic Cognitive Load of what we want to learn. There are topics that are more or less difficult to le...")
• 00:58, 24 January 2024 Ppugliese talk contribs created page Teams of Specialists (Created page with "Teams formed around subsets of delivery - e.g technical component, specialist skillsets (e.g. marketing, sales, design, analysis) and not aligned to a value stream A subset of delivery is a process or domain part required to deliver a full value stream TODO: This description needs a review")
• 00:58, 24 January 2024 Ppugliese talk contribs created page Specialist skill sets (Created page with "This definition needs to be added/refined to cover our mentions of “component teams”, “Technical platforms” / taylorism. TODO: This definition needs completing TODO: Standardise away from Component Teams and Technical platforms")
• 00:57, 24 January 2024 Ppugliese talk contribs created page System of Work (Created page with "How work gets done: the organisational context within which value is created. This includes organisational structure, process, culture, people and commercial ecosystem (suppliers, partners, customers, etc.).")
• 00:57, 24 January 2024 Ppugliese talk contribs created page Accidental Complexity (Created page with "Is defined as complexity added by our approach and process as opposed to the inherent complexity of solving a given problem. (Brooks) This term was introduced by Fred Brooks in "No Silver Bullet—Essence and Accident in Software Engineering"")
• 00:57, 24 January 2024 Ppugliese talk contribs created page Value of a Product (Created page with "TODO : This definition needs completing We reckon it is not easy to define value for a Product. Is it… * Value perceived by our customers * Value gained by our company * Short term value * Long term value * Long term maintainability/sustainability * Current vs. Future business opportunities * Exploration of value vs. exploitation of value * Sadly, also political aspects... … A Product Owner needs to consider what is the adequate mix of factors that are relevant fo...")
• 00:57, 24 January 2024 Ppugliese talk contribs created page Outcome (Created page with "The results you expect from Product development. The observable change in the world after delivering output; ideally observed with a change in people’s behaviours. '''TODO: Improve this definition'''")
• 00:57, 24 January 2024 Ppugliese talk contribs created page Scope of Accountability for a Product Owner (Created page with "Is the part of the value stream a Product Owner is accountable for, i.e. has authority and responsibility over. TODO : Add in image The ideal Scope of Accountability for a PO is the whole value stream. For small product developments, this should happen quite naturally, but in large and composite value streams this is ... * Usually not happening at the beginning of a transformation process and * Difficult to achieve, though trying to go in that direction is an effecti...")
• 00:56, 24 January 2024 Ppugliese talk contribs created page Product Line (Created page with "A set of Products that are related. For example because of synergies among those Products, technical commonalities, business strategy etc. A Product often requires coordination among various products and often results in a Composite Value Stream")
• 00:56, 24 January 2024 Ppugliese talk contribs created page Composite Value Stream (Created page with "A Value Stream that is constructed from multiple value streams that each have independently realisable value. Because of the complexities of the organisation, it could be that parts of a composite value stream deliver internally to other value streams rather than to an external customer. This should be avoided as much as possible and value streams should deliver to external customers, however there might be good reasons to organise this way. * Example TODO Composite...")
• 00:56, 24 January 2024 Ppugliese talk contribs created page Linear Value Stream (Created page with "A Value Stream where there is a single path of value creation from idea or request to releasing value. TODO Linear Value Stream Image Upload Required")
• 00:56, 24 January 2024 Ppugliese talk contribs created page Value Stream (Created page with "A stream of activities spanning from idea or request through to customer service provision that generates value for the customers and stakeholders. The Value Stream includes these aspects, where relevant: * vision * business strategy * operational * extensibility * maintainability * regulatory * compliance * security * commercial. File:Value_Stream_Image.png")
• 00:56, 24 January 2024 Ppugliese talk contribs created page Product (Created page with "Actual goods or services providing value to customers and business. This includes physical deliverables, “soft” products and services. A Product generates outcomes. Where an outcome is an observable change in the world after delivering output. A Product is generated via a Value Stream")
• 00:54, 24 January 2024 Ppugliese talk contribs created page Glossary (Created page with "__NOTOC__ This section contains descriptions of items that we have used throughout the principles. * Product * Value Stream * Linear Value Stream * Composite Value Stream *Partial Value Stream * Product Line * Scope of Accountability for a Product Owner * Outcome * Value of a Product * Accidental Complexity * System of Work * Specialist Skill Sets * Teams of Specialists *Cognitive Load *Ment...")
• 00:54, 24 January 2024 Ppugliese talk contribs created page Self-forming teams - “bounded autonomy” (Created page with "__NOTOC__ == Description == Organisations are more complex than their org chart shows: the official hierarchy is just one of the many parallel social networks active in a company. This is relevant in any company but much more in a modern collaborative work environment. The aim is to empower the collaboration network and reduce hierarchy to speed up decision-making. Therefore it is vital to create Teams where effective teamwork is possible. As it is impossible for leade...")
• 00:54, 24 January 2024 Ppugliese talk contribs created page PO should inspect to see if outcomes have been achieved (Created page with "__NOTOC__ The PO should focus on the results that the product is achieving, focusing on individual behaviour change in product usage and have meaningful measures that illustrate progress towards business and product outcomes. This principle is moving the emphasis from measuring team(s) output to measuring the impact of their collective efforts against business value indicators. === Evidence/impact === * The PO, together with relative Teams, has established a system o...")
• 00:53, 24 January 2024 Ppugliese talk contribs created page Sources of Patterns and Practices (Created page with "There are a number of potential sources of a vast number of potential patterns that can be considered as options to be applied in a given context. === Scale Frameworks === The elements of scaling frameworks may contain practices, patterns and ideas that suit your specific context. Consider these as input into your emergent practices and patterns but do not assume they will necessarily be “Best Practices” for your circumstances, especially if adopted as a monolithic...")
• 00:53, 24 January 2024 Ppugliese talk contribs created page Shared context improves decisions (Created page with "__NOTOC__ == Description == A shared understanding of a common collective valuable purpose improves collaboration, decision-making and motivation. Ensure that all those involved in the value stream are informed and invested in the end-to-end purpose at an appropriate level of detail to provide context for decision-making. Appropriate, in this context, means that the individuals or groups understand both the higher level collective mission and the specific level of detai...")
• 00:53, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:53, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:52, 24 January 2024 Ppugliese talk contribs created page 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:52, 24 January 2024 Ppugliese talk contribs created page 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:52, 24 January 2024 Ppugliese talk contribs created page 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:52, 24 January 2024 Ppugliese talk contribs created page 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:52, 24 January 2024 Ppugliese talk contribs created page 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:51, 24 January 2024 Ppugliese talk contribs created page 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:51, 24 January 2024 Ppugliese talk contribs created page 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:50, 24 January 2024 Ppugliese talk contribs created page 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:50, 24 January 2024 Ppugliese talk contribs created page 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...")
• 00:50, 24 January 2024 Ppugliese talk contribs created page 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:50, 24 January 2024 Ppugliese talk contribs created page Favour Teams with broader Business Domain Accountability (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:50, 24 January 2024 Ppugliese talk contribs created page 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:49, 24 January 2024 Ppugliese talk contribs created page 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:49, 24 January 2024 Ppugliese talk contribs created page 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: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...")