26 Matching Annotations
  1. Dec 2020
    1. you should invite any stakeholders who can help either identify or solve those problems. This will almost always mean you invite more than the development team, product owner, and Scrum Master or coach. Users, project sponsors, and representatives of other teams should participate. Consider also including those in important roles who look out for consistency and integrity of the product such as architects, designers, and database engineers.

      In a more mature agile organization, this should be easier to identify sine product team will be established and devops resources should be already engaged with the team.

    1. In a system with weak parties, it is incumbent on the ideological allies of the party to explain to the rank-and-file what is true and right. Pandering

      “...true and right...” the antithesis of the last 4 years.

  2. Nov 2020
    1. And mega dosing it and having these huge amounts as we’re prone to do in the Western world, you know, supersizing it as it would be, you know, kind of the fast food attitude towards supplements is actually becoming demonstrably ineffective or at best it’s ambiguous.

      John incorrectly summarized the point here, I think. I believe “Chris” was emphasizing the fact that western science isolates components trying to identify that one thing that does the body good, when nature actually puts many components together to get the benefit, and one component by itself is not effective or even detrimental.

  3. Sep 2020
    1. This is an important point. Also contains a typo, “adequate less” should be “adequate rest”

  4. Sep 2019
    1. value streams offers substantial benefits to the organization, including faster learning, shorter time-to-market, higher quality, higher productivity, and leaner budgeting mechanisms

      Value Stream benefits:

      1. faster learning
      2. shorter time to market
      3. higher quality
      4. higher productivity
      5. leaner budgeting mechanisms
    1. Many of these traditional mindsets exist throughout the organization and, left unchanged, can sabotage a fully realized implementation.

      I would like to see a citation for this. I believe a 2010 or 2011 State of Agile report (VersionOne) said something like this, but I only heard that anecdotally.

  5. Aug 2019
    1. Traditional Supplier management and coordination, which favors win-lose contracts, and focuses on the lowest short-term cost, rather than the highest lifecycle value

      Traditional Approach practice 4, Centralized planning Traditional Approach practice 6, project based funding and control Traditional Approach practice 7, Waterfall milestones

    2. Iron-triangle strangulation (fixed scope, cost, and date projects), which limits agility and does not optimize the total economic value

      Traditional Approach practice 5, work-breakdown structures Traditional Approach practice 2, Project overload Traditional Approach practice 1, centralized control

    3. Centralizing and developing requirements with people who will not be doing the actual implementation

      Traditional Approach practice #3, detailed project plans

    4. Overly detailed business cases based on highly speculative and lagging ROI projections

      Traditional Approach practice 6, Project-based funding and control; practice 7 Waterfall milestones

    5. Project-based funding (moving people to the work) and cost accounting, which causes friction and unnecessary overhead, finger pointing, bureaucracy, and delays

      Traditional Approach practice #6, project-based funding and control

    6. Perpetual overload of demand versus capacity, which decreases throughput and belies effective strategy

      Traditional Approach practice 2, Project overload

    7. Annual planning and rigid budgeting cycles

      Traditional Approach Practice 4, Centralized planning

    1. and are ready to act on it

      This is the key statement that underlies the confusion. How do you know you are ready to act on it, i.e. build an MVP? A lot of work goes into getting to the point where you/your company is ready to act. The customer research is huge - before building anything. Refining the problem down to something simple and singular (one problem). Using data to decide when and what to add is genius.

  6. Jul 2019
    1. the ability to make quick decisions.

      Push decision making to the people who know best, the front line. Importance of the principle of decision latency, a la scrum@scale.

    2. Exhibit 1

      Note that agile methods and customer acquisition / full alignment of interests (product management? Innovation?) are multipliers / accelerators.

  7. Dec 2017
    1. This is important - it is only a coordination meeting. If the team sees themselves as separate individual contributors then it won't understand the value of coordination - but even then, build and test suite coordination is valuable.

    1. What does this mean in practice? When creating the "backlog items" for each sprint, is there no discussion of acceptance criteria? and does this mean there is little knowledge of exactly what is needed? Acceptance criteria is key to BDD/Test First mindset.

  8. Feb 2017
    1. "If you don't know what the design is how can you task out the story and accept it into the iteration"? As you can guess, this question was greeted with blank looks and stunned silence. We just do was the final answer.

      "We just do" is so antithetical to Agile - scrum.. That is so much like saying, "can't change that impediment, that's just the way it is." Read on... rough design is agreed to based on the team's accepted standards.

    1. The idea of “deferred defects” has always bothered me in software development

      I agree that deferred defects should not be a concept in Software. Why not call it what it is: "technical debt". And as the article suggests, they should be fixed. In true Agile form, if they are not important enough to fix, then they are dropped out as requirements (or dropped to the absolute bottom of the backlog, and eventually refined off the backlog as no longer relevant).

    1. The price that product owners are paying for defects during a sprint is infinitely small in return to what they are receiving — a shippable, working piece of software.

      This is the bottom line.

    2. The beauty of Agile is that we all are a single team. This philosophy is so important to uphold in an Agile environment that I cannot stress it enough. It is the team that fails and not the individuals. We start with short sprints, and at the end of each sprint, we do a retrospective, including reflections on defects. We try to find the root cause of the defect and put in some measures to eliminate it.

      Product owner is part of the team. Team succeeds or fails together. Product owners need to be in the retrospective, part of the team. Root cause analysis of defects in retrospectives, so learning how to avoid in the future.

    3. defect prevention should be better, more learning should be sought, design flaws should be studied to deepen the teams' understanding of the subject, and so on

      Full circle to the point later about retrospective considers the defects - how did they manifest, what was missed (product, UX/Software design, etc.)

  9. Jan 2017
    1. the ability of an organization to rapidly adapt and steer itself in a new direction

      This is critical for financial services, given the intensity and frequency of regulations this millenia (2002 on). Having an organization that is agile, in addition to having infrastructure that is agile. Imagine a mortgage company that can consume new regulations by reading, analyzing and implementing in operations, compliance (tracking, attestation, reporting) with relative ease - massive competitive advantage. Now imagine a mortgage company that innovates and is ahead of regulations and is ensuring that they are competitive through efficiencies and innovative products without introducing unnecessary risk to customers or to themselves through questionable practices. Possibly unstoppable?