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.
- Expressing the backlog
- Ordering the backlog
- 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.
- Understanding – The product owner needs to have a detail understanding of WHAT needs to happen, not HOW it needs to happen.
- 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. This was surprising to me as I saw this as a role being fulfilled by the scrum master.
According to the webcast, the Product Owner can be part of the development team as well. Really? In my opinion, this will create ultimate confusion.
- Self-organising – In our scenario, our teams embraced the concept that, all are equal. Self-organising teams naturally emerged.
- 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.
- Team accountability – In my view, buy-in is crucial as well as answering the question: “What is in it for me?” Any thoughts?
- No sub-teams – We make use of outside resources. Sometimes a external resource will go into a spike and do knowledge transfer to increase the quality of the product.
Provide services to the organisation – helps people understand what is going on and pursue in direction.
- Ensure scrum process
- Serves the Product Owner (Servant-Leader)
- Serves the Dev Team (Servant-Leader)
- 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
- PO – Responsibilities, Delivery dates, Product insight, Resources, Burn Down and Evaluate. Understand the backlog and has a marketing has a role.
- SM – Process, Education and Understanding
- 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
In our case, we have maintenance that needs to be accomplished on some projects. Every Friday, is reserved for the fixing of bugs, but also for knowledge transfer. We opted for 3 week sprints. In these three week sprints, we actually burn the amount of points that would usually be burned in a regular two week sprint. Any thoughts are welcome…
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 enable the scrum master to be able to manage the change and facilitate the process without much emotional resistance.
It is true tha the scrum guide gives rules NOT strategies, we are learning daily.
A measure of scrum
- Ordered product backlog
- Team of 3 – 6
- Product owner that owns the backlog even if they do not change it
- Scrum master is responsible for the process
- Have sprints of one month or less
- Should be a fixed length
- Need a sprint backlog showing remaining work
- Review and retrospective
- Have working software at end
- Stakeholders who inspect the software increment
According to this, we have grown to a place where we are no longer, partial implementers of SCRUM.
The webcast stated that the Product Owner does not necessarily have to have access to the product backlog, because he should only be concerned with the fact that something should be delivered, without caring why. In our scenario, the Product Owner is very much the domain expert. He is in complete control of the backlog. This includes grooming and prioritising.
Although it might not be possible to deliver a releasable product at the end of the sprint, encourage team to deliver something very small.
The process is adaptable, except when it’s not – Adhere to the rules.
- Definition of done
- Product owner decisions
- Format of PBLs
- PBL oredering
- Development team processes
- Test practices
- Team members
- 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 compulsary
- User stories
- Acceptance test-driven development
- Emergent architecture
- Big visible display
- Work in Process
- Team room
- Build and test automation
Thanks to Martin Hinshelwood for a very insightful webcast.