The Enterprise Scrum Framework

Written by   on   in   with No comments

What is Enterprise Scrum?

Enterprise Scrum is an adaptation and extension of Scrum based on abstraction, generalization, and parameterization; that can be used in a scaled generic way for any management purpose.

The goal of the Enterprise Scrum is to grow unicorns and transform dinosaurs into unicorns. In other words, Enterprise Scrum powers DISRUPTION and allows companies of all sizes to be managed like startups which can simultaneously act like VCs as they grow up. 

Many of the Roles and Artifacts in Enterprise Scrum are named differently to not confuse other business people with the word "product".

Roles

  • Business Owner. Used instead of the Product Owner (PO) role.
  • Coach. Used instead of the Scrum Master (SM) role.
  • Team. It is still the Team.

Business Value

  • It is defined explicitly through a balance of the metrics (see below).

Artifacts

  • Value List. Used instead of "Product Backlog".
    • A list of things that when DONE add value. 
  • Value List Items (VLIs). Instead of Product Backlog Items (PBIs).
    • Each of them with a DOR, DOD, and other attributes. 
    • VLIs are DONE according to their DOD every Cycle. 
  • Projections
    • These are made with measurements over metrics of what got DONE (see below), so Release Planning is naturally included for all Cycles and at all levels.

Events

  • Cycle. Used instead of Sprints.
    • Cycles can be recursive without limit. 
    • You can have a yearly cycle, a quarterly cycle, or a 2-week cycle.

Techniques

  • Techniques of different types and at different levels can be included with specific parameters and inserted as 1) new steps, 2) to get work done into the framework relevant to the purpose of the instance (see below).
  • For example, techniques can be added for 1) facilitating work like User Stories, or 2) insertable NEW steps in an instance like Release Planning, or Architectural Scan added as NEW activities in the Initial Value List/Wave Projection.

Metrics and Reports

  • The only mandated report is the ScrumBoard.
  • In contrast with Scrum with 1 metric, the velocity, in Enterprise Scrum we are FREE to have as many metrics as you want/need. For example, we could track, profit, revenue, incidents, effort, customer satisfaction, compliance levels, etc.
  • In contrast with Scrum where we have the Burn down charts, in Enterprise Scrum you are FREE to choose any type of report.

Other Parameters

  • Enterprise Scrum also provides 80+ other parameters to extend, customize and apply the Scrum concepts to different domains, scaling, or adding techniques. 
  • These parameters were abstracted primarily by observing what people had already done in the field as they used Scrum for different purposes. 
  • These parameters make Enterprise Scrum a true framework, as the customizable parts are now visible and explicit. (I will release the full list of parameters later as a different publication.)

Instances

  • The framework exists as an explicitly customizable tool, but once the parameters, techniques, and added steps have been chosen, a defined Enterprise Scrum instance is created explicitly. For example, there are instances like:
    • the instance of Enterprise Scrum with User Stories and Release Planning.
    • the instance of Enterprise Scrum for Marketing.
    • the instance of Enterprise Scrum for Compliance Management.
    • the instance of Enterprise Scrum for Real State Sales.
    • the instance of Enterprise Scrum for Business Unit Portfolio management.

The Wave Principle

  • Any long-term "rough" predictions made in the Initial Value List of a longer Cycle, must be refined or recalculated after each and every shorter Cycle it includes.

References

Share:

The Fluid Teams

Written by   on   in ,   with No comments

What are Fluid Scrum Teams?

Fluid Scrum Teams organize themselves based on the work at hand. It is a vital aspect of approaches like Open Space Technology and FAST Agile. 

  • Every time new topics need to be addressed, the people of the Fluid Scrum Teams organize themselves to optimize the chances of success of the challenges. 
  • They form smaller teams each Sprint to maximize their effectiveness.

Suppose your pool of people is 20, these people organize themselves into 2 to 7 teams to address specific topics.

Fluid Scrum Teams and Scrum events

  • Sprint Planning:
    • All the Developers that work on the product, the entire pool of people, are present. 
    • The Product Owner proposes a number of objectives for the upcoming Sprint. 
  • Sprint Objectives:
    • A discussion to agree upon the objectives.
    • People of the Fluid Scrum Team self-organize themselves around the objectives.
    • They decide how to split into multiple teams working on their own objectives during one Sprint.
  • Daily Scrum:
    • The teams have their own Daily Scrums.
  • Sprint Review.
    • There's one Sprint Review reflecting upon the outcome of the work of all the teams. 
    • In every Sprint, different teams will be formed to address the objectives.
  • Fluid Scrum Teams are cross-functional.
  • Fluid Scrum Teams and self-management

Team Types

  • Complete fluidity.
    • In every Sprint, the teams that are formed can be totally different, depending on the problems at hand. 
    • This is a solution for environments that are especially complex and every new problem is distinctly different from previous problems.
  • Partial fluidity.
    • A part of the pool of people is working in stable steams addressing topics of a certain nature for multiple Sprints. 
    • Another part is fluid and organizes again and again. 
    • This approach is helpful for environments with elements of high complexity and also elements of lower complexity.
  • Specific fluidity.
    • A smaller group of people with special skills are assigning themselves to teams based on the need for their skills. 
    • Many organizations work like this. Especially when they have people that can’t work with a single team full-time. 
    • Think architects, database administrators, network specialists, and salespeople.
  • Fully stable teams.
    • The teams will not change for a longer period. 
    • In every Sprint, the teams have the same composition. 
    • This can be a good approach for environments that are complex, but with a high degree of predictability of the type of work at hand.

In complex environments, Fluid Scrum Teams can increase agility. By relaxing the constraint on stable teams, your teams will be able to handle increased complexity and tame the chaos.

References

Share:

The FAST Framework

Written by   on   in , , ,   with No comments

FAST is the acronym for Fluid Scaling Technology. Fluid Scaling Technology combines OpenSpace Technology1 and Open Allocation to create a  lightweight, simple-to-understand, and simple-to-master method for organizing people around work - that scales.

