Waterfall to Agile transition

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Teowulff wrote:

      Still, I would like to see how the agile version of the design process is going to work - and I am particularly curious as to where the community feedback comes in
      There is ACS member ( @Tyranno) in the team - my understanding is he will act on behalf of the Customer ;).

      I can't see any playtesters in the team though. Seems a true IT designer has been creating it, they always forget to add testers to the Agile Teams ;)
    • JimMorr wrote:

      Teowulff wrote:

      Still, I would like to see how the agile version of the design process is going to work - and I am particularly curious as to where the community feedback comes in
      There is ACS member ( @Tyranno) in the team - my understanding is he will act on behalf of the Customer ;).
      I can't see any playtesters in the team though. Seems a true IT designer has been creating it, they always forget to add testers to the Agile Teams ;)
      We need a new role of fluff Playtester. Currently , playtesting is only done in the Crunch half of the books.
    • Perhaps my understanding of the word fluff is wrong but for me it means the book represents the background and follows the story of the faction. That BG can check best.

      If a unit designed to be a trash mop representing massed of unwashed peasants is that or a undying deathstar PT would check.

      So BG: Are there designs meant to represent the Fluff in the book.
      PT do that designs play as intended.

      That is no official Announcements but my personal Interpretation.

      Advisery Board Member

      Click to apply to staff. I Organise: TA, TS and ACS. My Perspective on T9A on Youtube: T9A in Bayern - YouTube and T9A in Bavaria - YouTube
    • After some consideration. Maybe PT should be really out of the circle. They should get the AB for playtesting, maybe even with unit names hidden. A kind blank test. Perform a few battles, create a few army lists and give feedback on the units and their feel.

      Results might be interesting. "mop representing massed of unwashed peasants" could come back as "great MSU chaff with surprising agility"
    • Teowulff wrote:

      What I have learned from the past book redesigns is that the design teams do their thing and some time later the new book is being presented as a done thing, no discussion possible. No community involvement needed, except (indirectly) some ACS feedback.
      This will depend from book to book based on how much legal freedom we have in the initial stages or in other words how different the new needs to be compared to what users are currently used to.

      In general the further we go into the process there will space for more community involvement as we move into more generic IP books.

      Advisory Board

      Background Team

      DE LAB TT

      THE SAUCY QUILL INN
    • Teowulff wrote:

      Still, I would like to see how the agile version of the design process is going to work - and I am particularly curious as to where the community feedback comes in. What I have learned from the past book redesigns is that the design teams do their thing and some time later the new book is being presented as a done thing, no discussion possible. No community involvement needed, except (indirectly) some ACS feedback.

      In ICT projects where I work, when the project is finalized the user has to give a decharge, meaning giving a formal agreement that they agree that the suppplier has delivered what was agreed upon. In T9A such things don't exist. Users have no veto when things go terribly wrong and just have to accept what the teams have decided for them. As far as I can see there is no Senior User role. Of course, you can't have design teams consisting out of 500 people - but it wouldn't be an unheard of feature if the community can say "no" to cetrain entries. The designers then go back to the drawing table until something new is made that the community is happy with. It's not that complicated.

      Especially if you go agile you can redesign units 1 by 1 in sprints. If it's good, keep it. If it's not met with approval, it goes to the design table in some future sprint. In time, units are approved one by one and eventually all entries are approved and can go into the locked army book. Honestly I don't see any other way how to get a book with viable options that are actually taken into army lists. But of course, I may be wrong.
      There's a massive danger in "design-by-committee". In Scrum methodology the "Go/No Go" decision falls to the Product Owner (PO) who has final executive authority on the vision of the product and whether or not the Team has implemented that vision correctly. The PO can delegate some of that decision-making if they need to, but I'd really recommend against doing that as much as possible. Better for them to funnel all feedback through themselves and make a holistic decision rather than relying on stakeholder opinions that can be narrowly focused and often contradictory (both with themselves and with other stakeholders).

      Consider many of the most disruptive (and therefore successful) technologies in the marketplace. Would Steve Jobs have invented the iPhone if he surveyed phone users at the time and asked them what they wanted? Probably not, because the vast majority of people would never have thought of a smart phone before smart phones existed.

      Truly great things are created by visionary people that deliver not what the market thinks it wants, but rather deliver what the market needs but can't even imagine yet.

      That said, I think the Scrum teams would design and develop at their peril if their Sprint Reviews are not as public and transparent as possible. That's a pretty core principle of Agile development and big source of the value it provides. But allowing the community to view their progress and provide feedback is not the same thing as giving the community the ability to directly approve or reject the Team's implementation of the product vision.