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

We are late! let’s do scrum meetings

Well, you won’t believe it, but this is the kind of comments I witnessed today! I am at a big customer on a very big project. You know, many parties involved, big companies, a complex environment and a lot of stress for the approaching deadline…

In the status meeting, the big boy realized we can run out of time. The feeling of not making progress was starting to dominate the meeting… until someone came out saying “maybe we should do a scrum meeting every day” to speed up things…. I wish it could be like that!

What they do not realize is that to have better control of the project, and speed up things, they should start to work better together and trust more each other; not to increase the level of control on the project’s tasks. This is the exact opposite of scrum and what will make them waste a lot of time…

August 2, 2010 Posted by | Agile, SCRUM | Leave a comment

Agile Jedi Initiative

Ok… in the agile mythology it is enough you explain agile to your team and everybody in the team will be excitedΒ  about it and can’t wait to start to release something every week and do pair programming. If this does not happen… just fire who is not convinced enough and hire somebody else…

I do not want to argue if this is a dogmatic or pragmatic position, I would just say it is not the way I like to face the issue. If there is something that agile tells you is that hiding the problems under the carpet of time does not make you do better. From agile you learn to highlight the problems and find the solutions.

In introducing agile in a team of about 30 engineers, we experienced people reacting in different ways: somebody was excited (at least in principle), somebody doubtful, some were completely against (and maybe still are), the most close to neutral. What to do in such situation? Fire who is not fully convinced and hire a new team? Give up? Or firmly keep trying to change things and fix problems convinced that the results will come? We have taken the former approach, but I have to admit we had to push some changes from top to the teams. This is not ideal indeed and only the time will tell if it was a good thing or not. For sure, it is not something you can keep doing for too long. How then encourage people to free-up their energy also in making the way they work better, easier, more efficient, more knowledgeable… in a word more enjoyable?

One initiative we introduced and I hope will bring the benefits above is the Agile Jedi Initiative. Aim of this initiative is to combine ideas, sensitivities, skills and energy of who is more sensitive to agile practices so to build a working group open to anyone that sees a problem in the current practices and wants to contribute to solve it. This is something that shall come from the teams and that is for the teams. I really hope it will virally spread to all members of the engineering team.

But what’s the mission of an Agile Jedi? A simple question with a non trivial (or no) answer, so let’s get some principles come to help us. An Agile Jedi:

  1. Constantly inspects and improves
  2. Does what makes sense, never more, never less
  3. Takes ownership
  4. Grows leadership
  5. Turns problems in opportunities
  6. Is not afraid to make mistakes
  7. Searches for the next right answer
  8. Breaks the patterns, sees things under different perspectives
  9. Exercises agile techniques
  10. Helps anyone in all the above

May the Force be with you!

May 1, 2010 Posted by | Agile, Funambol, Uncategorized | Leave a comment

Sprint Review meeting is always fun

What are you sinking...

Do you know that feeling when you’re doing right? When the team is working effectively and with passion, focused on releasing value every sprint?

Well, one of these moments is during the Sprint Review meetings (the good ones).

And in order to properly celebrate the well DONE sprint I had the idea to close the review meeting with some nice “agile” messages: funny and interesting at the same time.

So I have started projecting some funny videos on basic agile themes from youtube: short and funny.

Here’s the list of the latest ones by category:




Enjoy the show and celebrate your scrum meetings when it is worth to do it!

April 6, 2010 Posted by | Agile, SCRUM | Leave a comment

Self organizing team or monster???

As you may know we recently acquired an Ukrainian company; they were mainly developers (in a wide – or agile if you want – sense) so they joined my team. Since they had all the competencies to release a software product, the most natural choice for me was to organize them in their own scrum team. In the past we have been working with teams neither fully collocated nor fully remote, and we have been experiencing the pain of such situation. Therefore, I wanted to avoid it at all costs. Also, their competencies where more focused on the client side of our product, which looked to me another good reason to keep them together in a remote scrum team.
Since this is not what I want to talk about in this post, I’ll make the long story short. The organization above shown some issues that the teams perceived as a big impediment to them because the remote team could not reliably commit on client-side user stories until the server side-stories, developed by another scrum team, were done.

To come to the topic, by chance, the other day I heard my development manager and the scrum master discussing about how the teams wanted to solve the problem: mix the server and client teams so that they both had who can work on the back-end and who can work on the front-end. Unfortunately, this also means to make both teams again partially collocated and partially remote. This reminded me with terror the past times and our previous bloody experience with such teams. I therefore started to question the decision and remarking my strong opinions, probably also making quite evident my opposition to the decision.

At that point, Edo (the scrum master) candidly asked:

“Stefano, do you want the teams to self organize or do you want to make the decisions on their behalf?”

He left me speechless and weaponless…
I do not want to be fake-modest here… being a founder and the CTO of Funambol, I know I am an heavy presence… I interviewed everybody in the engineering team and no one takes me lightly (or at least I hope – if you are new to Funambol you are warned now πŸ™‚ ). Still, that was I had to hear… 😐