Where and When to use FAST

  • FAST is ideally suited for business environments or challenges that show complexity, rapid change, or where there is a need for innovation. 
  • FAST is ideal for software development, product development, and agile at scale - because of their typically complex nature. 
  • FAST is applicable to most complex collaborative endeavors and is not limited to just the software domain.
  • FAST is built on fluid (re)teaming rather than static teams to maximize adaptability.
  • FAST is the same process at the small through to the large scale.
  • FAST is not built on Scrum. Instead, FAST is built on OpenSpace Technology.
  • FAST operates as a pure complex system
    • FAST also accommodates complicated and simple work.

FAST Roles

  • Product Manager. 
    • This role is not one of authority and command but more inspiration. 
    • Motivation, encouragement, communicating a clear vision, recommunicating the vision often, direction setting, standard-setting, providing feedback, and modern product management.
  • Team Members: 
    • A T-shaped team player committed to delivery, collaboration, communication, listening, continuous learning, and personal mastery.
    • Generalizing specialists.
  • Team Steward:
    • Natural leadership role where a Team Member has chosen to steward some work in a Value Cycle. 
    • Just as teams are fluid in FAST, team stewardship is fluid and not static.
  • Feature Steward (Optional):
    • As teams are not static in FAST, it can make sense for at least one person to stay with a feature/opportunity/outcome to see it all the way through to completion. 
    • Provide continuity across Value Cycles and serve as a point of contact for stakeholders. 
    • It is not required to work continuously on the feature they are stewarding, only to have a continuous understanding of the work.

