39 Matching Annotations
  1. Last 7 days
    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.

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

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

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

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

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

  7. 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.  
  8. Apr 2019
    1. People-centric means that you will allocate specific people to focus primarily on the maintenance tasks,

      approach 1

  9. 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
  10. 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...