quinta-feira, 21 de julho de 2022

Scrum - You're doing it the right way! Or... maybe... not at all

    Once upon a time, a long time ago, in a galaxy far, far away, there was a human called John Goodsense. John was a senior Scrum Master, hired to lead an Agile Chapter within a traditional organization.

    On his very first day, John was presented to an onboarding whitepaper, which introduces new employees to Scrum Framework. John read these 3 pages and said:

— That's wonderful! You've got every single concept completely explained wrong! — I'm joking, he did not say that.

    This was the real reaction:

— Okay, that's fine. But, if you don't mind, I'd like to make some improvements.

— That would be great! — Replied the Head of Business Agility.

So Goodsense listed his points.

— First of all, I believe we should remove the word "Methodology". Methodologies are typically composed of stringent and mandatory sequences of processes and procedures that implement predefined algorithms. And this is the opposite of Scrum.

    Second, Scrum is not based on the scrum formation from Rugby. Not even the first reference to scrum formation in Product Development. The article "The new new product development game" has associated successful development teams with rugby teams since 19.860. The basis of the Scrum Framework is Lean Thinking and Empiricism.

    Third, write stories to the Backlog is one of Product Owner's minor responsibilities. The PO is essentially a value maximizer, as the title of the role says: He/She is the Owner, the one who looks after success and profit.

    Fourth, Scrum Master is not a Master of Ceremonies, not a secretary, not even a Product Owner Helper. The SM is accountable for team's effectiveness and for establishing Scrum as described in the Scrum Guide.

    Fifth, or whatever, there is no sub teams in Scrum. Developers, Product Owner and Scrum Master are one single unity of work, one single team.

    Rituals and Ceremonies, I used to attend in the Church. Scrum have Events.

    Estimates are not mandatory.

    It is not an obligation to place all tasks in the Sprint Backlog within Sprint Planning. In fact, we may not have any tasks. Sprint Backlog is a plan composed of a fixed Goal and an emerging list of items. Splitting items into tasks is optional.

    The Scrum Team commits to the Sprint Goal, not to the Sprint Backlog. The Goal must be achieved with minimum effort, no matter how many or what items have been completed.

    The 3 questions were — Thank the Goddess! — removed from the lastest version of the Scrum Guide.

    The PO validates development and provides feedback to developers on a daily basis, not just at an event.

    Review is neither a presentation nor a demonstration. It is a working session to inspect and adapt. Key stakeholders shall experience the increment, use the product, to produce empirical knowledge.

    Retrospective's action items don't need to be implemented the next Sprint. Maybe those items are medium- or long-term actions.

    Product Backlog is not an ultimate requirements list, it's an emerging ordered list of what is needed to improve the product. Mind that Scrum is Empirical, so the needs emerge from experience not imagination.

    The same applies to Sprint Backlog, it must be adapted during the Sprint.

    The Head of Business Agility surprisingly, or not, told John:

— Great! I suggest you write a new whitepaper. Wherever you want! Not here.

    And that's how John Goodsense was fired in his very first day on the job.

Scrum - You're doing it the right way! Or... maybe... not at all

     Once upon a time, a long time ago, in a galaxy far, far away, there was a human called John Goodsense. John was a senior Scrum Master, ...