FAST Artifacts

  • Product Map – The Big Picture.
    • It's an extension of Jeff Patton's Story Mapping (Patton). The difference is that a Product Map focuses on high-level elements only, e.g. bets, capabilities, opportunities, aspects, desired outcomes, business goals, initiatives, themes, and features.
    • It's s a way to visualize what the Collective is doing as a whole. The map shows progress at a high level by the ratio of started, not started, and done.
    • Finer-grained details of high-level items are represented in Discovery Trees.
  • Discovery Trees – Thinking Big While Working Small.
    • Whenever work starts on a high-level item, create a Discovery Tree. A Discovery Tree represents the complexity of work while giving context to work items.
    • Break down work to understand, discover, or plan. But only just enough and just in time. 
    • As work recursively gets broken down from a high-level item into smaller subcomponents, a structure of branch and leaf nodes reveals itself.
    • The current progress toward node completion is evident by the ratio of nodes started, not started, or completed (or removing completed nodes from the tree).
  • Marketplace Board.
    • It visually represents a marketplace of work for a Value Cycle. 
    • The board shows what is happening in the current Value Cycle and who is on which team. (The FAST Marketplace Board borrows from OpenSpace's Bulletin Board.)
    • Each column on the Marketplace Board might represent a physical collaboration area. 
    • To constrain work in progress (WIP), limit the number of places available in the Marketplace.
    • On the board, this might mean restricting or removing columns.
  • Collective Agreements – How We Self-manage
    • It's a living document that describes the rules and mechanics of self-management within the Collective. Collective Agreements create and protect harmony and psychological safety. At a minimum, it should include: 
      • How do we make decisions?
      • How do we resolve conflict?
      • How do we change the Collective's Agreements?
      • Where do we keep the Agreements?

FAST Meeting

The FAST Meeting is the only event in FAST and it is facilitated by the FAST Product Manager. The current Value Cycle is declared closed, and the next starts.

  • Phase 1: Closing the Current Value Cycle.
    • Collective Synchronisation via Show and Tell. A representative from each team briefly summarises their team's work in the last Value Cycle, highlighting value delivered and discoveries made. It includes concise demonstrations if helpful.
    • Once all teams have completed their show and tell, the Value Cycle is closed.
    • Clear the Marketplace Board in readiness to repopulate again in the next Value Cycle.
  • Phase 2: Starting the Next Value Cycle. 
    • Reiterate Vision and Set Direction
    • Each FAST Meeting is an opportunity for the Product Manager to align, rally, and reinspire the Collective by reiterating the product vision, mission(s), and purpose. In addition, the Product Manager may choose to set priorities or direction for the Value Cycle. 
    • The Product Map can be a useful visual aid for this, and why having it on permanent display in the forum is recommended. 
  • Phase 3: Emerging Work & Self-selecting into Teams.
    • Create and Open the Marketplace.
    • Any Member can stand up in front of the Collective and declare their intent to steward a goal. The goal may be related to priorities just announced. Or not.
    • Once volunteers have stopped coming forward to steward work or the WIP limit has been reached, the Marketplace is declared open.
    • Collective Members then self-select into whichever team they feel they can contribute the most value to, or learn and grow the most from. 
    • Members go to the Marketplace Board and put their names into the slot associated with the goal they are interested in working on for that cycle.
    • Teams might be a component, feature, discovery team, or other, dependent on the work.
    • Teams have the autonomy to do whatever they feel is the best and right thing needed to add value.
  • Announcements (Optional). 
    • The Collective being gathered is an opportunity to make announcements. Announcements may be unrelated to work in the Value Cycle but are still relevant to the Collective.
  • Starting Work - Resolve Dependencies, Architect, Design, Plan, and Collaborate.
    • The dynamically formed teams now go to their chosen development area and plan. Each team tasks out their work and agrees on how they will collaborate. Should a team identify that they are likely to clash with another team or have dependencies, they meet with the other team(s) and discuss. To resolve dependencies or clashes, they might:
      • Merge.
      • Pick up some other work.
      • Have a design discussion, then plan if and how to divide labor.
      • Resolving dependencies this way can happen at any point in the cycle.

FAST Cadence and Flow

  • Synchronize the Collective to a shared understanding (via show and tell).
  • The pause between cycles is a sensing point to adjust teams, or work items should a better fit make sense. What was discovered in the last cycle? Has our understanding of the work or customer changed? Did any metrics change? Etc.
  • Revisit the purpose and vision of the product and company. Repetition, repetition... 
  • Cycles are not time boxes. Sign-off can happen at any point. Therefore, continuous delivery/deployment is a compatible natural fit and highly recommended for FAST.

FAST Adoption

FAST is a method that works on a small scale, large scale, and everything in between. It is the same process throughout, with only a few minor differences. A Collective is typically responsible for only one product or value stream in its entirety, but multiple products for a Collective are feasible. In the case of multiple products, the Product Manager can be singular or plural.
  • Small-scale FAST – Fewer Than 14 People. 
    • Use small-scale FAST when a Team has (roughly) fewer than fourteen people. 
    • Small-scale FAST can replace/supersede Scrum.
    • The collaboration units that Collective breaks into are smaller than in large-scale FAST. 
    • The smallest collaboration unit in small-scale FAST is two people, and pair programming is recommended when two. 
    • Mob Programming (Pearl) works well for collaboration units larger than two people.
  • Large-scale FAST – 14 to 200 People. 
    • Large-scale FAST is for a Collective of around fourteen or more people.
    • Collaboration units are typical agile software team sizes, e.g. 3-13 people.
    • Once a Collective grows too far past Dunbar's number (150), split and spin off a new Collective.
  • FAST Portfolio describes multiple Collectives. 
    • Working in this mode, FAST Product Managers meet for portfolio discussions.

FAST in Enterprise

  • FAST can integrate with other enterprise methods such as BOSSA nova, FLEX, and SAFe.

FAST Continuous Improvement.

  • FAST is not prescriptive on methods for implementing the principle of reflect and tune.
  • Each Collective should experiment and discover what works best. Some ideas and options:
    • Form a FAST Guild that meets on cadence to reflect and tune.
    • Host regular OpenSpace Events for the Collective with the theme Reflect and Tune.
    • Add a Turn Up the Good section to the FAST Meeting.

References

Share:

The Scrum@Scale Framework

Written by   on   in , ,   with No comments

Scrum of Scrums (SoS)

A Scrum of Scrums operates as if it were a Scrum Team, satisfying the Team Process component with scaled versions of the Scrum accountabilities, events, and artifacts. While the Scrum Guide defines the optimal team size as being fewer than 10 people, Harvard research has determined that the optimal team size is 4.6 people (on average). Therefore, the optimal number of teams in a Scrum of Scrums is 4 or 5.

As a dynamic group, the teams composing the Scrum of Scrums are responsible for a fully integrated set of potentially shippable increments of product at the end of every Sprint. Optimally, they carry out all of the functions required to release value directly to customers.

Scrum of Scrums of Scrums (SoSoS)

Depending upon the size of the implementation, more than one Scrum of Scrums may be needed to deliver a complex product. In such cases, a Scrum of Scrum of Scrums (SoSoS) can be created out of multiple Scrums of Scrums. Each of these will have scaled versions of each Scrum of Scrums’ roles, artifacts, and events.

Scaled Events

  • Scaled Daily Scrum (SDS). 
    • The main talking points of a Daily Scrum are the progress towards the Sprint Goal and impediments to meeting that commitment. 
    • In a scaled setting, the Scrum of Scrums needs to understand collective progress and be responsive to impediments raised by participating teams; therefore, at least one representative from each team attends a Scaled Daily Scrum (SDS). 
    • Any person or number of people from participating teams may attend as needed.
    • To optimize collaboration and performance, the Scaled Daily Scrum event mirrors the Daily Scrum, in that it:
      • Is time-boxed to 15 minutes or less.
      • Must be attended by a representative of each team.
      • Is a forum to discuss how teams can work together more effectively, what has been done, what will be done, what is going wrong & why, and what the group is going to do about it
      • Some examples of questions to be answered:
        • What impediments does a team have that will prevent them from accomplishing their Sprint Goal or that will impact the delivery plan?
        • Is a team doing anything that will prevent another team from accomplishing their Sprint Goal or that will impact their delivery plan?
        • Have any new dependencies between the teams or a way to resolve an existing dependency been discovered?
  • Scaled Retrospective. 
    • Every Sprint, the Scrum of Scrums holds a scaled version of the Sprint Retrospective where the Scrum Masters of each team get together and discuss what experiments have been done to drive continuous improvement and their results. 
    • Additionally, they should discuss the next round of experiments and how successful improvements can be leveraged across the group of teams or beyond.

Scaled Accountabilities

  • Scrum of Scrums Master (SoSM). 
    • The Scrum of Scrums Master is accountable for ensuring the Scaled events take place, are productive, positive, and kept within the time box. 
    • The Scrum of Scrums Master may be one of the team's Scrum Masters or a person specifically dedicated to this role. 
    • They are accountable for the release of the joint teams' efforts and continuously improving the effectiveness of the Scrum of Scrums. This includes greater team throughput, lower cost, and higher quality. In order to achieve these goals, they must:
      • Work closely with the Chief Product Owner to deliver a potentially releasable product increment at least every Sprint.
      • Coordinate the teams’ delivery with the Product Owners' Team's release plans
      • Make impediments, process improvements, and progress visible to the organization
      • Facilitate the prioritization and removal of impediments, paying particular attention to cross-team dependencies
  • Executive Action Team (EAT). 
    • It fulfills the Scrum Master accountabilities for an entire agile organization. This leadership team creates an agile ecosystem that allows the Reference Model to function optimally, by:
      • Implementing the Scrum values
      • Assuring that Scrum roles are created and supported
      • Scrum events are held and attended
      • Scrum Artifacts and their associated commitments are generated, made transparent, and updated throughout each Sprint.
      • Formulating guidelines and procedures that act as a translation layer between the Reference model and any part of the organization that is not agile.
    • The Executive Action Team is accountable for removing impediments that cannot be removed by members of the Scrum of Scrums (or wider network).


Notes

  • Scrum@Scale is also known as Scrum of Scrums.

References

Share:

The LeSS Framework

Written by   on   in ,   with No comments

Agile development with Scrum requires a deep organizational change to become agile. Therefore, neither Scrum nor LeSS should be considered merely a practice. Rather, they form an organizational design framework.

LeSS provides two different large-scale Scrum frameworks. Most of the scaling elements of LeSS are focused on directing the attention of all of the teams to the whole product instead of "my part." Global and "end-to-end" focus are perhaps the dominant problems to solve in scaling. The two frameworks – which are basically single-team Scrum scaled up – are:

  • LeSS: Up to eight teams (of eight people each).
  • LeSS Huge: Up to a few thousand people on one product.

Same as Scrum

LeSS is a scaled-up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS, you will find:
  • A Single Product Backlog (because it’s for a product, not a team),
  • One Definition of Done for all teams.
  • One Potentially Shippable Product Increment at the end of each Sprint.
  • One Product Owner.
  • Many complete, cross-functional teams (with no single-specialist teams),
  • One Sprint.

Different than Scrum

  • Sprint Planning Part 1: In addition to the one Product Owner, it includes people from all teams. Let team members self-manage to decide their division of Product Backlog Items. Team members also discuss opportunities to find shared work and cooperate, especially for related items.
  • Sprint Planning Part 2: This is held independently (and usually in parallel) by each Team, though sometimes for simple coordination and learning two or more Teams may hold it in the same room (in different areas).
  • Daily Scrum: This is also held independently by each Team, though a member of Team A may observe Team B’s Daily Scrum, to increase information sharing.
  • Coordination: Just Talk, Communicate in Code, Travelers, Open Space, and Communities.
  • Overall PBR: There may be an optional and short overall Product Backlog Refinement (PBR) meeting that includes the Product Owner and people from all teams. The key purpose is to decide which teams are likely to implement which items and therefore select those items for later in-depth single-team PBR. It is also a chance to increase alignment with the Product Owner and all teams.
  • Product Backlog Refinement: The only requirement in LeSS is single-team PBR, the same as in one-team Scrum. But a common and useful variation is multi-team PBR, where two or more Teams are in the same room together, to increase learning and coordination.
  • Sprint Review: In addition to the one Product Owner, it includes people from all teams, and relevant customers/users, and other stakeholders. For the phase of inspecting the product increment and new items, consider a “bazaar” or “science fair” style: a large room with multiple areas, each staffed by team members, where the items developed by teams are shown and discussed.
  • Overall Retrospective: This is a new meeting not found in one-team Scrum, and its purpose is to explore improving the overall system, rather than focusing on one Team. The maximum duration is 45 minutes per week of Sprint. It includes the Product Owner, Scrum Masters, and rotating representatives from each Team.

Less Huge

References

Share:

The Nexus Framework

Written by   on   in ,   with No comments

A Nexus is a group of approximately three to nine Scrum Teams that work together to deliver a single product; it is a connection between people and things. A Nexus has a Single Product Owner who manages a single Product Backlog from which the Scrum Teams work.

The Nexus framework defines the accountabilities, events, and artifacts that bind and weave together the work of the Scrum Teams in a Nexus. It minimally extends the Scrum framework only where absolutely necessary to enable multiple teams to work from a Single Product Backlog to build an Integrated Increment that meets a goal.

The Nexus Framework helps teams solve common scaling challenges like reducing cross-team dependencies, preserving team self-management and transparency, and ensuring accountability. 

  • Nexus helps to make transparent dependencies. 
  • Nexus provides opportunities to change the process, product structure, and communication structure to reduce or remove these dependencies.

Nexus Accountabilities

  • Nexus Integration Team. The Team is accountable for ensuring that a done Integrated Increment (the combined work completed by a Nexus) is produced at least once a Sprint. 
    • It provides the focus that makes possible the accountability of multiple Scrum Teams to come together to create valuable, useful Increments, as prescribed in Scrum.
    • Integration includes addressing technical and non-technical cross-functional team constraints that may impede a Nexus’ ability to deliver a constantly Integrated Increment.
    • It should use bottom-up intelligence from within the Nexus to achieve resolution.
  • The Product Owner: 
    • A Product Backlog has a single Product Owner who has the final say on its contents. 
    • The Product Owner is accountable for maximizing the value of the product and the work performed and integrated by the Scrum Teams in a Nexus. 
    • Is accountable for effective Product Backlog management.
  • A Scrum Master: 
    • The Scrum Master in the Nexus Integration Team is accountable for ensuring the Nexus framework is understood and enacted as described in the Nexus Guide. 
    • This Scrum Master may also be a Scrum Master in one or more of the Scrum Teams in the Nexus.        
  • One or more Nexus Integration Team Members: 
    • Scrum Team members who help the Scrum Teams to adopt tools and practices that contribute to the Scrum Teams’ ability to deliver a valuable and useful Integrated Increment that frequently meets the Definition of Done.

Nexus Events 

Nexus adds to or extends the events defined by Scrum. 

  • The duration of Nexus events is guided by the length of the corresponding events in the Scrum Guide. They are timeboxed in addition to their corresponding Scrum events.
  • It may not be practical for all members of Nexus to participate to share information or come to an agreement. Except where noted, Nexus events are attended by whichever members of the Nexus are needed to achieve the intended outcome of the event most effectively.
  • The Sprint. A Sprint in Nexus is the same as in Scrum.
  • Cross-Team Refinement. Reduces or eliminates cross-team dependencies within a Nexus. 
    • The Product Backlog must be decomposed so that dependencies are transparent, identified across teams, and removed or minimized. 
    • Product Backlog items pass through different levels of decomposition from very large and vague requests to actionable work that a single Scrum Team could deliver inside a Sprint.
    • The frequency, duration, and attendance of Cross-Team Refinement vary.
    • Where needed, each Scrum Team will continue its own refinement in order for the Product Backlog items to be ready for selection in a Nexus Sprint Planning event. 
  • Nexus Sprint Planning. Coordinates the activities of all Scrum Teams within a Nexus for a single Sprint. Appropriate representatives from each Scrum Team and the Product Owner meet to plan the Sprint. The result of Nexus Sprint Planning is:
    • A Nexus Sprint Goal that aligns with the Product Goal and describes the purpose that will be achieved by the Nexus during the Sprint
    • A Sprint Goal for each Scrum Team that aligns with the Nexus Sprint Goal.
    • A Single Nexus Sprint Backlog that represents the work of the Nexus toward the Nexus Sprint Goal and makes cross-team dependencies transparent
    • A Sprint Backlog for each Scrum Team, which makes transparent the work they will do in support of the Nexus Sprint Goal.
  • Nexus Daily Scrum. The purpose is to identify any integration issues and inspect progress toward the Nexus Sprint Goal. 
    • Appropriate representatives from the Scrum Teams attend the Nexus Daily Scrum, inspect the current state of the integrated Increment, and identify integration issues and newly discovered cross-team dependencies or impacts. 
    • Each Scrum Team’s Daily Scrum complements the Nexus Daily Scrum by creating plans for the day, focused primarily on addressing the integration issues raised during the Nexus Daily Scrum.
  • Nexus Sprint Review. It is held at the end of the Sprint to provide feedback on the done Integrated Increment that the Nexus has built over the Sprint and determine future adaptations.
    • The Nexus Sprint Review replaces individual Scrum Team Sprint Reviews. 
  • Nexus Sprint Retrospective. The purpose is to plan ways to increase quality and effectiveness across the whole Nexus. 
    • The Nexus inspects how the last Sprint went with regards to individuals, teams, interactions, processes, tools, and its Definition of Done.
    • In addition to individual team improvements, the Scrum Teams' Sprint Retrospectives complement the Nexus Sprint Retrospective by using bottom-up intelligence to focus on issues that affect the Nexus as a whole.

Nexus Artifacts

  • Product Backlog. There is a single Product Backlog that contains a list of what is needed to improve the product for the entire Nexus and all of its Scrum Teams. At scale, the Product Backlog must be understood at a level where dependencies can be detected and minimized.
    • Commitment: Product Goal - The Product Goal, describes the future state of the product and serves as a long-term goal of the Nexus.
  • Nexus Sprint Backlog. It is the composite of the Nexus Sprint Goal and Product Backlog items from the Sprint Backlogs of the individual Scrum Teams. It is used to highlight dependencies and the flow of work during the Sprint. The Nexus Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that the Nexus can inspect their progress in the Nexus Daily Scrum.
    • Commitment: Nexus Sprint Goal. It is a single objective for Nexus. 
  • Integrated Increment. It represents the current sum of all integrated work completed by a Nexus toward the Product Goal. The Integrated Increment is inspected at the Nexus Sprint Review but may be delivered to stakeholders before the end of the Sprint. 
    • The Integrated Increment must meet the Definition of Done.
Share:

The Scrum Framework

Written by   on   in ,   with No comments

The Scrum framework is defined in The Scrum Guide and was introduced as a better way of team collaboration for solving complex problems. The Scrum framework is fairly simple being made up of a Scrum Team consisting of a Product Owner, a Scrum Master, and Developers, each of which has specific accountabilities. 

The Scrum Team takes part in five events and produces three artifacts. The Scrum Guide contains the definition of Scrum,  describing the Scrum accountabilities, events, artifacts, and the guidance that binds them together.

Scrum Accountabilities 

  • Scrum Master: The person on the Scrum Team who uses their knowledge of Scrum to help the team and organization to be as effective as they can be; they do so by taking approaches like coaching, teaching, facilitating, and mentoring
  • Product Owner: The person on the Scrum Team who makes sure that the team is creating the most valuable product they can create.
  • Developers - the people on the Scrum Team who work together to create the product.

Scrum Events

  • Sprint: Short cycles of one month or less, during which the work is done; the Sprint contains all of the other Scrum events; a new Sprint starts immediately after the conclusion of the previous Sprint
  • Sprint Planning: The event is dedicated to planning out the work that will take place during the Sprint
  • Daily Scrum: The event is held every day where the Developers inspect the progress toward the Sprint Goal, uncover anything that may be getting in their way and adapt accordingly
  • Sprint Review: The event is held at the end of the Sprint where the Scrum Team and key stakeholders review what was accomplished in the Sprint and what has changed in their environment; next, attendees collaborate on what to do next
  • Sprint Retrospective: The Scrum Team gets together during this event to talk about how the last Sprint went and identify the most helpful changes to improve their effectiveness

Scrum Artifacts

  • Product Backlog - an evolving, ordered list of what is needed to improve the product; it is the single source of work undertaken by the Scrum Team
    • Commitment: Product Goal -  the target the team plans against 
  • Sprint Backlog - a highly visible list of work that is the Developer’s plan for Sprint, which may evolve as they learn
    • Commitment: Sprint Goal - the single objective of the Sprint
  • Increments - small pieces of work that serve as concrete stepping stones toward the Product Goal. You can deliver as often as needed during the Sprint and are not limited to only one release per Sprint.
    • Commitment: Definition of Done -  the description of what it takes for an Increment to be considered complete

References

Share:

The Kanban Method

Written by   on   in ,   with No comments

With Kanban, you can manage work. It is a method to manage all types of professional services, also referred to as knowledge work.

Using the Kanban method means applying a holistic way of thinking about your services with a focus on improving them from your customers' perspective.

Kanban is not a methodology nor a process framework. Rather, it is a management method or approach that should be applied to an existing process or way of working.

STATIK

The STATIK approach should be applied to each service. It will result in a full Kanban system design. Throughout the process, systems thinking should be applied. The (future) system is always considered as a whole, with the goal of improving the flow of value to customers.

Kanban Boards

Kanban boards are the most common means of visualizing a Kanban system. 
  • Common to all boards is pulling work from left to right through the board: on the left, new work items enter the board. When they exit on the right, value is delivered to customers.
  • There is at least one clear commitment and delivery point and a representation of the permitted amount of work (Work in progress, WIP).
  • Work Items can be of different types and sizes, from tasks to requirements, types of artifacts, (groups of) product features and topics to projects or product packages on higher-level boards.
  • Work items are typically displayed on individual (paper) notes, which are usually called cards or tickets.
  • The series of activities these work items go through is referred to as Workflow. Kanban is based on the "Start where you are now" approach, so, the actual workflow (not a wishful future image) is being modeled on the Kanban board.
  • The individual steps in the workflow and buffers are shown in columns.
  • Lanes are often used for different work types, projects, etc. to distribute capacity.
  • The workflow is modeled on the board. Different colored notes can be used, for example, to represent different types of work items.
  • The flow of work and its risks should be realistically shown in their true current state rather than a wishful image of the future at all times.

WIP Limits and Pull

The so-called WIP limit, i.e., the maximum number of work items allowed at a time, can be defined per work state(s), per person, per lane, per type of work, for a whole Kanban system, etc. WIP limits are typically represented by a number in a circle, above the respective columns.
  • Limiting the work that is allowed to enter the system is an important key to reducing delay and context switching which may result in poor timeliness, quality, and potential waste.
  • The aim is to create a balance between demand and capability over time.
  • Limiting the work that is allowed to enter the system also creates a continuous flow of work in which drawing or "pulling" work only happens if there is capacity. 
  • A virtual pull signal is generated when the WIP limit is not fully utilized. While work on the board moves to the right, pull signals move to the left, further upstream.

Core Kanbas Metrics

  • Lead time is the time it takes for a single work item to pass through the system from the start (commitment point) to completion.
  • Delivery rate is the number of completed work items per unit of time, such as features per week, training classes per month, or new hires per month.
  • WIP (work in progress) is the number of work items in the system (or a defined part of it) at a certain point in time.
  • Cumulative flow diagram (CFD). It is useful information regarding the flow of work across multiple activities. The colored areas in the diagram represent the number of work items within a particular activity in the workflow and how these work items move across all activities, from top to bottom, over time until done.

Kanban Cadences

Please note that like all elements of a Kanban implementation, the cadences can and should be set up to it within the given organizational context. In practical terms, this means:

  • Identify existing meetings and reviews that already serve a similar purpose and continually evolve them.
  • Keep the existing names or use the standard cadence naming or come up with something else. It is the purpose that matters.
  • Pick the frequency and duration based on your context. In many cases, having more frequent but shorter meetings over time increases agility.

References

Share:

The eXtreme Programming Method

Written by   on   in   with No comments

The Rules of Extreme Programming

References

Share:

The 6 Types of Socratic Questions

Written by   on   in   with No comments

1. Clarifying Thinking and Understanding

Get them to think more about what exactly they are asking or thinking about. Prove the concepts behind their answer or argument. Use basic "tell me more" questions to get deeper.

  • "Can you give me an example?"
  • "Can you explain further?"
  • "Are you saying..."
  • "What is the problem you are trying to solve?"

2. Challenging Assumptions

  • "Is that always the case?"
  • "Are you assuming...?"
  • "How can you verify or disprove that?"
  • "What would happen if?"

3. Examine Evidence & Rationale

  • "Why do you say that?"
  • "How do you know?"
  • "Why?"
  • "What evidence is there that supports..."

4. Considering Alternative Perspectives

  • "Are there any alternatives?"
  • "What is the other side of the argument?"
  • "What makes your viewpoint better?"
  • "Who would be affected and what would they think?"

5. Considering Implications and Consequences

  • "What are the implications/consequences of...?"
  • "How does that affect....?"
  • "What if you are wrong?"
  • "What our experience tells us will happen?"

6. Meta Questions

  • "Why do you think I ask that question?"
  • "What does... mean?"
  • "What is the point of the question?"
  • "What else might I ask?"

References

Share:

The Business Model Canvas

Written by   on   in ,   with No comments

What is the Business Model Canvas?

The Business Model Canvas (BMC) is a strategic management tool to quickly and easily define and communicate a business idea or concept.

  • The right side of the BMC focuses on the customer (external), while, the left side of the canvas focuses on the business (internal). 
  • Both external and internal factors meet around the value proposition, which is the exchange of value between your business and your customer/clients.

Value Proposition

It is the fundamental concept of the exchange of value between your business and your customer/clients.
  • Value Proposition is the value exchanged from a customer for money when a problem is solved or pain is relieved for them by your business.
  • It is important to have context around the goals the company is trying to achieve for its Customer Segments and where your business/product/service fits in the value chain.
Good questions to ask when defining your business/product:
  • What is the problem I am solving?
  • Why would someone want to have this problem solved?
  • What is the underlying motivator for this problem?

Customer Segments

Customer Segmenting is the practice of dividing a customer base into groups of individuals that are similar in specific ways, such as age, gender, interests, and spending habits.

Things to consider when determining your Customer Segments:
  • Who are we solving the problem for?
  • Who are the people that will value my value proposition?
  • Are they another business?
  • If so, what are the characteristics of those businesses?
  • Or, are they other people?
  • Does my value proposition appeal to men/women or both?
  • Does it appeal to young adults aged 20 to 30 or teenagers?
  • What are the characteristics of the people who are looking for my value proposition?
To continue...

References

Share:

The Cynefin Framework

Written by   on   in ,   with No comments

The Cynefin framework is a problem-solving tool that helps you put situations into five "domains" defined by cause-and-effect relationships. This helps you assess your situation more accurately and respond appropriately. It was developed by David J. Snowden.

The Five Domains

  • Obvious Contexts – "The Domain of Best Practice"
    • The options are clear and cause-and-effect relationships are apparent to everyone.
    • You need to "Sense – Categorize – Respond" to the obvious decisions. 
      • Assess the situation, categorize its type, and then base your response on best practices. There is often one established "correct" answer, based on an existing process or procedure.
    • There is a danger (oversimplification). 
      • Leaders, or an organization, experience success and then become complacent:
        • Make sure that there are clear communication channels in place, so that team members can report any situations that don't fit with any established category.
        • Avoid micromanaging and stay connected in order to spot a change in context.
      • Leaders may not be receptive to new ideas because of past experiences and success. 
        • Stay open to new ideas and be willing to pursue innovative suggestions.
        • Create a communication channel—an anonymous one, if necessary—that allows dissenters to provide early warnings about complacency.
      • Frequently collapses into Chaos occur because success has bred complacency.
  • Complicated Contexts – "The Domain of Experts"
    • There is a clear relationship between cause and effect, but it may not be visible to everyone. For example, you might see several symptoms of a problem but not know how to fix it.
    • You need to "Sense – Analyze – Respond"
      • Assess the situation, analyze what is known (often with the help of experts), and decide on the best response, using good practice.
    • There is a danger:
      • Leaders may rely too heavily on experts in complicated situations while dismissing or overlooking creative solutions from other people. 
        • Assemble a team of people from a wide variety of backgrounds (including rebels and dissenters), and use tools such as Crawford's Slip Writing Method to ensure that everyone's views are heard.
  • Complex Contexts – "The Domain of Emergence"
    • It might be impossible to identify one "correct" solution, or spot cause-and-effect relationships, in "complex" situations. 
    • You need to "Probe – Sense – Respond." 
      • Complex contexts are often unpredictable.
      • Rather than trying to control the situation or insisting on a plan of action, it's often best to be patient, look for patterns, and encourage a solution to emerge.
      • It can be helpful to conduct business experiments in these situations and accept failure as part of the learning process. 
      • Make sure that you have processes in place to guide your team's thinking – even a simple set of rules can lead to better solutions than no guidance at all.
      • Gather a diverse group of people to come up with innovative, creative solutions to complex problems. 
      • Use brainstorming tools such as Random Input or Provocation to generate new ideas, and encourage your team to debate the possibilities.
Tip:
Complicated and complex situations are similar in some ways, and it can be challenging to tell which of them you're experiencing. However, if you need to make a decision based on incomplete data, for example, you're likely to be in a complex situation.

  • Chaotic Contexts – "The Domain of Rapid Response"
    • No relationship between cause and effect exists, so your primary goal is to establish order and stability. Crisis and emergency scenarios often fall into this domain.
    • You need to "Act – Sense – Respond" 
      • Act decisively to address the most pressing issues, sense where there is stability and where there isn't, and then respond to move the situation from chaos to complexity.
      • Conduct a Risk Analysis to identify possible risks, prioritize them with a Risk Impact/Probability Chart, and make sure that you have a comprehensive crisis plan in place. 
      • It's impossible to prepare for every situation, but planning for identifiable risks is often helpful.
      • Reliable information is critical in uncertain and chaotic situations, so make sure you know how to communicate in a crisis. 
  • Disorder
    • It can be extremely difficult to identify when you're in a "disorder" situation. Here, it isn't clear which of the other four domains is dominant, and people generally rely on decision-making techniques that are known and comfortable. 
    • Your need to "Gather Information" so that you can move into a known domain and then take the appropriate action.

References

Share:

The Managing Complex Change Model

Written by   on   in   with No comments

The Lippitt-Knoster Model for Managing Complex Change is an excellent tool both to plan Change, as well as to diagnose issues when a project is already happening. It provides a consolidated map of all the elements needed, and I particularly like the focus on Incentives, as these are way too often missed in many alternative models.

The Key Components of the Model for Managing Complex Change

  • Vision:
    • Why is change needed?
    • Shared and are people buying in? 
    • Are there measurable, achievable goals? 
  • Consensus:
    • Leaders cannot assume they have the power to push through change without gaining a consensus. 
  • Skills:
    • What skills are needed? 
    • Do staff members have expertise or training in what they are being asked to do? 
    • If not, will it be provided by someone they trust?
  • Incentives:
    • How will employees benefit them? 
    • Can be tangible such as monetary, or intangible such as personal achievement or prestige.
  • Resources:
    • What resources are readily available? 
    • Are they appropriate? 
    • Are there in-house people who are resources? 
    • Is the distribution of resources fair? 
    • What resources are needed and how will you get them?
  • Action Plan:
    • The action plan for change should be clear and developed by a representation of all stakeholders. 
    • Without a plan, gaining traction and moving forward is impossible.

The possible negative change outcomes

  • Confusion.
  • Sabotage.
  • Anxiety.
  • Resistance.
  • Frustration.
  • Treadmill or False Start.

References

Share:

The 8 Steps Process for Change

Written by   on   in   with No comments

Step 1: Create A Sense Of Urgency

In order to build the business case internally and build momentum within the entire organization, a Change Agent must appeal to and influence both Thinking (our new Rational brains) and Feeling (our older Reptilian brains).

  • Make a compelling story.
  • Use of metaphors, analogies, and imagery.
  • Use simple language and avoid jargon and acronyms.
  • Frequent, consistent, and aligned communication.
  • Energy and enthusiasm are infused throughout.
  • Careful use of data – don’t overuse it.
  • Do your homework to understand what people are feeling.
  • Rid the channels of communication of junk so that important messages come through.
  • High level of visibility.
  • Bring the outside in.
  • Communicate with what you DO not just what you SAY.

Step 2: Build A Guiding Coalition

This step involves pulling together a group with enough power to lead change. 

  • It must have the right composition, a significant level of trust, and a strong shared objective. 
  • The elimination of the individualistic ego, and the fortitude to work through ongoing inertia.
  • The Guiding Coalition should feature the following four qualities:
    • Position Power:  Enough key players should be on board so that those left out cannot block progress.
    • Expertise:  All relevant points of view should be represented so that informed intelligent decisions can be made.
    • Credibility:  The group should be seen and respected by those in the firm so that the group’s pronouncements will be taken seriously by other employees.
    • Leadership:  The group should have enough proven leaders to be able to drive the change process.

Step 3: Form A Change Vision

In this step, the Guiding Coalition needs to clarify how the future will be different from the past. This is achieved through an organizational vision. 

Kotter outlines six characteristics of effective visions:

  • Imaginable: They convey a clear picture of what the future will look like.
  • Desirable: They appeal to the long-term interest of those who have a stake in the enterprise.
  • Feasible: They contain realistic and attainable goals.
  • Focused: They are clear enough to provide guidance in decision-making.
  • Flexible: They allow individual initiative and alternative responses in light of changing conditions.
  • Communicable: They are easy to communicate and can be explained quickly.

Step 4: Communicate The Vision For Buy In

In this step, the guiding coalition needs to ensure that as many people as possible understand and accept the vision. A good rule of thumb is to amplify communication of the vision by a factor of ten.  A single memo or series of speeches by the CEO will not cut it - it needs to be communicated in hour-by-hour activities and anywhere and everywhere - referred to in emails, meetings, and presentations.

Kotter outlines some guidelines for communicating the vision. These are:

  • Simple: No techno babble or jargon.
  • Vivid: A verbal picture is worth a thousand words – use metaphor, analogy, and example.
  • Repeatable: Ideas should be able to be spread by anyone to anyone.
  • Invitational: Two-way communication is always more powerful than one-way communication.
  • Again, keep the Golden Circle in mind as a reference point.
  • Actions definitely speak louder than words. An entire team of senior managers who do this sends a powerful message which can inspire confidence, decrease cynicism and change internal cultures.

Step 5: Empower Broad-Based Action

After the vision has been defined and communicated, the organization needs to remove as many barriers as possible and unleash its employees to do their best work.

  • Structural Barriers. 
    • Internal structures within an organization can often be at odds with the change vision. 
    • This again is manifested as bloated middle management, siloed departments, and an over-emphasis on managers over makers.
    • Two strategies work here. 
      • First, realign incentives and performance appraisals to reward and reflect the thing you most value as a business. 
      • Second, concentrate on improving management information systems. 
    • The goal is to speed up feedback loops and provide the information necessary for employees to do their jobs more efficiently.
  • Supervisory Barriers
    • This basically refers to troublesome supervisors. 
    • They are often defined by locked, one-sided mental models or a large number of interrelated habits that add up to an inability to accept change.

Step 6: Generate Short-Term Wins

This step is predicated upon generating and making visible unambiguous success as soon as possible. It is critical to driving short-term wins in any long-term change effort.

  • The Guiding Coalition should be tasked with identifying significant improvements within 6 to 18 months. 
  • Experience significant short-term wins by fourteen and twenty-six months after the change initiative is much more likely to complete the transformation.

Step 7: Sustain Momentum - Don’t Give Up!

Consolidating gains and producing more incremental change. This stage is vastly improved with strong leadership. Transformational leaders will strive to launch more and more projects to drive change deeper into the organization, and more importantly, become part of the organization’s culture. A lack of consistent and sufficient leadership runs the risk of stalling plans.

Kotter outlines a good checklist that appears at this stage in a lot of successful change organizations:

  • More projects are being added.
  • Additional people are being brought in to help with the changes.
  • Senior leadership is focused on giving clarity to an aligned vision and shared purpose.
  • Employees are empowered at all levels to lead projects.
  • Reduced interdependencies between areas.
  • Constant effort to keep urgency high.
  • Consistent show of proof that the new way is working.

Step 8: Institute Culture Change - Make It Stick

Kotter outlines a checklist for Culture:

  • Cultural change should come last, not first.
  • You must be able to prove that the new way is superior to the old.
  • The success must be visible and well communicated.
  • You will lose some people in the process.
  • You must reinforce new norms and values with incentives and rewards – including promotions.
  • Reinforce the culture with every new employee.

References 


Share:

The STAR Method

Written by   on   in   with No comments

The STAR interview method is a structured approach to answering behavioral-based interview questions that help employers to understand a candidate’s past behavior and how it can predict their future performance. 

Using the STAR method is important because it helps employers to:

  • Assess a candidate’s skills and qualifications: Employers can ask specific and detailed questions that will help them to assess a candidate’s skills, qualifications, and how they have applied those skills in previous roles.
  • Identify a candidate’s strengths and weaknesses: Employers understand how a candidate has handled different situations in the past, which can help them identify the candidate’s strengths and weaknesses.
  • Evaluate a candidate’s potential: Employers evaluate a candidate’s potential for success in the role and how they would perform in similar situations in the future.
  • Compare candidates: Employers can ask the same set of questions to multiple candidates, which makes it easier to compare and evaluate their responses and make a decision.
  • Make objective decisions: Employers make objective decisions by providing a structured way to evaluate candidates’ responses and assess their qualifications and experience.
  • Avoid bias: Employers avoid bias by providing a consistent way to evaluate candidates’ responses and assess their qualifications and experience, regardless of their background or demographics.
  • Provide valuable feedback to candidates: Employers can provide valuable feedback to candidates by giving them specific feedback on their answers, which can help them improve their interview skills and prepare them better for future job opportunities.

Step by Step

  • Situation. 
    • Describe the specifics or context of the situation that you want to highlight. 
    • What was it?
    • When was it?
    • Who was involved?
  • Task & Actions. 
    • Specify what actions you took to complete the tasks and achieve your results.
    • What were you asked to do?
    • What did you do?
    • How did you interact with others involved?
  • Results. 
    • Share the results that followed due to your actions and/or the general outcome of the situation. 
    • Let them know what results you could also provide to their company if they offer you the position.
    • How did the situation end?
    • What metrics can you share?
    • What feedback did you get?
    • What was the outcome?
  • Reflection (bonus).
    • What did you learn?

The SHARE Method

  • S -- Situation; describe a specific situation;
  • H -- Hindrances; identify any hindrances or challenges faced;
  • A -- Action; explain the action(s) you took in response;
  • R -- Results; discuss the results or outcomes from your action(s);
  • E -- Evaluate; explain and evaluate what you learned from the experience.

References

Share: