Recent Changes

Thursday, October 5

  1. page Agile User Story Slicing - An Alternative to the Vertical Slicing Metaphor for Valuable User Stories edited ... System requirements are best captured at the system boundary. As such, User Story Acceptance C…
    System requirements are best captured at the system boundary. As such, User Story Acceptance Criteria (and indeed their associated Acceptance Tests that are preferably automated) should document what happens at the system boundary, and no further.
    Some Anti-Patterns
    people who don't really knowstruggle with how to
    Sometimes, a team is very limited by the stories they can create because they are a component team, and are not able to create an end to end feature like feature teams can. In scaled Scrum implementations(several teams working on the same product/system), some organizations have remnants of waterfall still in their organizational design and team structure, such as a large organization composed almost exclusively of component teams. It's important to keep an eye out for this "too many component teams" anti-pattern -- it can be quite devastating to productivity and value delivery.
    Great Agile User Stories will hit the system boundaries at least TWICE!
    The boundaries of the system(or product, as we say in Scrum) under development are shown in the graphic above. SB1-SB4 represent the system boundaries, where we interface with our key stakeholders (humans, as well as upstream and downstream systems, who have humans that represents the interests of those systems). A good Agile User story will hit those boundaries twice. For instance, the typical "vertical slice" in a typical software application with a GUI will hit system boundaries SB3 and SB4. Sometimes, upstream data will somehow get surfaced in one of our product's GUIs -- so it will hit system boundaries SB1 and SB4. Another example might even hit all 4 boundaries! Some data could flow in from an upstream system(SB1), be presented in our product's GUI(SB4) for some sort of approval or tweaking(SB3), then approved and sent to the downstream system(SB4).
    It's important to note that in this model, the upstream system and downstream system could be the same system. Imagine your product is a back end payment system for a retail web site, and that your back end system had no real GUI. In that case, the "upstream" website would send a payment service request to your system(SB1), and then your system would do some processing on it, and send it back to the (now considered) "downstream" web site (SB2) with an approval or denial code or similar. It's again important to note that if you have "back end stories", you probably have component teams. Again, not all component teams are evil, but having too many of them in your organization is pretty damaging in terms of agility and productivity.
    upstream and to downstream systems(usually
    In Summary
    story correctly to have "value" or not.
    below for more help with
    [[include component="page" wikiName="scrumcrazy" page="User Story Links" title="Other good User Story Resources:" editable="1"]]
    [[include component="page" wikiName="scrumcrazy" page="Section SubPageFooter"]]
    (view changes)
    8:21 am

Thursday, September 28

  1. page Is SAFe(tm) Bad? Is it unsafe? Is it Agile? Are there alternatives? edited [[include component="page" wikiName="scrumcrazy" page="Section SubPageHead…
    [[include component="page" wikiName="scrumcrazy" page="Section SubPageHeader"]]
    For much better alternatives to SAFe(tm), see this page.
    All my personal/professional opinion.
    I'm not a big fan of SAFe(tm). I haven't yet had time to sit down and detail all of the problems I have with it, but I'll hit a couple.
    1. It's not Agile at all. It's a sales strategy.
    My biggest problem with it is that it condones old, out of date, and dysfunctional practices that don't enhance Agility. It is essentially a hybrid approach of Waterfall and Agile, along with
    SAFe has changed a lot of baggage from RUP. This probably shouldn't surprise anyone sinceover the creator, Dean Leffingwell, was a big salesman/evangelist for RUP. The biggest baggage from RUP is the complexity of a zillion different roles and the fact that SAFe is a "slice and dice" methodology. It's not a framework.years, so I now think differently about it. With the "slice and dice" thing is really just a slick sales strategy. It allows those selling SAFe to immediately disown any practiceelimination of SAFe that a potential client complains isn't Agile or won't work. It also means that any tiny subset of SAFe is still considered to be SAFe. As such, I just consider this a sales strategy to sell more billable hours. This strategy was also used in RUP, and yet... over the years... which has prospered more? RUP or Scrum? Scrum is a framework, so there is no slice and dicing of the framework itself.
    2. It misleads people into thinking that it uses Scrum at the team level.
    It claims to use Scrum at the team level, but then completely sells out Scrum in so many ways. It sells out the Product Owner role by giving control to all manner of people over the Product Backlog contents, something Scrum expressly forbids. It sells out the Scrum Master role by suggesting it's a 25% time commitment. Then, it completely sells out the Development Team by creating Ivory Tower architects.
    3. To date, no Agile Manifesto author has endorsed it. That should tell you something right there.
    This one is self explanatory. :-)
    The reasons I don't like it are covered in way more detail in these reviews of SAFe by other people who are sharp enough to tell the differences between SAFe and other approaches,
    hardening sprints, as well as the history behind similar practices and approaches.
    [[include component="page" wikiName="scrumcrazy" page="Reviews
    introduction of the Scaled Agile Framework" editable="1" wrap="1"]]
    "Essential SAFe", I'm much better alternatives to SAFe(tm), see this page.
    [[include component="page" wikiName="scrumcrazy" page="Section SubPageFooter"]]
    more positive about SAFe now.
    (view changes)
    10:34 pm
  2. 10:32 pm