Pragmatic Agile Weblog

Agile software development in real life

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

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:

Teamwork:

Communication:

Misc:

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

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:

http://blog.mountaingoatsoftware.com/correct-use-of-a-release-sprint

http://www.infoq.com/news/2009/12/stabilization-sprints
http://www.infoq.com/news/2008/02/done-shippable-quality

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.

Integration

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.

P.S.
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

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

Mike Cohn on user story writing

http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template

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

Scrum READY state ?

Recently, in a post on the extreemprogramming-it list I read a post quoting the following two links

  1. http://blog.xebia.com/2009/06/19/the-definition-of-ready/
  2. http://blog.xebia.com/2009/07/04/flow-to-ready-iterate-to-done/

They introduce an interesting concept in scrum development which has to do with the interaction between the product owner and the development team: the READY status.

In the first article, READY is defined as follows:

READY is defined by the Definition of READY. It is similar to the Definition of DONE, but with the following differences. Whereas with the Definition of DONE the “supplier” is the Team and the “client” is the Product Owner, it’s the other way around with the Definition of READY: the Team is the “client” and the Product Owner is the “supplier”. Even though I will detail the Definition of READY later, in the end it boils down to one statement: READY is when the team says: “Ah, we get it”.

I thought about it a little bit and I have to say it does not convince me. The first thing that makes me hesitant to buy into it is that it introduces a sort of phase.

In explaining the use of this state, the author says:

In a self-organizing team setting a clear destination it very important: self-organization does not exist if you have nothing to organize TO. The READY state prevents team thrashing by ensuring that the preconditions for a good Sprint execution have been met.

And of course this is a very good proposition. But is a READY state really necessary in order to achieve that goal? What if for the most different reasons it is difficult to reach that kind of READY state. And why we exclude in principle that instead a team should self-organize to even overcome a lack of READYness?
One of the agile practices I like is that you want to spend your precious time on things that have enough value. This also means that you can accept a level of un-READYness under certain circumstances. For example, you do not necessarily need all user stories to be completely ready when you do release or iteration planning. The goal is first to identify what can fit a release or an iteration and only when a user story has enough value make sure that all aspects are covered, that the US is of the right size to fit the iteration, that the implementation strategy is define and maybe the tasks identified.

I also do not quite like the fact that the READY status remarks slight separation between the product owner and the team, while instead I like more to think about the PO is part of the team. The team works together also to make sure the user stories are ready and it is not a precondition to start a sprint. The last thing you probably want if you are doing scrum is that the teams are waiting on a precondition to be triggered in order to produce value, exactly like if a developer should wait to start development until an architect has done the design.

July 15, 2009 Posted by | Agile, SCRUM | Leave a comment

Facing reality

I’ve been asking myself what’s the biggest and hardest challenge in embracing agile development. There are a lot of factors in play and it is not easy to clearly see what gives us the biggest pain. There have been also different phases in our way of adopting scrum, each with its challenges.

The human factor is surely one of the most interesting challenge because there is no way to foresee how people will react to the introduction of a development process that asks them to self-organize and make the team’s goals their own goals.

The practices their-self are challenging as well. You get lost very easily when you do a lot of changes at the same time. This is particularly true when you are experimenting yourself all those changes, because maybe you do not have the luxury of a budget for someone that can help you. In any way, I strongly believe there are things you have to learn in the hard way, no help other than your experience can show you the way.

Legacy code is another big obstacle in the way of being more agile. You would like to do more, be able to confidently change things; instead, you often fall in the chicken-and-egg problem that becoming able to do so means to spend time to refactor a big chunk of code. Since it is expensive, you do not start, piling technical debts over technical debts.

But the most challenging experience of embracing scrum is facing the reality. The essence of scrum is very simple: you have a check point of all your work, assumptions, plans, in a very short time-frame. This is terrific, because you know almost immediately how you are doing. But the reality can be something you and your stakeholders are not ready or willing to know.
When you do a long term plan, you keep the hope your plan is good until very close to the end. Since the deadline is far away, you keep the feeling that somehow you can catch up. There is usually not any real and concrete reason for that to happen, but you still believe it. The scope won’t be significantly reduced until the end, the resources will be the same for duration of the project, customers will keep bugging you with bugs and requests, you will keep read tons of emails per day. But still, you believe you can make it. There is something in the back of your brain that tells you “we cannot make it, we cannot make it…”. But you don’t hear it, and you keep believing something magic will happen.

Do not get me wrong, this is done all in good faith. The best product owners are the ones that see possible what everyone else considers impossible. This makes them more reluctant to consider that a plan is not achievable. They want the teams to have a “yes, we can!” attitude and they do not want to hear “sorry, this plan is not doable”. On the other side, the teams want to make their product owner happy, therefore tend to say “let’s try and see”.

I observed a very interesting phenomenon when we switched to two week iterations. Most teams over-committed so that after one week most of the stories were still not done. Asking the teams if the commitment were still confirmed, they were still confident they could complete all the stories. I was becoming every day most worried and the teams kept being confident they could do all the USs until the very last day. There was not any real reason to this to happen… but still the teams were confident. Do not get me wrong, I appreciated a lot the teams attitude of trying to keep the commitments to what they promised to deliver, but the result was that their goals have been constantly not met and the stakeholders have been seeing the teams constantly fail on their commitments. This resulted in unpredictable velocity and in the teams and stakeholders constantly frustrated by the missed goals.

But scrum asks you to do something different: to look at your self, at your teams, at your stakeholders and do not lie. Scrums allows you to achieve your goals because you first of all have to face the reality. The reality of your team, of your resources, of your possibilities, of your knowledge. Only if you accept this challenge and you accept you have to make a plan that works given your real conditions you will be able to see your progress iteration after iteration. Only in this way you can see your weaknesses and work around them in the meantime you work to fix them.
However, sometimes this is not easy to accept. You may be frustrated and wish you have a different team, different deadlines and a different budget. You will be tempted to point your finger to scrum just because it opens your eyes.
But if you resist to that temptation and start to accept reality, you will have the great opportunity to fix what’s wrong and therefore to constantly improve. End eventually, you will be surprised to meet unhoped results.

I believe there are two factors that allow a development team to face reality:

1. Trust each other. The development team shall always keep in mind that what the PO is asking is what will make the product a successful product. POs shall always keep in mind that the development team wants to build a successful product and put all its best efforts to make it happen.

2. The development team needs to gain the confidence of saying, without illusions, what’s achievable. The team needs to learn to say ‘NO’. Plus, the development team must learn to provide alternatives. Firm ‘NO’ must be exceptional. Most of the times a ‘NO’ should be accompanied but alternative options.

What I often tell my team is that we can accept we do mistakes because nobody is perfect. What we cannot afford and to not improve. Facing reality is a precondition to improve a team.

July 5, 2009 Posted by | Agile, Funambol, SCRUM, Software development, Software engineering | Leave a comment