niedziela, 6 grudnia 2015

Limit WIP

Although Scrum Guide does not mention this explicitely, it is an important part of sprint planning and the sprint work itself to limit the amount of Work In Progress. Let's look at this aspect in detail and consider some examples.

Without the notion of WIP, several team members may just start work on several backlog items, say 6 developers start 6 different backlog items. In practice, this apporach often goes together with the phenomenon of one developer working on a single backlog item for several days - either because they are too big for one person to complete them quickly or because they are too big in general. If the backlog items are too big, each developer may work on their backlog item even for the whole duration of the sprint. Now, there are some disfunctions in a team that does this:

Teamwork
Each developer is focused on their backlog item, so there is no really teamwork there. If at least 2-3 developers focus together on one backlog item, it fosters collaboration and gives people common aim. Developers who work together on one item are also more exposed to changes being made in the code, because nobody is developing in a silo.

Predictability
It is very difficult to say if the team is going to each the spring goal at any point during the sprint - everything is in progress, everything is assigned, but what will actually be Done - this is unknown almost until the very last day. With smaller backlog items and 2-3 developers working on each, a substantial part of sprint backlog is completed during the sprint, so it is much easier for the team to gauge what will be completed by the end of the sprint (at least the items that are Done now wil be Done at the end of the sprint).

Sprint planning
With silo work and big backlog items the team is bound to miss important aspects of the spring planning meeting. After all, a developer that is going to work alone on backlog item A for 10 days will not have much to say about his plan. On the contrary, if a few developers work on each backlog item and the backlog items are rather small (say, doable withing 1-5 days each), the sequence of work is becoming very important during the planning. The team will not plan to start the bigger backlog items late in the sprint. They will consider the order of sprint backlog and the order of their planned work during the sprint to maximize the probability of achieving the sprint goal. They may even notice that what the Product Owner desires is not achievable in a sprint - not because there is too much work to be done but because the sequence of work puts constraints on the delivery.

In a well performing team, there should typically be more than one developer working on a regular backlog item. The backlog items should flow quickly from In Progress to Done, because they are small and two or more people usually work on each. The team may choose to set official WIP and put it on the corkboard - no more than 3 backlog items In Progress at the same time. Or they may just pay attention to it without setting the official limit. Finally, a good Scrum Team will pay attention to defining and splitting the backlog items so that they are small. It is not enough that a backlog item is just doable within a sprint. Smaller backlog items give the team more flexibility in the way they plan to sequence their work and allow them to start work on next backlog items even near the sprint end.

wtorek, 29 września 2015

C3 - the origins of XP

I think this is not widely known, even among Scrum/XP practitioners and therefore I would like to spread it: please devote 10-15 minutes of your time to learn about C3 - Chrysler Comprehensive Compensation project.

If you read even these three short entries:

you will learn why this project is regarded as the one that gave birth to XP and you will see which, now very famous, folks from XP/Scrum world worked on C3 in the '90s.

To give you a trailer, this is what Chet Hendrickson wrote in the article that I provided the link to (last from the list). Share this with your Product Owner :-)

When C3 was restarted under Kent Beck’s coaching, Marie sat down and wrote the user stories we needed for the first release plan. She was able to explain how the stories fit together. She assigned their priority. She questioned our estimates. She would have made the estimates, if we had let her, and she would have down about as well as we did. She approved every acceptance test. She did a hundred other things that we eventually took for granted.

We don’t know how Marie learned to do all of this. Marie didn’t know how she knew it. She must have known before we started the project, because we don’t know how Marie knew these things, we were not able to help her do them. And, because Marie didn’t know, she wasn’t able to teach others how to help her (...)

środa, 6 maja 2015

Scrum Days conference - Warsaw, 28-29 May

Scrum Days conference is just a few weeks ahead. On the second day, during the Workshops part, I'm going to conduct the Practical Scrum Training, similar to that I described here in my blog, but based on a different application example, so that it can fit into the time allotted.

If you are coming to the conference and you have not read the Practical Scrum Training posts yet, I encourage you to do so. I was able to try the training out with two groups of people of various skills (developers, scrum masters, managers) and I'm convinced that at Scrum Days we are going to have almost 3 hours of great fun and learning.

If you already know you want to join the workshop, please prepare a laptop with Python 2.7 installed and any source code editor you prefer (mind the tabs). You only need just a little knowledge of Python to attend the workshop :-)

http://scrumdays.pl/



wtorek, 21 kwietnia 2015

Barbarians will take it all

[Wikipedia]
A barbarian is a human who is perceived to be uncivilized (...)

(...) Barbarian Invasions, was a period of intensified human migration in Europe, often defined from the period when it seriously impacted the Roman world.




