A number of porcupines huddled together for warmth on a cold day in winter; but, as they began to prick one another with their quills, they were obliged to disperse. However the cold drove them together again, when just the same thing happened. At last, after many turns of huddling and dispersing, they discovered that they would be best off by remaining at a little distance from one another
Arthur Schopenhauer
Starting to implement Agile SCRUM is good fun. Depending on the team, you can implement almost everything from the start and succeed or you can slowly introduce changes one by one and fail.
The way the team absorbs and applied new habits and constraints is really important and you can play as Scrum Master a key contribution building up the confidence and trust within the team. There is not a common rule and sometime it is a matter of luck but I found it easier implement Agile SCRUM to a well established team where people know each other for quite a long time than with a brand new team.
As we know, another important factor is the clear definition of team roles. Try to maintain one person as Product Owner as the SCRUM rules dictates and avoid confusion of roles between project manager and scrum master or stakeholders and Product Owner.
For my future reference and if you found yourself working as SCRUM Master in the same situation with a “open mind team” and with the business side backing you, here is the list of actions required to introduce the Agile SCRUM framework.
You can apply them gradually depending on the time schedule and the difficult to change the daily habits but you have to apply them all if you want get back the benefits out of the SCRUM process that I can summarize as follow: good communication within and outside the team, good visibility of the progresses, what is going on, release plan.
It’s not simple and there could be pitfalls or problems depending on how the team members and the stakeholders are open to change. The team motivation is a key factor and you have to play your part trying to explain and build up the process.
If you just wait for the team to “democratically” adopt these rules it will not happen or the rules will be adopted in a way that is not the right way. If you expect developers to keep the whiteboard in sync with the issue tracker software or to do the pair review before completing tasks or to split requirements in small stories… well, good luck with that. This is why when you play as SCRUM Master you can leave to them all the implementation details but you have to apply and own the process, the set of rules and control that they are followed by the team. Stop being a SCRUM Nun and start behaving as a SCRUM Master 🙂
The Scrum Team is formed by one Product Owner (PO), Developers (Devs) and optionally Qa testers. In absence of specialized QA resources, Devs can test and verify the code and the PO can help with tests.
Short sprint of two weeks
This allows the team to be more flexible on sprint goals. The PO can have a better control about the capacity of the team and ensure it is in line with the planned release. There is no necessary correlation between Sprint length and Release date. The PO can decide at any time when there are enough features to ask for a new release. This moment can be predetermined up front but is not related to the length of the sprint.
Start each sprint with the Planning
During the Sprint Planning session the PO will outline the main goals for the incoming sprint. He describes the stories that are at the top of the Product Backlog and the team can technically discuss each story and give an estimation based on complexity (not man days). Once the PO knows how complex the stories are he can move the chosen stories from the Product Backlog to the Sprint Backlog. The total amount of points can be aligned with the average velocity of the team.
Do daily stand-ups
Every morning the Devs stand up for a scrum where each participant says what he or she did the day before and what is going to happen during the day. This stand-up is time boxed to 10 minutes maximum so it is important avoid technical details. The PO and other stake holders can join the meeting but they are not required. More detailed technical discussions can of course be taken offline.
Set up a whiteboard
The Kanban whiteboard displays what is going on with the sprint. It is important that each participant in the process keeps the whiteboard updated. Devs can move cards from “TODO” to “In Dev” and once that the card is complete they can move it to “In Test”. The person involved in QA or pair review can move the card from “In Test” to “Done” or back to “In Dev” if there are issues. There is no need to create bugs for stories that are in the current sprint. We can create bugs that are related to old stories or legacy code.
Requirements, Stories and Bugs
The PO can write Requirements in free hand form. He can add any documentation or description. During sprint grooming sessions, the PO describes a requirement and with the help of the team the Requirement is translated to one or more Stories.
A story has to follow the following template:
As a , I want so that
E.g.
“As an App administrator, I want to view an import exceptions screen so that I can understand what data has not been processed and why.”
Once a story is created the Devs can estimate its relative complexity. The estimation is expressed in points and is based on one or more acceptance criteria. An acceptance criterion is one expected behaviour. A story can have one or more acceptance criteria.
Acceptance criteria can be written using the following template
(Given) some context
(When) some action is carried out
(Then) a particular set of observable consequences should obtain
Grooming sessions
Grooming sessions are time boxed 1 hour meetings where the PO can discuss with Devs what is going on in the Product Backlog. He can discuss each new requirement or story and any relevant bug. During those sessions the team can translate requirements to stories and give them an estimation using planning poker cards. Grooming sessions play an important role in order to be ready for the next sprint so that everyone understands the work involved.
Team Retrospective
At the end of the sprint and before the sprint planning there will be a Retrospective meeting where each member of the Scrum Team can discuss what went well and what could have been improved in the previous sprint.
Sprint review
This is a session that happen at the end of the sprint and is used to show to the Product Owner and any other interested stakeholder the results of the sprint. Devs can bring on the table all the relevant implemented stories and fixed bugs cards and briefly show the result on a projector. This meeting is not technical so if there are cards that cannot be understood by the Product Owner they don’t need to be show here.
Definition of Done
The DoD is a check list that states how a story can be considered Done. Only when a story passes all of the checks defined in the check-list can be moved to the Done column. The DoD is defined by each team.
Example of a Dod
- Code produced (all ‘to do’ items in code completed) and meeting development standards
- Peer reviewed (or produced with pair programming)
- Unit tests written and passing (not for UI items)
- UI items: Approved by Product Owner or QA tester and signed off as meeting all acceptance criteria
- Code check in
- Update ticket documentation describing:
Tech Solution
Test steps
Release notes
References:
http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
You must be logged in to post a comment.