I hated him with all my forces. But at the same time I loved him with all my heart. I mean… what could have made me more happy having embraced agile? The teams are the ones at the front line. They fight every single day. They know their problems and they want to fix them. What must be here my role? Tell them I know more then what they know looking around from my desk? Or give them all support they need to remove the impediments they have found out?

Guys, that’s the way I want you. Put your balls (wherever you have them) on the table and tell me I am wrong; show me I am fucking wrong!

If I have created a self organized team or a monster, only the time will tell. For now it is good to know I can go on vacation tomorrow for 6 months and no one will ever notice it! It is a great feeling. A feeling of achievement of at least a milestone. It is time for a new tattoo!ο»Ώ

March 28, 2010 Posted by | Agile, Funambol | Leave a comment

Stabilization sprints

One of the most advertised advantages of agile development is that at the end of each iteration the product is always releasable. The idea is that each piece of functionality is either done or not done and everything done should be shippable.

Ok, we are not that good yet πŸ™‚ Or maybe this is not even a realistic goal in some organizations or under certain conditions. Under the cover, the subject is not that obvious and if you are interested in knowing more these are few interesting links:

We adopt stabilization sprints before declaring a release GA. Indeed, the stabilization process is a work-in-progress that we try to improve at every release. For the upcoming release we structured the stabilization process in two main phases: integration and final stabilization. The integration period will take two iterations and is focused on putting all components together and performing integration and other high level testing. Then we will have one iteration of final stabilization. In this last period we will focus on real usage to make sure we do not encounter major issues that will get in the face of the user on real deployments. In the following, the process is described in little more details.


Length: 2 2week iterations
Focus: integration, regression and performance testing; general testing by selected users (dogfoodding)
Entrance criteria:

  • snapshots of all components ready
  • user documentation ready
  • no bugs targeted to the release
  • no development planned for the release
  • device list of the devices we condider blocker for the release ready

Output: all packages become release candidate

Final stabilization

Length: 1 2week iteration
Focus: stability and general testing by selected users
Entrance criteria:

  • all components are release candidates
  • network environment for testing machines verified and locked
  • performance are ok

Output: all packages become GA

During integration testing any bug found is triaged to determined if it must be fixed in the current release or can be postponed. Of course the bar is pretty high assuming most of the bugs should have been captured during development iterations.
The final stabilization iteration is intended to make sure a live system works smoothly for a period of time without major flaws. In our experience, it is a very good way to capture things that are difficult to foresee in advance and that likely (as per Murphy’s law) a customer would run into pretty soon. Only really sever bugs should block the release at this stage.

I keep asking myself if stabilization sprints are necessary in real cases or instead are just a sign of sub optimal development practices during normal iterations. For now, my experience tells me stabilization gives still a lot of value to the quality of the product shipping and allows to focus the team on tasks that would be not very efficient to do upfront in each iteration. But as usual, we will see how it goes and try to improve next time πŸ˜‰

se dico che vado a correre

March 4, 2010 Posted by | Agile, Funambol, SCRUM, Software development, Software engineering | Leave a comment

Yellow and Red Cards: teams like a referee with the Scrum Master

… another idea to improve the interaction between the Scrum Master and the teams…

One of the main goals of the Scrum Master is to help the teams, helping in:

  • applying Scrum and Agile methodologies
  • removing impediments
  • performing good and effective retrospectives
  • in other words… putting mirrors in the software development process

But what happens if the Scrum Master is not really a Master?
The teams:

  • don’t apply Scrum
  • don’t report impediments
  • don’t have good retrospectives with practical action items
  • in other words… don’t improve their way of working

So I had this idea that comes from Soccer rules:
each team has the following 2 cards (yellow and red) and, like the referee in a match, can book with the yellow card or even send off with the red card the Scrum Master.

One rule of Scrum is that the Scrum Master work as a servant leader so if he’s not performing well in this role, he should be fired.

Here are the rules:

  • if the Scrum Master doesn’t help the team for what he is in charge of then the team will show the yellow card
  • if the Scrum Master continues not helping the team after the first yellow card then the team can use the red card and fire the Scrum Master

I think that this approach will help us to work more proactively and better following the road of improvements day by day.

We’re just starting the game and I hope the teams will apply it as an english referee (tipically ignoring small faults but punishing the most serious ones πŸ˜‰ )

I’ll keep you updated on how it works.

After leaving Diego Maradona’s shirt ripped almost to shreds and his ankles lacerated, Claudio Gentile remarked that “football isn’t a game for ballerinas”…. we could say that “Scrum isn’t a game for ballerinas” πŸ˜‰

February 11, 2010 Posted by | Agile, Funambol, SCRUM | 1 Comment

User stories! user stories! user stories!

Something happened today that made me laugh and think about why I love so much user stories.
We had a old conference phone that we haven’t been never too happy about, but it was doing a kind of its job, so we kept it for long time. The other day, after a terrible call where no one could understand each other (not just because of the phone πŸ™‚ ), we decided to replace it with a new one. One person (I will avoid any hint that could point the finger to the persons involved πŸ™‚ ) ordered the phone and waited the delivery. Right. When the phone arrived that person asked another person to install it. The other person installed it. Right.

