Pragmatic Agile Weblog

Agile software development in real life

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

Certified Scrum Master

Yes, I’m a Certified Scrum Master.

But here I’d like to share with you more than just that I’ve passed the online exam.

I’ve been for three days at the CSM course in Milan with Craig Larman.
He’s a great teacher and professional: the agile/scrum theory that you can learn from books cannot give you the same understanding that he will teach you.
During the three days he shares with you so many practical examples and experiences that you really understand the meaning of Agile and Scrum.

After the course I’ve been totally renewed and with this “force” in me I’ve already been able to improve our implementation of Scrum in Funambol.

The first step I’ve started with is Simplicity: Simplicity is essential (one of the Agile Principles).

I’ll update this pages with the next steps (there are many others in plan).

So… thanks a lot Craig, thanks Francesco Cirillo and XPLabs to have organized the course in Milan.

If you want to learn Scrum and Agile basics this is the course for you… then, as a second step, you’ll be entitled of membership at the Scrum Alliance and you can take the exam for CSM… like I did with 90% of right answers πŸ˜‰ .

January 30, 2010 Posted by | 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 Mobile Open Source: The Book

Funambol Book Cover The new Funambol Mobile Open Source book is out!!!

Really awesome… by Stefano Fornari and reviewers in Funambol.

Here is an introduction to the book:

The book is composed of two parts. The first part will take you through the steps required to fully understand and deploy Funambol to provide PIM synchronization and push email solution to your mobile users. This is done step-by-step, starting from a simple personal usage scenario to a more complex environment that must serve thousands of users. All components of the platform are smoothly introduced and explained, starting from the functionality they provide. The second part of the book is more informative and will assist you in building Funambol extensions. In particular, it contains an easy-to-follow tutorial that will allow you to write a Funambol connector in a few easy steps. If you are looking forward to install and get started with Funambol, this book is for you. You need to have a technical background and be confident with a bit of code tweaking, but not a developer. General server administration skills are assumed and familiarity with Java will be a benefit in places.

Buy your copy from many online stores (Amazon included) and enjoy the Mobile Open Source world.

January 7, 2010 Posted by | Uncategorized | 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

Informative workspace – the scrum kiosk

One of the biggest challenges you have in a organization with 6 scrum teams with some people remote and different stakeholders introduced at different levels in the scrum methodology, is sharing some significant information about the status of the development.

Each scrum team tends to create its own working style, a sort of ecosystem that best fit people in the team. The challenge is to encourage that everyone, inside the scrum teams, but also external stakeholders, can share the same big picture.

One way to encourage better mindfulness amongst the entire team is to create an “informative workspace”, something that tunes anyone in to the status of the project.

Better thanΒ  using my words to explain it, I will borrow an excerpt of James Shore & Shane Warden’s book The Art of Agile Development.

Your workspace is the cockpit of your development effort. Just as a pilot surrounds himself with information necessary to fly a plane, arrange your workspace with information necessary to steer your project: create an informative workspace.

An informative workspace broadcasts information into the room. When people take a break, they will sometimes wander over and stare at the information surrounding them. Sometimes, that brief zone-out will result in a aha moment of discovery.

One recent improvement we have done to make our environment more informative is what we called the scrum kiosk.

We installed a monitor on the wall and we slide-show projects facts: deadlines, status reports, process information and reminders, burn down charts and so on.

It’s a live snapshot of the current iteration and release.

We’ve implemented it in few simple steps using the following software:

DejaClick: Firefox plugin for web browsing recording. It automatically reproduces the main paths done browsing our internal systems and wikka pages

– a Fullscreen Firefox plugin

– a simple Java app to put everything in an infinite loop

You can see some pictures below.

In addition, since we have remote people, we plan to stream the content of the monitor to our internal network, so that everyone can see what’s displayed. Indeed it is not the best solution, but it is something in meanwhile we find a better idea.

Any comments or suggestions is welcome!

December 2, 2009 Posted by | Agile, Funambol, SCRUM | 3 Comments

Brown bag agile lectures

Recently I’ve introduced the concept of Agile Lectures in Funambol (see here)… aka Brown Bag Lectures.

Below you can find the list of the lectures done until now…. a successful initiative in my opinion: 30 minutes every week, informal, cookies, coffee and beverages… not a meeting, more a coffee break (a little brown bag meeting).

Agile Lectures:

01 Sep 2009

  • “The Art of Agile Development” Book- Chapter 6: “Collaborating – Trust”Links:

22 Sep 2009

29 Sep 2009

06 Oct 2009

  • “Agile Estimating and Planning” Book – Chapter 4: “Estimating in Story Points”

… continue…

… maybe we could even do it live online also for external people πŸ˜‰

October 7, 2009 Posted by | Uncategorized | Leave a comment

Cost of unit testing

I found an interesting article about the topic of how much unit testing cost:

October 2, 2009 Posted by | Software development | Leave a comment

Agile lectures

Recently Edo, our scrum master, introduced a new initiative that I particularly like: agile lectures. From his presentation:

What is it?

30 minutes of our time every week to read and comment together some excerpts of Agile (Books, Articles, Tutorials, Videos).
We’ll start with some paragraph from the book “The Art of Agile Development”.


Because learning is an on-going never ending process, we still need to learn something and Agile is hard to maintain


With a projector in a relaxed environment with coffee, tea, cookies. Reading and commenting together. Remote people will join via webex and have virtual cookies πŸ˜‰


Every Tuesday at 4.30pm until 5.00pm (CET).


In the meeting room in Pavia’s office (the cave) and via webex for remote people


Everybody is welcome to the lectures. No need to send confirmations, just come in the cave and join the lectures.

The reason why I like it so much is because we have been realizing that between agile and pragmatic agile there is a huge distance. I see pragmatic agile as the every-day agile, with the environment you are in, the people and the teams you have, the habits and cultures each group of people establishes over time. These lectures are a way to understand how agile and pragmatic agile can get closer. With this I mean that we see how things could be done differently, so that we talk about it and internalize it. I learned that at the end some people are not interested in principles or values at all. They are just interested in their daily job and in how make it better. Agile lectures are a good way to talk about real every-day experience in the context of agile practices.

September 26, 2009 Posted by | Agile, Funambol | Leave a comment

Mike Cohn on user story writing

September 20, 2009 Posted by | Agile, SCRUM | Leave a comment