J I McFadyen Engineering

Supporting Collaboration

Exploring Scrum: the Fundamentals

Book cover of Exploring Scrum: the Fundamentals by Dan Rawsthorne and Doug Shimp

Exploring Scrum: the Fundamentals by Dan Rawsthorne and Doug Shimp

So far it has an interesting take on implementing Scrum in organisations. Not necessarily one I’d present to my own clients, though I don’t doubt it has worked for the authors.

I haven’t finished reading it yet, mainly due to time-constraints and other reading I had to prioritize, but will carry on soon.

Snippets

Scrum is a simple development framework allowing a single, co-located, cross-functional, self-organizing Team to build high-quality software in an incremental, agile manner

three parts to a software development process: the People, the Product, and the Practices.

People use Practices to develop Product

Lean principles tell us that Product should be developed by thinking from a user’s point

the simple Practices contained in the Scrum framework are merely ‘training wheels’;

Self-organization and the ScrumMaster role;

Strict accountability and the Product Owner role;

Respect for the Product;

Agility in all things.

I may be looking at a Team that is trying to become a Scrum Team.

Scrum’s ‘out of the box’ process is just good enough to allow for successful development

Many highly mature Scrum Teams follow a process that doesn’t resemble ‘by the book’ Scrum very much

Arguably, the most important role involved in Scrum is the Stakeholder,

the most important person on the Scrum Team is the Product Owner (PO).

The Backlog contains Items at all levels of fidelity, from vague wishes, wants, or needs to finely detailed requirements.

It is important to note that the Team has committed to the Goal, but merely agreed to the Items;

A Scrum Team’s mission is simple: to produce valuable Work Results,

people with skills, not people playing roles.

the Team figures out how to do its work, manages itself as it does the work, and has all the skills it needs to get the work done.

teams are more effective and efficient at solving difficult problems than individuals are,

the Product Owner is defined by his or her accountability, not skill set.

the ScrumMaster is accountable for making sure that Scrum is used correctly, that the Team uses Scrum in a positive way, and that the Team is constantly improving its use of Scrum.

the Project Manager cannot be the ScrumMaster… unless the role of Project Manager is redefined to explicitly exclude accountability for Work Results.

On a Scrum Team the project management responsibilities are carried out by the Team itself,

Scrum is successful largely because it is based on values.

focus should be on fixing the environment – not on fixing the people – when trying to change behavior.

Often, when an Organization is new to Scrum, the Organization’s values will be in conflict with the Team Values

the ScrumMaster should help the Team resolve its differences with the Organization.

the Team determines how it’s going to do its work within the constraints the Business has given it.

the Team is self-organized and self-managed, but not self-directed – it figures out the ‘how’ and ‘who,’ but not the ‘what’ or the ‘why’

the Product Owner is a single Team Member; this accountability is not something that can be shared.

The Product Owner is the Team Member who has final say over what the Scrum Team does.

as far as I know, Scrum is the only management framework (outside the military) that explicitly separates them – which it enforces by having the two roles of Product Owner and ScrumMaster to provide the necessary balance.

the Product Owner needs to have a lot of information in order to be effective,

a ScrumMaster has no actual management authority over the people on the Scrum Team.

the ScrumMaster often needs to take the cultures of the Team and the Organization into account.

the Team owns the problem, so the Team owns the solution

This tension between ‘whats’ and ‘hows’ is often a topic of near-continuous discussions between the Team and the Organization.

it is the ScrumMaster’s responsibility to make sure they get removed.

Scrum exposes issues that need to be corrected whether or not the Organization uses Scrum.

do not use the term to refer to the Team Members themselves, even though they are clearly stakeholders.

follow the accountability…

Team Swarm encapsulates the Lean Concept of Single Item Flow

Scrum generally considers quality to be more important than quantity,

define an Epic as an Item that can’t be agreed to by the Team.

an Epic contains things that are inherited by all the internal Stories.

Time-boxing is a very powerful technique for managing scope creep,

the Agreement may change the Size.

the Team should always feel free to strengthen the standard Doneness Definition

Related posts:

  1. The importance of ownership Product owners have one of the hardest jobs in an agile team; they have to decide on what needs to...
  2. Agreeable conversations When does whole-team collaboration become an impediment and not a desirable quality of the team? For me it has been...
  3. 3 months in In October, as a freshly minted CSM, I started at a new client as a developer on a project claiming...
  4. ScrumMaster Is Not Part of the Team | 10 Reasons I have just read ScrumMaster Is Not Part of the Team | 10 Reasons from Boris Gloger, and though I agree...
Category: book snippet