Pragmatic Agile Weblog

Agile software development in real life

The use of SO THAT in user stories

recently, I found a good example of why (or how) to use the SO THAT clause in a user story. The use case is simple: a web site where the visitor should not be required to sign-up or sign-in.

The US would look like:

AS A visitor I WANT to access the site without any sign in or sign up SO THAT …

What to put in the SO THAT clause? try not to read the below and stop a bit thinking about it. What would you put?
I am pretty sure most of you is thinking “it depends by the reason why this is needed”…. EXACTLY! the SO THAT clause tells something about why we want that US; it tells something about the value to the user. It is important, because differently than use cases or formal specifications, it does not give the exact intended behavior, but just the goal from a user perspective. This tells us a lot in terms of what we can think of and what we should not if, for example, we want to provide the functionality in increments.

Back to the US, one version could be:

AS A visitor I WANT to access the site without any sign in or sign up SO THAT I do not give any personal data to the site


AS A visitor I WANT to access the site without any sign in or sign up SO THAT I can easily and quickly access all functionality of the site

As you see these two USs provide very different perspectives on what’s the real value to the user: in one case is privacy, in another case is easy of use. This can bring to very different strategies to split the story if necessary.

August 18, 2011 Posted by | Agile, Software development | Leave a comment

Declaring war to branches

What do branches have to do with agile? They have a role under many aspects. I will not cover the most basic ones like why a version control system is necessary (which is true regardless you do agile or not), but I want to cover a bit some implications we are facing in an environment with many teams working in parallel.

I believe the role of a VCS is fundamentally twofold: it’s the central repository of code from which you deliver a new release; and it is a communication tool, so that all developers can see what each other does and keep themselves updated with each other work.

In this post, I want to go in more details about the second aspect, accordingly to some real work (and world) experience I notice in my teams.

The concept that a scrum team uses the repository as a communication tool, is quite widely accepted. I would say it is well metabolized by each team member, so that everyone does not feel comfortable in keeping the code on his/her laptop only. It is the way code is exchanged, which is very good indeed. It is also well received and assimilated as a communication tool between different teams, so that we can all relay on nightly builds built from the trunk. The code repository is therefore a tool every one in the team relay upon to have the most stable code.

What’s wrong then? well, nothing in itself. However, there is a dynamic I am still trying to understand better, but that is showing some very bad effects. I start to identify a broken pattern, which is like this:

  1. One dev team needs to implement a new feature for a customer that we want to include in the product;
  2. Because as usual customers are in hurry, you need to deliver as quick as you can, and all that you know better than me, the team decides to make branch for that customer and develop the new feature on the branch
  3. Since everybody understands that 2 must be a temporarily solution because we want at the end the feature in the product, the team promises itself after releasing to the customer the branch will be merged
  4. The merge does never happen

And here is where the process breaks. At the end, you have different customers with radically different versions, all live with something that it is not the product. And because they are live, the forces against update them with a new release of the product are so strong that very hardly they will ever be all aligned to the same version. I am sure all readers understand this is quite bad, and who hosts for their customers, understands how bad it is even more.

The reasons why the merge does not happen are many and all good: firstly and most fundamentally everybody is scared to do the merge because at the point when it will be done, the code has so diverged from the trunk that the merge will be boring, very hard, long and will surely result in breaking the product, requiring a lot of regression and so on. Secondly, if the project is successfully, very likely you have a phase II, still urgent, still important. Do you want to risk you break everything? of course not, let’s keep working on the branch… this is even more true in agile development where it is us before all that tries to make the customer accept to do things incrementally and in phases.

So, should we ban the branches at all? Shall we just all work on the trunk? Honestly I do not know, at least yet. But I want to see if there is another way… what I’ve been doing since a few iterations is trying to understand why the teams feel so badly the need to work on branches. I am realizing something interesting that I want to report below:

  1. Usually branches start from a genuine good intention of a team, not wanting to interfere with the work of other teams: if I work on my own branch, I will not break the code for you, so that you can keep working like I wasn’t doing anything.
  2. ┬áThe above is a practice also in place during the iterations, even at the level of a single iteration. The assumption is that the code will be merged before accepting the user story. The good news is that at this level (differently from branches for a project) the teams do it diligently. However what’s the direct result? it is that the other teams will just see the code changing suddenly at the end of the iteration, without time to remedy. The good intention of not breaking the code for other teams turns into delaying the time when issues can be encountered to a time where usually there is not more time to fix things within the iteration.

What I am finding is that branches are created mainly for the fear of breaking the code for other teams. Again, the intention is good, but is it the best way to make sure we do not break the code for other teams? Are we sure we can not work differently so that we do not break the code, and if we do is not a big deal?

In working directly with the teams I started to question the need of a branch and I expressly asked a team to discuss a bit before creating one. I am finding particularly interesting that most of the times, the need of a branch comes from the fear that only potentially a developer interferes with the work of another developer. And even more interestingly, they may be working on the same code. This seems common sense at a first glance. But when asking something like: have you checked with the other team if this is a problem? have you talked to them to see if touching that area of the code would be a problem for them? have you briefly discussed the changes together so that everybody will not have big surprises? …
You know what? most of the times that communication did not happen. Thus, the communication tool subversion, is turning into an obstacle to a more effective and efficient way to communicate: talking. This is the aspect I consider more important and that I want to attack. I want to attack the fear of breaking the code for others. And I believe the best way is not to isolate more the teams, but more integration between them. The best strategy is not to avoid to interfere each other, but to interfere more, on a daily basis, working all the time on the same trunk of code. I am sure this will break things more often and we will have a less stable trunk for a while. But I also think the incidents that will happen will make the teams generate the anti-corps to pay more attention to the code they release, to make sure code is tested at build time, to be able to change code more quickly and to talk more each other to save time and effort.

Therefore, from now on, I declared war to branches!

August 15, 2011 Posted by | Agile, Funambol, SCRUM, Software development, Software engineering | Leave a comment