Scrum Fundamentals Revisited

This is a quick and dirty Scrum Fundamentals Entry.

Scrum depends on the empirical process of inspection, transparency and adaptation. 

The basic roles that exist in scrum are listed below and briefly described. Based on the webcast present by scrum.org a few comments are worth making regarding our own process.

Product Owner

1. Expressing the backlog
2. Ordering the backlog
3. Valuing – In our scenario the product owner serves as a proxy for the business. He evaluates the business case and needs, and determines the backlog based on what is most valuable to the client.
4. Understanding – The product owner needs to have a detail understanding of WHAT needs to happen, not HOW it needs to happen.
5. Protects team from disruptions – In our case, the ‘proxy’ product owner is involved in depth with the client, as well as the team. This places him in a great position to protect the development team by managing accurate expectations based on re-negotiation of the backlog.

Development team

1. Self-organising – In our scenario, our teams embraced the concept that, all are equal. Self-organising teams naturally emerged.
2. Cross-functional teams – You need to have everybody on the team that you need to complete the definition of done. We are doing quite well with teams of two with roaming operational, architecture and technology support.
3. Team accountability – In my view, buy-in is crucial as well as answering the question: “What is in it for me?”
4. No sub-teams – We make use of outside resources. Sometimes an external resource will go into a spike and do knowledge transfer to increase the quality of the product.

Scrum master

Provide services to the organisation – helps people understand what is going on and pursue in direction.

1. Ensure scrum process
2. Serves the Product Owner (Servant-Leader)
3. Serves the Dev Team (Servant-Leader)
4. Serves the organisation

Provide knowledge and tools necessary

• It was stated that the Scrum Master can be part of the development team – This was a revelation to me. I do believe that the application of this role can possibly lead to the temptation for the Scrum Master, which according to the scrum manual, should be in a “management” position to fall into the trap of becoming a traditional project manager. As accurately stated in the webcast, this approach will divide attention. It might be a good idea for the scrum master to be involved at the production level to better be able to identify the impediments to the team. A trade-off at best. My preference…definitely not.
• The Scrum master and Product owner should not be the same person (inherit conflict), although the is no rule against this in the scrum guide.

Where do Scrum Masters come from?

• Traditional project managers
• From Dev teams

How technical do they need to be?

• Don’t have to be, but makes them better and more versatile masters.

Roles in context of traditional PM. PM is also split up into two roles

1. PO – Responsibilities, Delivery dates, Product insight, Resources, Burn Down and Evaluate. Understand the backlog and has a marketing has a role.
2. SM – Process, Education and Understanding

Scrum overview

• Product backlog -> Sprint backlog -> Remaining work @ Daily scrum -> Working software

Time cycles for sprints

• Scrum guide < 30 days
• If cycle is 30 days, teams not able to complete the work, because it tends to be a little over estimated.
• Recommend two weeks sprints – forces them to look more closely at the backlog
• Shorter is most often better – product owner should not become annoyed

Although the webcast states that you can add to the framework without invalidating the rules, we try to follow the rules to the letter. This enables the Scrum Master to be able to manage the change and facilitate the process without much emotional resistance.

It is true that the scrum guide gives rules NOT strategies, we are learning daily.

A measure of scrum

1. Ordered product backlog
2. Team of 3 – 8
3. Product owner that owns the backlog even if they do not change it
4. Scrum master is responsible for the process
5. Have sprints of one month or less
6. Should be a fixed length
7. Need a sprint backlog showing remaining work
8. Review and Retrospective
9. Have working software at the end
10. Stakeholders who inspect the software increment

Although it might not be possible to deliver a releasable product at the end of the sprint, encourage team to deliver something very small.

Challenges

The process is adaptable, except when it’s not – Adhere to the rules.

Can change:

• Definition of done
• Product owner decisions
  • Format of PBLs
  • PBL oredering
• Development team processes
• Test practices
• Team members

Caution!

• Beware of partial scrum
• Don’t undermine the PO or the Dev team
• Don’t interfere mid-sprint
• Don’t skimp on ceremonies
• Don’t plan too much detail too soon

Helpful, but not compulsory

• User stories
• Acceptance test-driven development
• Emergent architecture
• Big visible display
• Work in Process
• Co-location
• Team room
• Build and test automation

References

Thanks to Martin Hinshelwood for a very insightful webcast.