Friday, March 27, 2015
Tuesday, February 3, 2015
Practical Scrum Training (7) Training Scenario
This is the final post in Practical Scrum Training. I will explain now how I imagine the training should be conducted. I imagine one day, with a lunch break, should be enough to cover what I list here below.
The training group should consist of a few (3-4) groups of individuals and there should be from 2 to maybe 4 people in each group. Each group should be seated in from of one computer.
The training begins with a description of the application and the participants should be able to run the included unit tests as well as the application itself.
Then, the trainer presents the initial product backlog.The trainer acts, to some extent, like a Product Owner. The product backlog refinement that we went through in previous posts is not meant to be performed upfront, but rather in several stages, on as-needed basis.
The goal for the teams is to build product increments in artificially short iterations - each 1 or 1.5 h long. The development team performs all regular Scrum events, like planning, review and retrospective, but because of the artificial shortening of sprints, they are not required to observe any proportion of length of these compared to the sprint itself. For the same reason, the development team does not have daily scrums.
Some of the product backlog items, like checking the validity of entered data, should be hardly possible to increment within an hour and therefore the teams will be forced to divide such product backlog items into a few smaller ones. The teams will be reminded very strongly that they must finish the product backlog items they accepted into a sprint. Leaving an item unfinished at the end of the sprint will be treated as a failure - retrospective should be used to come up with ideas how not to let it happen in next sprint.
Training attendies may choose any approach to work efficiently using one computer per each team of 2 - 4 people. They should, however, be strongly encouraged to use TDD as they code (let's state it directly: they must use TDD). More ambitious teams may try to introduce unit tests into the module that converts internal representation of the tree into pydot objects (something I did not do in the baseline of the application). Apart from wearing the Product Owner's hat the trainer should also do some duties similar to those known from sessions like code retreat: walk from group to group, provide comments and advice regarding code quality. The trainer should be able to do this craftsmanship part of the duties for smaller groups (less groups, less people in a group).
This outline of the training and the family tree example can be used by anyone who wishes to try it out with a development team. You can use all of this information, if you want to deliver this training yourself. As the author of the training, I am also willing to deliver it in person.
The training group should consist of a few (3-4) groups of individuals and there should be from 2 to maybe 4 people in each group. Each group should be seated in from of one computer.
The training begins with a description of the application and the participants should be able to run the included unit tests as well as the application itself.
Then, the trainer presents the initial product backlog.The trainer acts, to some extent, like a Product Owner. The product backlog refinement that we went through in previous posts is not meant to be performed upfront, but rather in several stages, on as-needed basis.
The goal for the teams is to build product increments in artificially short iterations - each 1 or 1.5 h long. The development team performs all regular Scrum events, like planning, review and retrospective, but because of the artificial shortening of sprints, they are not required to observe any proportion of length of these compared to the sprint itself. For the same reason, the development team does not have daily scrums.
Some of the product backlog items, like checking the validity of entered data, should be hardly possible to increment within an hour and therefore the teams will be forced to divide such product backlog items into a few smaller ones. The teams will be reminded very strongly that they must finish the product backlog items they accepted into a sprint. Leaving an item unfinished at the end of the sprint will be treated as a failure - retrospective should be used to come up with ideas how not to let it happen in next sprint.
Training attendies may choose any approach to work efficiently using one computer per each team of 2 - 4 people. They should, however, be strongly encouraged to use TDD as they code (let's state it directly: they must use TDD). More ambitious teams may try to introduce unit tests into the module that converts internal representation of the tree into pydot objects (something I did not do in the baseline of the application). Apart from wearing the Product Owner's hat the trainer should also do some duties similar to those known from sessions like code retreat: walk from group to group, provide comments and advice regarding code quality. The trainer should be able to do this craftsmanship part of the duties for smaller groups (less groups, less people in a group).
This outline of the training and the family tree example can be used by anyone who wishes to try it out with a development team. You can use all of this information, if you want to deliver this training yourself. As the author of the training, I am also willing to deliver it in person.
Friday, January 30, 2015
Practical Scrum Training (6) Discussion of Product Backlog (continued)
Let's consider the product backlog item related to the editing of data. Just this one more and then we'll jump straight into ordering the product backlog.
In order to correct the information about a person in the family tree as a family tree user, I want to be able to edit the data of a person I choose.
I didn't like this item from the start, because it seemed to me rather complicated to develop. When I think about it now, it doesn't seem that complicated. But for the purpose of training, I need to ask a question: can we do anything smaller, break it into smaller parts or do any other trick to achieve something similar quicker than if we were to develop it as is.
As always, there is something we can do. The aim here is correct data. If we add a new item that introduces deletion of people from the tree, it will be possible to delete a person with incorrect data and then add same person again, this time with good data. Maybe a little awkward to the user, but if we desperately wanted to deliver the "correction" functionality quickly, then maybe we could get away with this approach and deliver real editing functionality one iteration later.
But there's a catch: if we delete a person and add them again, then the "new" person will have a new, unique identifier and the identifier of the deleted person may be spread in several other records (children).
It may be a good point for the training to suggest the deceitful solution with deletions and see when the trainees are able to spot this problem. At planning? Maybe during the development? Maybe someone writing a test for it will be able to spot it quickest?
After thinking about all of this, I conclude that deletions are important (but are not good substitutes for editions) and they deserve to be a product backlog item on their own.
This is how I would order the product backlog item now:
That's it. The next post will outline how I imagine the training should be conducted.
In order to correct the information about a person in the family tree as a family tree user, I want to be able to edit the data of a person I choose.
I didn't like this item from the start, because it seemed to me rather complicated to develop. When I think about it now, it doesn't seem that complicated. But for the purpose of training, I need to ask a question: can we do anything smaller, break it into smaller parts or do any other trick to achieve something similar quicker than if we were to develop it as is.
As always, there is something we can do. The aim here is correct data. If we add a new item that introduces deletion of people from the tree, it will be possible to delete a person with incorrect data and then add same person again, this time with good data. Maybe a little awkward to the user, but if we desperately wanted to deliver the "correction" functionality quickly, then maybe we could get away with this approach and deliver real editing functionality one iteration later.
But there's a catch: if we delete a person and add them again, then the "new" person will have a new, unique identifier and the identifier of the deleted person may be spread in several other records (children).
It may be a good point for the training to suggest the deceitful solution with deletions and see when the trainees are able to spot this problem. At planning? Maybe during the development? Maybe someone writing a test for it will be able to spot it quickest?
After thinking about all of this, I conclude that deletions are important (but are not good substitutes for editions) and they deserve to be a product backlog item on their own.
This is how I would order the product backlog item now:
- In order to correct the information about a person in the family tree as a family tree user, I want to be able to edit the data of a person I choose
- In order to make corrections in the family tree as a family tree user, I want to be able to delete a person from the tree
- In order to add new people to the family tree efficienty as a family tree user, I want to be asked if I want to add another person right after I added the last one
- In order for the family tree to be easier to read as a family tree user, I want the graphical representation of the tree to alternately use one of two different colors for each generation
- In order for the family tree to be easier to read as a family tree user, I want the graphical representation of the tree to rotate colors of generations from a predefined set of colors
- In order to maintain integrity of family tree data as a family tree user, I want the identifiers of the parents checked (natural numbers, identifiers are optional) and blocked from being entered if invalid
- In order to maintain integrity of family tree data as a family tree user, I want the identifiers of the parents checked to be existing identifiers of people already existing in the tree and blocked from being entered if that is not the case
- In order to disallow non-logical connections in the family tree as a family tree user, I want to be blocked from pointing a person as their own parent
- In order to disallow non-logical connections in the family tree as a family tree user, I want to be blocked from pointing the same person as both mother and father of someone
- In order to distinguish the gender of a person in the family tree as a family tree user, I want to be able to assign gender attribute to each person
- In order to maintain the data about births and deaths in the family as a family tree user, I want to be able to assign birth and death dates to each person
That's it. The next post will outline how I imagine the training should be conducted.
Subscribe to:
Posts (Atom)