58 Matching Annotations
  1. Nov 2022
    1. my takeaways

      • Sprint is a form of limiting WiP; Sprint Backlog is an explicit WiP limit policy

      • Limiting WiP decreases Cycle Time because wait time and task switching are minimized

      • WiP is a leading indicator of Cycle Time, and the latter can be a leading indicator for Throughput

      • self management means that Developers choose PBIs for the Sprint Backlog in collaboration with the Product Owner;

      • flow debt is borrowing work time from other items to prioritize an item in progress → it results in the increase of the age of other items in progress

    1. my takeaways

      • SLE is set by the team for the team → purpose is to inspect and adapt the workflow in the Daily Scrum and the Sprint Retrospective;
      • hence, the SLE is not a commitment or a promise, especially not to an outside stakeholder
      • "We basically learn about the increased risk to specific items the more time passes without them completing. Common sense, no? The idea is that by visualizing these items and that growing risk we can focus the team's tactical inspection and adaptation during the Daily Scrum on tackling these risky items."
    1. my takeaways from the Kanban Guide for the Scrum Teams

      • kanban = a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system
      • kanban can enhance/augment the work of the Scrum Team as described in the Scrum Guide

      • flow = the movement of value throughout the product development system

      • empiricism in Scrum in Kanban - besides being used to inspect and adapt the Product Increment - is used also to make transparent, inspect and adapt the workflow → make the workflow policies (how do we get things done) explicit (i.e. transparent) → use flow metrics in Scrum Events to inspect → adapt experimentally → run again :)

      • basic flow metrics: Work in Progress; Cycle Time; Work Item Age; Throughput (check my other notes, especially the one(s) tagged with metrics for more detail)

      • Little's Law [average Cycle Time = average WiP / average Throughput] → we can shorten the CT by decreasing the WiP limit; Throughput is mostly constant, i.e. hardest to change

      • Kanban Practices for Scrum Teams

      • visualisation of the Workflow (on the board);
      • limiting WiP (by imposing limits for all the "doing" columns, i.e. all the columns between start and finish points of the workflow) → WiP items are Product Backlog Items rather than tasks;
      • active management of work items in progress (pulling new work items at about the same time that they leave workflow; ensuring that work items pulled in don't age unnecessarily; responding quickly to items blocked or aged too much);
      • inspecting and adapting the team's Definition of Workflow (visualisation policies and how we work policies).

      Definition of Workflow = a set of explicit policies of how do we get the work done → shared understanding improves transparency and enables self-management → defined by the Scrum Team

      impact of Kanban on Scrum Events 1. Sprint - per def it's a WiP limit (definite number of PBIs get pulled into Sprint Backlog - each PBI is a work item) - opportunity for both product and process(es) inspection and adaptation - multiple releases of increment are possible 2. Sprint Planning - reviewing historical Throughput enables understanding capacity of the Scrum Team 3. Daily Scrum - focus on establishing a consistent flow, by holding the meeting around the kanban board; - check on the blocked items and how to unblock them; slow items and items violating their SLE; consider factors which can impact the work and are not represented on the board; have ve learned anything new that might change what Scrum Team has planned to work next; is Wip limit being respected 4. Sprint Review - reviewing Throughput enables Product Owner to discuss likely delivery dates; 5. Sprint Retrospective - metrics enable discussion on improvement of processes; - inspection and adaptation of Definition of Workflow for the next Sprint - regular cadence of flow optimization reduces complexity and improves focus, commitment and transparency.

      Increment is impacted by the fact that short feedback loops for processes make it possible the Scrum Team to identify bottlenecks, constraints and impediments to enable this faster, more continuous delivery of value.

    2. my highlights from the Kanban Guide for Scrum Teams

      how it was made

      I've read the Kanban Guide for Scrum Teams on my tablet using the Moon+ Reader Pro. While reading, I've highlighted parts of text that I've found important. Then I've exported those highlights as a text document and pasted it into a Hypothesis page note here. So, here you'll basically find the quotes from the Guide without any comments. I strongly suggest reading the whole guide and annotating it yourself.

      higlights

      01-2021 Kanban Guide.pdf (Highlight: 66; Note: 0)

      ───────────────

      ▪ This guide does not replace or discount any part of The Scrum Guide. It is designed to enhance and expand the practices of Scrum.

      ▪ Kanban (n): a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system.

      ▪ Flow is the movement of value throughout the product development system

      ▪ frequency of the transparency, inspection, and adaptation cycle - which we can also describe as the Cycle Time through the feedback loop.

      ▪ they provide a focus on improving the flow through the feedback loop

      ▪ Work in Progress (WIP)

      ▪ work items started but not finished

      ▪ Cycle Time: The amount of elapsed time between when a work item starts and when a work item finishes

      ▪ Work Item Age: The amount of time between when a work item started and the current time. This applies only to items that are still in progress.

      ▪ Throughput: The number of work items finished per unit of time.

      ▪ Little’s Law,

      ▪ Little’s Law reveals that in general, for a given process with a given throughput, the more things that you work on at any given time (on average), the longer it is going to take to finish those things (on average).

      ▪ Most of the other elements of Kanban are built upon the relationship between WIP and Cycle Time

      ▪ flow theory relies on empiricism by using flow metrics and data to gain transparency into historical flow and then using that data to inform flow inspection and adaptation experiments.

      ▪ Scrum Teams can achieve flow optimization by using the following four practices: · Visualization of the Workflow · Limiting Work in Progress (WIP) · Active management of work items in progress · Inspecting and adapting the team’s Definition of Workflow

      ▪ Kanban practices are enabled by the Scrum Team’s Definition of Workflow

      ▪ Scrum Team members’ explicit understanding of what their policies are for following the Kanban practices

      ▪ shared understanding improves transparency and enables self-management

      ▪ the scope of the Definition of Workflow may span beyond the Sprint and the Sprint Backlog

      ▪ Creating and adapting the Definition of Workflow is the accountability of the relevant roles on the Scrum Team as described in the Scrum Guide. No one outside of the Scrum Team should tell the Scrum Team how to define their Workflow.

      ▪ Visualization using the Kanban board is the way the Scrum Team makes its Workflow transparent.

      ▪ Defined points at which the Scrum Team considers work to have started and to have finished.

      ▪ A definition of the work items - the individual units of value

      ▪ flowing through the Scrum Team's system (most likely Product Backlog items (PBIs))

      ▪ definition of the workflow states that the work items flow through from start to finish

      ▪ Explicit policies about how work flows through each state (which may include items from a Scrum Team's Definition of Done and pull policies between stages).

      ▪ Policies for limiting Work in Progress (WIP).

      ▪ work items the Scrum Team has started but has not yet finished

      ▪ Scrum Teams using Kanban must explicitly limit the number of these work items in progress.

      ▪ an explicitly limit WIP however they see fit but should stick to that limit once established.

      ▪ primary effect of limiting WIP is that it creates a pull system.

      ▪ the team starts work (i.e. pulls) on an item only when it is clear that it has the capacity to do so.

      ▪ WIP drops below the defined limit, that is the signal to start new work

      ▪ different from a push system, which demands that work starts on an item whenever it is requested.

      ▪ Making sure that work items are only pulled into the Workflow at about the same rate that they leave the Workflow.

      ▪ Ensuring work items aren't left to age unnecessarily.

      ▪ Responding quickly to blocked or queued work items as well those that are exceeding the team’s expected Cycle Time levels

      ▪ service level expectation (SLE) forecasts how long it should take a given item to flow from start to finish within the Scrum Team’s Workflow

      ▪ uses its SLE to find active flow issues and to inspect and adapt in cases of falling below those expectations.

      ▪ SLE itself has two parts: a range of elapsed days and a probability associated with that period (e.g., 85% of work items should be finished in eight days or less)

      ▪ based on the Scrum Team's historical Cycle Time

      ▪ the Scrum Team should make it transparent

      ▪ If no historical Cycle Time data exists, the Scrum Team should make its best guess and then inspect and adapt once there is enough historical data to do a proper SLE calculation.

      ▪ The Scrum Team uses the existing Scrum events to inspect and adapt its Definition of Workflow

      ▪ aspects of the Definition of Workflow the Scrum Team might adopt

      ▪ Visualization policies

      ▪ How-we-work policies -

      ▪ Kanban in a Scrum context does not require any additional events to those outlined in The Scrum Guide.

      ▪ Sprint and its events provide opportunities for inspection and adaptation of both product and process.

      ▪ misconception that teams can only deliver value once per Sprint. In fact, they must deliver value at least once per Sprint.

      ▪ Scrum Teams rely on the Sprint Goal and close collaboration within the Scrum Team to optimize the value delivered in the Sprint

      ▪ flow-based Sprint Planning meeting uses flow metrics as an aid for developing the Sprint Backlog. Reviewing historical throughput can help a Scrum Team understand their capacity for the next Sprint

      ▪ flow-based Daily Scrum focuses the Developers on doing everything they can to maintain consistent flow. While the goal of the Daily Scrum remains the same as outlined in The Scrum Guide, the meeting itself takes place around the Kanban board and focuses on where flow is lacking and on what actions the Developers can take to get it back.

      ▪ What work items are blocked and what can be done to get them unblocked?

      ▪ What work is flowing slower than expected? What is the Work Item Age of each item in progress? What work items have violated or are about to violate their SLE and what can the Scrum Team do to get that work completed?

      ▪ Are there any factors not represented on the board that may impact our ability to complete work today?

      ▪ Have we learned anything new that might change what the Scrum Team has planned to work on next?

      ▪ Have we broken our WIP limit? And what can we do to ensure we can complete the work in progress?

      ▪ Inspecting Kanban flow metrics as part of the review can create opportunities for new conversations about monitoring progress towards the Product Goal.

      ▪ Reviewing Throughput can provide additional information when the Product Owner discusses likely delivery dates.

      ▪ A flow-based Sprint Retrospective adds the inspection of flow metrics and analytics to help determine what improvements the Scrum Team can make to its processes

      ▪ Scrum Team using Kanban also inspects and adapts the Definition of Workflow to optimize the flow in the next Sprint.

      ▪ Scrum Team should consider taking advantage of process inspection and adaptation opportunities as they emerge throughout the Sprint.

      ▪ changes made during the regular cadence provided by the Sprint Retrospective event will reduce complexity and improve focus, commitment and transparency.

      ▪ Kanban helps manage the flow of these feedback loops more explicitly and allows the Scrum Team to identify bottlenecks, constraints, and impediments to enable this faster, more continuous delivery of value

      ▪ The flow optimization practices of Kanban provide Scrum Teams with additional opportunities to inspect the right thing, at the right time, and then based on that inspection, adapt as needed. Kanban's hyperfocus on transparency, visualization, and flow maximizes feedback, empiricism, and ultimately the delivery of value.

    1. my takeaways

      • leading indicators (Work Item Age) are relevant for non-finished work, while lagging indicators (Cycle Time, Throughput) are relevant for finished Items

      • kanban metrics are of use in the Scrum Events

      • in Sprint Planning the key metric is Throughput, complemented with Work Item Aging for planning on work regarding leftover work from previous sprints.
      • in the Daily Scrum Devs concern themselves with the WiP and Work Item Aging.
      • Sprint Review revolves around Throughput, complemented by WIP and Cycle Time.
      • in Sprint Retrospective we focus on Cycle Time, Throughput & WIP, while taking a look also at Work Item Aging.

      Work in Progress

      = a number of work items started but not finished - start and finish are defined by Scrum Team's Definition of Workflow - an explicit policy that serves as a constraint to help shaping of the flow of work - historically visualized through the Cumulative Flow Diagram

      Cycle Time

      = time elapsed between when a work item starts and when it finishes - start is when the work item is pulled into the workflow - CT is a lagging indicator visualised in a Cycle Time Scatterplot from which we can read trends, distributions, and look at the anomalies - enables us to come to the *Service Level Expectation (=amount of time that we expect a work item to be finished in)

      Throughput

      = number of work items finished per unit of time - exact count of items, regardless of their size - measured usually at the finish line of the workflow - visualized either at a separate run chart, or as the angle of curves on a Cumulative Flow Diagram - can be read out of the Cycle Time Scatterplot as well → !is not velocity!

      Work Item Age

      = time elapsed between moment when the work item has been pulled into the workflow (=start) and the current time - complemented with Cycle Time it can show us which items are doing well and which are late - Work Item Age is the best metric to look at if you want to determine when an item that has already started is going to finish

    1. my takeaways

      kanban is a pull system = the team pulls the items into its workflow, instead of having them pushed by the management or any other instance.

      kanban core practices

      1. visualize the work, workflow, and risks to flow/value delivery;
      2. limit WiP;
      3. manage flow;
      4. make process(es) & policies explicit;
      5. implement feedback loops; improve collaboratively, evolve experimentaly.

      visualisation

      • regards both work going into and out of Sprint;
      • we visualise the flow of PBIs rather than the tasks;

      WiP limitation

      • regards PBIs being developed at the time;
      • Sprint is a WiP limit (i.e. Developers *pull PBIs into Sprint Backlog);
      • Kanban boards for Scrum Teams limit WiP per different stages of development process rather than having just one summary WiP limit for all categories of "doing";
      • Wip limits should be low enough to introduce pain → that pushes the Team beyond comfort zone which forces teamwork and drives deep collaboration;

      flow management

      • monitor aging/stallenes of work items;
      • focus on the healthy flow of work;
      • to increase the flow teams should look to release as soon as the work is ready;

      explicit precess(es)

      • enables empowerment through increased transparency;
      • enables inspection on "why do we do things this way?" or "how will a change affect the flow or the results?";
      • most explicit policies in Scrum are the Definition of Done and the Scrum itself. another policy is the visualisation of work (columns on the kanban board), visualization of blockers, work prioritization etc.

      feedback loops

      • data-driven Sprint Retrospective

      collaborative improvement, experimental evolution

      • models and scientific method can guide empirical evolution of the Scrum Team;
      • planning of the aims/goals and methods of their validation;
      • constant review (in the Retros) of the results and decide whether further experimentation is needed, or the chane can be deployed as a standard operating policy
    1. Al estar matriculado en el curso, estás suscrito por defecto a los mensajes de estos foros, lo que quiere decir que recibirás por correo las notificaciones de los temas que se vayan abriendo.  Si no fuera así, por favor revisa la configuración del filtro de correo no deseado, por si los estuviera bloqueando.
      • ver
    2. OPERATIVA El objetivo del curso es conocer y comprender los contenidos que están disponibles tanto en las lecciones del área "Lecciones" y  en el libro del curso, que se encuentra disponible en la sección "Documentación". El libro del curso resulta útil para su consulta off-line, pero es recomendable hacer el seguimiento de las lecciones.Las lecciones en línea incluyen preguntas para reforzar el aprendizaje y comprobar su comprensión. Para acceder a una lección es necesario haber completado la anterior. El formato e-learning permite dedicar el tiempo y momento del día más apropiado para cada uno; y para que resulte compatible con casi cualquier actividad, el calendario se ha estimado con bastante holgura, suponiendo una dedicación de tiempo medio inferior a una hora diaria. Por supuesto se puede realizar en menos días, con un ritmo más rápido. Cualquier consulta o tema de discusión lo puedes plantear en el foro en el área de comunicación. Para acreditar el aprendizaje de los contenidos de este curso y registrar los correspondientes Puntos de Autoridad Académica de Scrum Manager (150PDAs) se puede realiza el examen que estará disponible los tres últimos días.

      -OK

  2. Oct 2022
    1. For that, you must create a culture of fear in which it’s more important to show others you’ve been productive than to help the team achieve its goals.
    2. Once you have convinced your team to estimate tasks, you can pressure people to work longer hours to prove they’re not bad at estimations.
    1. Sometimes a Scrum Team is hired and assembled fully by an organization without any input from the Scrum Team members, and there's nothing in Scrum preventing that. Likewise, there is nothing in Scrum that prevents a group of people from forming their own Scrum Team and organizing themselves into a structure that gives them their best shot at achieving the organization's goals.

      the Scrum Team may be both assembled or self-assembled

    2. In Scrum, the Product Owner manages the Product Backlog, Scrum Masters manage Scrum's effectiveness, and Developers manage how Increments are created.

      this is important, who is accountable for the management of what

    1. who

      is it really about who (customer/user) we're working for? or can we say that it's about what (goal/value/outcome /impact) we're working for?

  3. Aug 2022
  4. Jun 2022
    1. ساده سراغ اسکرام نمی ریم میریم سراغ کانبان،

  5. Feb 2022
    1. STLC - Software Testing Life Cycle

      Software Testing Life Cycle (STLC) is defined as a set of activities performed to perform software testing. The Software Testing Life Cycle refers to a testing process with specific steps that must be performed in a specific order to ensure that quality objectives are met.

    1. The waterfall methodology for software development is rapidly losing popularity, while the Agile methodology is increasingly used for software development by companies around the world.

      Important differences between Agile and Waterfall methodology

      The waterfall methodology for software development is rapidly losing popularity, while the Agile methodology is increasingly used for software development by companies around the world.

  6. Nov 2021
    1. Is Agile/SCRUM Modern Slavery? https://en.itpedia.nl/2021/11/30/is-agile-scrum-moderne-slavernij/ What do you say Modern Slavery? Yes, when I first read the Agile Manifesto, I felt an unease. Especially when I also read the 12 accompanying principles. I realize that I am making extreme statements in this article, but they are intended as a mirror and to reflect for ourselves what we are actually doing.

  7. Oct 2021
    1. The problem with the first approach is that it considers software development to be a deterministic process when, in fact, it’s stochastic. In other words, you can’t accurately determine how long it will take to write a particular piece of code unless you have already written it.

      Estimation around software development is a stochastic process

    1. “concretizzazione” dei principi dell’Agile nelle due metodologie più diffuse, ovvero Scrum e Kanban, esplorandone le principali differenze.

      Cosa sono le metodologie Scrum e Kanban?

      Si tratta di due metodologie che rendono concreti i principi alla base dell'Agile.

  8. Sep 2021
    1. All too often a Sprint Review is nothing more than a team saying they did a bunch of stuff with no actual feedback happening. The same can be said of Retrospectives, where the team produces many stickies, but no change manifests. The Daily Scrum Is a daily feedback mechanism, but all too often reduced to merely a task status update.

      Seems to be a pretty common pattern ... :/ I observe it, too, all day. And I wonder how to change that. Every time we decide to talk about obstacles and challenges instead of just give a status update in the daily we don't do it at the end. In reviews we hardly get any feedback. This is not just not agile but de-motivating as well. And then I realize, that we are not in a lifecycle state where Agile is the right framework for us ...

  9. Apr 2021
    1. how the Scrum Master should support the team being self-managed, and the relationship with the Sprint Goal.

      In a nutshell, Scrum requires a Scrum Master to foster an environment where:

      A Product Owner orders the work for a complex problem into a Product Backlog. The Scrum Team turns a selection of the work into an Increment of value during a Sprint. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint. Repeat

    1. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework. Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

      This is the section in the Scrum Guide that defines the Scrum Master as Leader first. Servant later (below.) The explicit mentioning of accountable and true leaders emphasises the new focus on leadership in a Scrum Master.

      Does this support the ongoing discussion between Scrum Masters and Line Managers?

      Who’s responsible for coding standards? Who is holding the team accountable when they do not adhere to the DOD? What about quality standards? The role of the QA lead? Yes to all who answer: The Team. They are collectively accountable. What if team dysfunction that a SM can’t solve on his own disrupt performance and quality? He has got no disciplinary status/power, and should not, in order to not restrict his coaching attitude?

      There is an article on scrum.org that states that servant leadership is still useful.

      Further consider the self-managing / self-governing ideas https://www.scrum.org/resources/blog/scrum-team-self-managing This article enables each organisation to create shared understanding on how much power lies within the team.

      Since the Scrum master is accountable for the effectiveness of Scrum, he must facilitate shared understanding and agreement within the team and within the teams organisation.

    2. the Scrum Team must create a Definition of Done

      It’s a mutual effort of the whole Scrum Team to create the DOD. Stephanie describes that well in her article: https://www.scrum.org/resources/blog/2020-scrum-guide-definition-done-created-scrum-team

    3. were (or were not) solved

      This emphasises that problems are to be solved not only during or after a decision in a retrospective, but during a sprint. However, achieving the Sprint Goal and meeting the DOD for each sprint backlog item still has priority over improvement work. Ach

    1. Self-Managing over Self-Organizing

      https://www.scrum.org/resources/blog/scrum-guide-2020-update-self-mgt-replaces-self-organization

      Consider reading this article from Steven Denning and see how different states of a team contribute to performance. Self-managing is topped by Self-Organising, where teams organise their own context, including team members (self-selection).

      And:

      Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.

      https://www.scrum.org/resources/blog/scrum-team-self-managing

    2. three different sets of accountabilities: PO, SM, and Developers.
    3. Definition of Done

      A great article on how the DOD applies now to the Scrum Guide and the Scrum Team. The emphasis that the entire Scrum Team creates the DOD prevents from misunderstandings in the future, as I’ve personally witnessed in the past.

      https://www.scrum.org/resources/blog/2020-scrum-guide-definition-done-created-scrum-team

    4. Introduction of Product Goal

      How do Product Goal and Release Goal relate? Is the Product Goal the product vision and Release Goal is helping us to define relevant Sprint Goals to achieve the Release Goal?

      Good reads about the Product Goal: https://www.scrum.org/resources/blog/scrum-guide-2020-update-introducing-product-goal

      https://www.scrum.org/resources/blog/product-goal

    5. 2020 Scrum Guides

      Several articles on Scrum.org describe and discuss the 2020 changes: https://www.scrum.org/scrum-guide-2020

    6. removing any remaining inference to IT work (e.g. testing, system, design, requirement

      Things that have been removed:

      • The prescriptive elements of the Sprint Review.
      • The detailed outcomes defined in the purpose of the Sprint Retrospective.
      • The improvements that will be implemented in the next Sprint from the Retrospective.
      • Refinement usually consumes no more than 10% of the capacity of the team.
      • How to monitor progress towards the goal in Product Backlog.
      • The use of an organization’s “Definition of Done”.
      • The three questions for the Daily Scrum.
      • Meeting after the Daily Scrum for detailed discussions, replanning, etc

      Source: https://www.scrum.org/resources/blog/scrum-guide-2020-update-what-has-been-removed

    7. Sprint Goal.

      The importance of the Sprint Goal escalated again. This crucial bit of discussion during Sprint Planning empowers the team to make Yes/No decisions on work pulled into a sprint, not only during planning, but also during the sprint itself. It focuses the product owner and development team on delivering something valuable to be shown in the Sprint Review. (Start with the end in mind.)

    1. “The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.” While there are still explicit accountabilities for the Product Owner, Scrum Master, and Developers, all three roles must work together effectively in order to be successful with Scrum.

      While the SM worked closely with the Dev team to support them creating the DOD, with this new emphasis on entire Scrum Team the potentially odd moments of ownership and contribution from the SM/PO to the DOD are less likely to happen.

    2. everyone on the Scrum Team should care about and contribute to quality.

      This is where the new Scrum Guide 2020 generates some leverage for Coached and the Testing Engineers (as part of DEV). Testing/Quality is everyone’s job on the Scrum Team. Including all DEV, PO and SM.

    1. Refinement usually consumes no more than 10% of the capacity of the team. 

      It used to give me a good reason to point to the Scrum Guide when the team was annoyed by the number of refinement hours during a sprint.

      With more experience, it becomes clear that the number of refinement hours spent should not depend on the Scrum Guide but on the readiness of work. A better measure, and this differs from team to team, is how many stories shall be ready at all times? One to three sprints worth of ready work? At least enough work should be ready before Sprint Planning, so that the actual sprint delivers done work (and not more refinement work, only.)

      Refinement hours spent also depend on how predictable the work is on the Product Owner’s roadmap and if there is a need to do first iterations of refinement on future releases, months away to have a very high level estimate of effort.

      Opinions?

    1. more emphasis on leadership

      Where and how does it place more emphasis on leadership? (need to explore!)

      Leading what? Quality goals? Coding standards? Dysfunctional behaviour? → Role of the manager working with a scrum team, within a scrum team, managing people that are part of a scrum team.

    1. Bring up the board that shows the status of every item the team is working on.Starting in the right-most column, get an update for each ticket in the column.Be sure to ask: “What’s needed to move this ticket to the next stage of progress?”Highlight blockers that people bring up and define what’s needed to unblock work.Move to the next column to the left and get updates for each ticket in that column.Continue until you get to the left-most column.

      Format of "walk the board" daily standup

    2. More people brings more status updates.More updates mean more information that others won’t care about.The team may be working on multiple projects at once.If the team has customers, ad-hoc work will regularly come up.

      Problems of dailies when more people show up

    3. I start thinking about my update to prove I should keep my jobPeople zone out when a teammate starts talking about how they worked on something that doesn’t affect me.It’s finally my turn to give an update. No one is listening except for the facilitator.We go over our time and end when the next team starts lurking outside the room.

      That's how a typical daily usually looks like

    4. What did I complete yesterday that contributed to the team?What do I plan to complete today to contribute to the team?What impediments do I see that prevent me or the team from achieving its goals?

      3 questions to be answered during a daily meeting

  10. Dec 2020
    1. As we advocate in our Agile Product Management overview, the more involved that a product manager is with the development team, the better. That involvement should be along the lines of a product owner who champions customer needs, the "why" of the product. When the involvement blurs into tasking, the "how" for a team, then there is a problem. Even with the best of intentions, this kind of utilization mindset tends to hide problems: defects, hand-offs, and unknowns. Interleaving scope and process tends toward locking scope, schedule, and quality. That's a recipe for failure.
      • The [[Product Manager answers the why]]
      • The [[Scrum Master answers the how]]
    2. When starting out with scrum, it can be a huge help to have someone in the role who has seen scrum working before. Better yet, has seen many examples of it working. For this reason, scrum masters are often hired as consultants, rather than as full-time employees.

      some companies are not able to afford a full time scrum master, but having someone that knows the process well and can provide agile coaching can be important to adopting scrum properly.

    3. As facilitators, scrum masters act as coaches to the rest of the team. “Servant leaders” as the Scrum Guide puts it. Good scrum masters are committed to the scrum foundation and values, but remain flexible and open to opportunities for the team to improve their workflow.

      [[scrum masters are facilitators and coaches]], they understand

      • [[scrum fundamentals]]
      • [[scrum values]]

      While [[agile is a mindset]], [[scrum is a framework for getting things done]]

    4. Scrum has a clearly defined set of roles and rituals that should be followed
      • What are the [[scrum roles]]
      • What are the [[scrum rituals]]
    5. Summary: The scrum master helps to facilitate scrum to the larger team by ensuring the scrum framework is followed. He/she is committed to the scrum values and practices, but should also remain flexible and open to opportunities for the team to improve their workflow.

      the scrum master is someone that facilitates the team, and helps ensure that the scrum framework is followed, and values adhered to.

  11. Nov 2020
    1. Scrum-Based Learning Environment: Fostering Self-Regulated Learning.

      Linden, T. (2018). Scrum-Based Learning Environment: Fostering Self-Regulated Learning. Journal of Information Systems Education, 29(2), 65–74.

    1. An Agile Framework for Teaching with Scrum in the IT Project Management Classroom

      Rush, D. E., & Connolly, A. J. (2020). An Agile Framework for Teaching with Scrum in the IT Project Management Classroom. Journal of Information Systems Education, 3, 196.

  12. Apr 2020
    1. Spikes Spikes are a type of exploration Enabler Story in SAFe. Defined initially in Extreme Programming (XP), they represent activities such as research, design, investigation, exploration, and prototyping. Their purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate. Like other stories, spikes are estimated and then demonstrated at the end of the Iteration. They also provide an agreed upon protocol and workflow that Agile Release Trains (ARTs) use to help determine the viability of Epics. Details Agile and Lean value facts over speculation. When faced with a question, risk, or uncertainty, Agile Teams conduct small experiments before moving to implementation, rather than speculate about the outcome or jump to a Solution. Teams may use spikes in a variety of situations: Estimate new Features and Capabilities to analyze the implied behavior, providing insight about the approach for splitting them into smaller, quantifiable pieces Perform feasibility analysis and other activities that help determine the viability of epics Conduct basic research to familiarize them with a new technology or domain Gain confidence in a technical or functional approach, reducing risk and uncertainty Spikes involve creating a small program, research activity, or test that demonstrates some aspect of new functionality. Technical and Functional Spikes Spikes primarily come in two forms: technical and functional. Functional spikes – They are used to analyze overall solution behavior and determine: How to break it down How to organize the work Where risk and complexity exist How to use insights to influence implementation decisions Technical spikes – They are used to research various approaches in the solution domain. For example: Determine a build-versus-buy decision Evaluate the potential performance or load impact of a new user story Evaluate specific technical implementation approaches Develop confidence about the desired solution path Some features and user stories may require both types of spikes. Here’s an example: “As a consumer, I want to see my daily energy use in a histogram so that I can quickly understand my past, current, and projected energy consumption.” In this case, a team might create both types of spikes: A technical spike to research how long it takes to update a customer display to current usage, determining communication requirements, bandwidth, and whether to push or pull the data A functional spike – Prototype a histogram in the web portal and get some user feedback on presentation size, style, and charting Guidelines for Spikes Since spikes do not directly deliver user value, use them sparingly. The following guidelines apply. Quantifiable, Demonstrable, and Acceptable Like other stories, spikes are put in the Team Backlog, estimated, and sized to fit in an iteration. Spike results are different from a story because spikes typically produce information rather than working code. They should develop only the necessary data to identify and size the stories that drive it confidently. The output of a spike is demonstrable, both to the team and to any other stakeholders, which brings visibility to the research and architectural efforts, and also helps build collective ownership and shared responsibility for decision-making. The Product Owner accepts spikes that have been demoed and meet its acceptance criteria. Timing of Spikes Since they represent uncertainty in one or more potential stories, planning for both the spike and the resulting stories in the same iteration is sometimes risky. However, if it’s small and straightforward, and a quick solution is likely to be found, then it can be quite efficient to do both in the same iteration. The Exception, Not the Rule Every user story has uncertainty and risk; that’s the nature of Agile development. The team discovers the right solution through discussion, collaboration, experimentation, and negotiation. Thus, in one sense, every user story contains spike-like activities to identify the technical and functional risks. The goal of an Agile team is to learn how to address uncertainty in each iteration. Spikes are critical when high uncertainty exist, or there are many unknowns.  
  13. Apr 2019
    1. People-centric means that you will allocate specific people to focus primarily on the maintenance tasks,

      approach 1

  14. Nov 2017
    1. important ScrumMaster characteristics.

      One must be (among others):

      • Knowledgeable
      • Questioning
      • Patient
      • Collaborative
      • Protective
      • Transparent
    2. the principal ScrumMaster responsibilities.

      These include:

      • Coach
      • Servant Leader
      • Process Authority
      • Interference Shield
      • Impediment Remover
      • Change Agent
  15. May 2017
    1. Every time a customer service assistant shrugs and says “computer says no” or an organization acts in crazy, inflexible ways, odds-are there’s a database underneath which has a limited, rigid view of reality and it’s simply too expensive to fix the software to make the organization more intelligent. We live in these boxes, as pervasive as oxygen, and as inflexible as punched cards.

      Isn't it interesting how the rigidity of institutionalised "old economy"-businesses and their management structure as well as their work ethics is, in a way, mimicked by their IT-architecture? Efficiency over effectiveness, stability over flexibility, repetition over creative destruction and innovation. And then came Agile...