We (professional software developers) are the Roman world. You who read this post, are most likely part of the Roman world.

Who are barbarians? Barbarians are all of those people who do not have the background (both in terms of education and experience) that the Roman world perceives as necessary to do a job in software development field.

Barbarians have lower expectations when it comes to salary, office and tools standard, fancy titles, etc.

They use a lot of stuff invented by the "real" developers so far. They may not have profound understanding of how this stuff works in details, but they are very skillful in using it for specific purposes. More often than not, Barbarians do not build excellent, fault tolerant software, but rather software that is good enough. And their customers are happy with that which is good enough.

Barbarians have a very strong drive for getting things done and strong focus on work. They are very often able to complete an assigned piece of work much quicker than the Romans.

The Romans detest everything the Barbarians develop, even the greatest products that some of the Romans would not be able to do themselves. At the same time, Barbarians admire many of the works of the Romans.

How did it start? I think some smart folks just figured out that creating a small nice web service is not that hard. Then, they learned how to do some fancy scripting on a web site. Then, they figured out how to do things on the server side. Next, they realized they have skills to do similar things when it comes to a standalone application or a different application server, etc. They got better and better at it. And they do not need all the overheads that the Romans do: they do not need architects or analysts to do their job. They just go ahead and do it. Would you hire them for a project? I would certainly do. NASA wouldn't. But NASA can afford to hire the Romans.

I am with the Barbarians. I think they will take most of the IT marketshare within the next 10+ years. I don't think this is anything bad. This is just a bucket of cold water to those that are too nosy.

wtorek, 3 lutego 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.

piątek, 30 stycznia 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:

  • 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
Is this the only good order possible? Of course not. This is only how I see it and I did not consult this with anybody (customer, potential user). Also, once the items are estimated, the order of development may slightly change when the development team estimates what can be done in each iteration.

That's it. The next post will outline how I imagine the training should be conducted.

środa, 28 stycznia 2015

Practical Scrum Training (5) Discussion of Product Backlog (continued)

As promised in the previous post, we are going to discuss the product backlog item:
In order to secure integrity of family tree data as a family tree user, I want to have checks for all data I enter so that entering invalid data is not possible
Is this an easy one, or rather difficult and big? Maybe it's not super-difficult, but it is a large one, probably in the top three biggest items that we currently have in product backlog. How can we break it down?

First of all, let's realize which data needs to be checked. When adding a new person to the tree, we enter:
  • name and surname - these probably do not require any checks
  • mother and father IDs - definitely needs checking
Now, depending on the order of the product backlog, we may or may not have additional attributes that need checking. If we deliver an increment with birth and death dates and gender attributes available for the user before we deliver this item, then this will open a whole new set of checks and the item will be even larger. On the other hand, if we deliver this item first, then we will probably need to think of checks while doing the gender item or any other product backlog item that has to do with person attributes. Doing checks will then be an integral part of the items ordered later or it will be covered by a separate backlog item, to make product backlog items smaller. In this context, think about the product backlog item that adds the ability to edit person's data.

Let's leave the order of product backlog items aside for a while and consider the checking of the IDs of the parents. We could say: that must be a number - and just check if that's a number. This would be purely syntactical checking. But we could go further and check if an ID entered actually exists somewhere in the tree (that is, is a valid ID of a parent). We could even check if a person is ever added / editted as their own parent and disallow this situation. Or wait - we could also check that the IDs of the parents are not equal to each other, which would mean someone is trying to set the same person as mother and father. And all these possibilities are good cases to consider for checks, even assuming that we do not have gender attribute developed yet.

There is also one extra hint that I can give you: did you notice that this item contains the word all?
In order to secure integrity of family tree data as a family tree user, I want to have checks for all data I enter so that entering invalid data is not possible.

Beware of this word in any product backlog item you see. That means it is too general and it tries to embrace too many known and unknown things.

Product backlog items that use universal quantifiers (like "in all cases", "for every possible configuration", etc.) act like magnets and they attract newly identified scope, making the item difficult for the team to finish within a sprint. 

Even with the assumption that we have not developed anything prior to this product backlog item (no dates, gender, etc.), we could divide this item into several smaller ones:

In order to secure integrity of family tree data as a family tree user, I want to have checks for all data I enter so that entering invalid data is not possible.
can be refined into:
  • 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
Isn't that nice?

poniedziałek, 26 stycznia 2015

Practical Scrum Training (4) Discussion of Product Backlog

This post is a base for a discussion that could be held with a group of developers, facilitated by a trainer.

