Pragmatic Agile Weblog

Agile software development in real life

Scrum?… a formality…

When somebody in the team says that Scrum is like the 12 tasks of Asterix in the following video….

What do you do? What is the best approach to manage the situation?

I’ve just posted the question to the scrumdevelopment Yahoo group and I’ll report here some feedback.

Stay tuned!


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