Today I come into the office and person1 + person2 told me happily and proud: “We have the new phone!”. “Great!” I said, “does it work well?”… Person1 + person2 looked at each other and I could see a baloon with a big question mark coming out of their heads… the user story “AS A user I WANT to make a conference call SO THAT we improve communication with remote people” was not done indeed! and I did not accept it! πŸ™‚

January 20, 2010 Posted by | Agile, Funambol | Leave a comment

Funambol Code Sniper v2: agile open source development?

Ok, at Funambol we like challenges πŸ™‚ Who knows about Funambol development, may know about the Code Sniper program. It is a program that with the aim of encouraging open source development around the Funambol platform, offers bounties to develop projects that the community would like to have.
The original program worked fairly well, but shown also some limitations. The main issues we have been facing are:

  • technical specifications vs features specifications: the first thing a developer was requested to do was to write a specification document so that the community could understand what was being developed. Typically, this was more a technical document that explained how things would have been done. This may be a good thing, but it does not show which value a potential user would get from the software.
  • whole or nothing: being the project based on a monolithic specification, the approach of the development was in many case a monolithic effort. The developer started the development one her own, and until everything was done, the community did not see much. In other words, this approach does not encourage an iterative and incremental development so that potential users cannot see anything until the entire project is done. At that time, feedback may become not only not welcome, but even frustrating (you tell me know that this is not what you wanted???).
  • long development cycle: the above, usually turns also in a longer development cycle that results in a higher risk that the developer does not complete the work for lack of time, abandoning the project in an unknown state. This makes it more difficult for another developer to take over.
  • difficult work recognition: how to recognize (and then remunerate) the work done? in a whole or nothing approach we are forced to recognize the work done only when all the work has been completed. But this can be unfair if a developer has done some work, but could not complete the project. Plus, it becomes a barrier to picking up a sniper by the developer community.

In short, the above limitations result in a higher barrier to the participation to the program. Stefano Maffulli tackle the problem and redesigned the program to make participation simpler and wider, even for non-developers, and to provide long term incentives. Code Sniper v2 rewards not only developers but also testers and users that provide feedback. It is simpler because it only consists of only three steps:

  1. Identify the target – pick from a list of projects, which are ideas provided by Funambol or the community
  2. Contribute – write feature requests, develop code, test or give feedback. Development is carried out by volunteers that pick items to work on from the list of feature requests or from bug reports. Each time an item is completed, a new version is released
  3. Collect your reward – for each released version, contributors collect the reward and the cycle can start again, providing a long term incentive to collaborate

You can find more information here.
There is an interesting aspect of the new Code Sniper program that I want to highlight. The new program is designed around principles that come from the agile community. Let’s see how, in addressing the challenges identified above.

  • technical specifications vs feature specifications: the new program encourages the use of User Stories to describe requirements. This changes completely the approach to how specify what is going to be developed in two ways: first, they are written with the point of view of a user, describing what a particular user will have instead of focusing on how something should be done or should work; secondly, user stories encourage the description of features in smaller pieces, more than in a monolithic set of functionality. You can see an example in how to write a Funambol Sync Client, the agile way.
  • whole or nothing: being able to break features in small user stories, each bringing value to the user avoids the whole or nothing approach. It also allows to see the development of a component as an iterative process. At any given time, the application does something. User story after user story, the application builds up, giving more value to the user at any addition. This encourages an earlier adoption of the software. Not all users will be satisfied at any moment, because maybe the application does not give enough value to them. But other users or developers can benefit from even an incomplete application, thus being more stimulated to contribute.
  • long development cycle: each user story must be a self contained feature. It is not allowed to check in a user story until it is complete and working. The goal is to have a working application at any given time; maybe incomplete, but what is in must work. This allows to break the development in smaller cycles, to release more frequently (potentially at any time), to be able to test a feature earlier. This should also stimulate participation because a developer knows that she does not necessarily has to be in charge of a big task (and therefore a big effort), but she can pick up the user story that she can do in the time she has available.
  • difficult work recognition: now that the work is divided in user stories, it is also much easier to recognize the work of a developer. A developer has done when a user story is working. This also means that more activities than just development can be recognized. For example the definition of the user story itself and the acceptance criteria to consider it done; also the testing to accept or the user story can be rewarded. For example a user story could be picked up by two people. One (the final user) would scope the user story, define the acceptance tests and perform the testing. The other person could develop the code.

I believe this is a kind of ambitious goal and truly experimental. We do not hide that there is the other side of the coin. Probably, being inspired from agile methodologies, this approach requires more educated people. But hopefully, as agile is emerging as the most popular development model, this will not be a big issue. Anyway, in the spirit of agile, we will try, inspect and correct!

Feel free to leave your comments and feedback!

December 18, 2009 Posted by | Agile, Funambol | Leave a comment