19 Matching Annotations
  1. Nov 2018
    1. Phase-gate approval processes that don’t mitigate risk and discourage incremental delivery

      3, #6, #7

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

      5, #2, #1

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

      3

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

      6?

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

      4?

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

      6

    7. Measures of progress that focus on document-driven deliverables and task completion, versus objective measures of value

      7

    8. Annual planning and rigid budgeting cycles

      4

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

      2

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

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

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