Let's look at our Product Backlog again and color the items that seem clear and straightforward green and those that require further discussion blue.
  • 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 present each generation in a different color
  • In order to secure integrity of family tree data as a family tree user, I want to have checks for all data I enter so that entering invalid data is not possible
  • 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 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
This coloring does not mean that all the green items are absolutely clear about the details, for example, the last item does not say if birth date should be mandatory. Maybe yes, maybe no. Maybe the customer wants this to be mandatory and we will need to persuade them that optional is a better option for birth dates. That is all OK - it is not the point that all such details are known straight from item title. It is just first "C" in 3C: "Card, Conversation, Confirmation".

Let's talk about the second item from the list - tree coloring. Why is it blue? The basic idea is easy to get. The concept of what a generation is clear. Even if we do not have the algorithm to distinguish between generations, we would be able to manually color even a complex tree, were it printed on paper. I think the only thing that needs to be clarified is how many colors will do. Saying just "each in a different color" may be difficult or impossible to meet for very large trees. But maybe our program will never be used for trees larger than 4 or 5 generations. Or wait, maybe that's not good assumption. So if we may have a user that wants to maintain 12 generations, do we need 12 different colors? Will the user actually be able to distinguish between them then? Or maybe it will be all good if we just have 5 colors and use them one by one to color consecutive generations and simply switch from 5th to 1st color when we still have something to color? Yes, this last idea seems just fine, we may agree later if that's 5 or something else.

That much for clarification, but is there possibility to break this item into a couple of smaller ones? No, it is what it is, either we do coloring or not. Would it be easier though, if we started from just two colors? Well, yes, it could make things a little bit easier. If we were to use just two colors we could just say that whatever the color of parent nodes is, the color of all their children should be the other one. I think this would result in proper coloring of generations (that is, alternating between two colors) for any family tree. So, even for such seemingly undivisable product backlog item, we were able to break it into two that we can order one after another:
  • 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 next post, we'll discuss the product backlog item that says about data checks.

niedziela, 25 stycznia 2015

Practical Scrum Training (3) Product Backlog

This post features the product backlog that will be used for the remaining parts of the training. It is deliberately not ordered and some of the items are written such that they can be good candidates for Product Backlog Refinement.
  • 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 present each generation in a different color
  • In order to secure integrity of family tree data as a family tree user, I want to have checks for all data I enter so that entering invalid data is not possible
  • 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 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
Sit comfortably and think for a while about this Product Backlog. What would be the best order of the items, in your opinion? Do you see items that need refinement or spark questions about the details?

In next posts I will try to answer these questions as I see it.

piątek, 23 stycznia 2015

Practical Scrum Training (2) Basic functionality is ready

I completed what can be called a basic version of our family tree application. This is what the user can do with it:
  • add new people to the tree
  • print the tree in text mode
  • save the tree as png file
The program works from command line and can be started by typing:

$ python main.py

Prerequisities: there must be pydot and graphviz installed on the system to run the program.

The files:
The program has some shortcomings, for example it requires one to put the IDs of parents while adding a child, but in general it works fine. It can create a png picture like this one below.


This version is the baseline for the trainees to start. The backlog from which to work on extending the application will be published in next post.


sobota, 10 stycznia 2015

Practical Scrum Training (1) Outline of the application

Next several posts will be devoted to the Practical Scrum Training I decided to develop. The basic idea for the application that will serve as an example will be this:

A desktop application capable of maintaining and presenting a family tree. The basic version of it (that students will be provided with at the start of the training) will most likely allowed just for:
  • entering individuals and defining their relationships
  • presenting data (I'm not sure how, at the moment)
  • persistently storing the data so that it can be loaded at next start of the application
That's most likely all it will do. It will not be written with great care to the craftsmanship and that will be on purpose - it should be like any of these applications that you start working on when it has already been developed to some extent and your job is to extend it rather than develop it from scratch.

sobota, 3 stycznia 2015

Practical Scrum training for Developers - a proposal - your feedback is welcome!

I have an idea of developing a practical Scrum training targeted at Developers that would use hands-on programming examples.

Most of Scrum games that I know of or experienced are metaphores, like building objects with Lego blocks, not real software development. I'm not saying these examples are bad, but there is definitely something lacking in terms of what Developers may practise at a training session.

My objectives for the training are:
  • develop an application and a rough product backlog that could be then refined and implemented during the training session
  • focus on breaking large user stories into smaller and smaller ones
  • incorporate TDD as an XP practice
The training would be done using Python.

Now, I need your feedback: do you think you would sign-up for such a training, if I had one ready? Would you want me to run this training for you? Do you also think that's something that is missing from regular Scrum training offer?

Please use comments or contact me directly with the feedback.