Showing posts with label large team. Show all posts
Showing posts with label large team. Show all posts

Monday, April 1, 2013

fire prevention and firefighting




Moving around large Agile projects, I came across a common situation that hinders the team performance.  Individuals cannot allocate time for improving their work (and avoid future problems) because they are constantly firefighting current issues.

It typically happens like this: Someday on the past, the problem has started. Unfortunately, the issue (small at the time) was not clearly identified. It only got enough attention when it was on fire. Therefore the vicious cycle:


Everyone is busy putting out fires -> no time to improve (and avoid future fires) -> more fires


It takes discipline! Finding the balance between fire prevention and firefighting is not easy. You still need the fire sirens. But some experienced firefighters should be out of the fire department before the fire siren alert. Think preventive and proactively!

Friday, July 17, 2009

CI, structural changes and merges

Be mindful of the amount of structural changes while in the period that will require more code merge effort.
This was the message I sent to the programmers on a large agile team I have been working with.

Scaling agile has a few caveats to it. This blog post is an awareness message for programmer, which I believe to be complementary to the Continuous Integration practice for large teams.

Below is the message sent to the large Agile team.

We are a large team (+120 programmers: devs and QAs)

Programmers are coding everyday; despite of release candidates and regression periods. How is it possible?

We branch (prior to a new release), then we merge back (after it has been released); all the time ( release branch strategy )…

Consider the following simplified example of a Release formed by 2 dev iterations and 1 regression iteration.

Sample Project Release and Iteration plan

Dev activity –-It1—It2—It3—It4—It5—It6—It7—It8—It9--ItN--
Regression –------------Reg 1----Reg2-----Reg3—-------------
Release sch –------------------Rel1-----Rel2—---Rel3----------


So let’s look at different moments in time:

It2:
Dev activity –-It1—It2
Regression –----------
Release sch –---------

All programmers are working in the main trunk. Any regression activity is happening in the main trunk. There is no release yet. The release candidate is the main trunk itself.


It3:
Dev activity –-It1—It2—It3
Regression –-----------Reg 1
Release sch –-----------------

The release is formed by two dev iteration and one regression iteration.
In this case, the work done for Rel1 is related to It1 , It2, and Reg1; but should not be impacted by It3 development. Therefore the need to branch out the codebase: main trunk, and R1 branch.

Humm… if there is a branch, there will be a merge later: structural changes will have to be merged back!

It4:
Dev activity –-It1—It2—It3—It4
Regression –------------Reg 1----
Release sch –-----------------Rel1

R1 has been released. The code is merged back to the main trunk. The R1 branch now should have very little activity (production support only), therefore it should not create any difficult merge.
Programmers are mainly working in the main trunk; no merge required (remember, we do Continuous Integration!). Go crazy, do the structural changes that you feel are amazing (btw, if it is not, CI will catch it).

It5:
Dev activity –-It1—It2—It3—It4—It5
Regression –------------Reg 1----Reg2
Release sch –-----------------Rel1-----

The development period for R2 is over (It 3 and It 4). The regression work should not be impacted by the development work from It5. A branch for R2 has been created. If there is a branch, the code will have to be merged later on… Please be mindful of structural changes as you will have to merge them.

Have you noticed the pattern?

In the sample presented above:
It 2, it4, It6 development is happening in the main trunk which won’t require large amount of merges later on.

It 3, it5, It7 development is happening in the main trunk, but there is lots of development happening for a release, and those will have to be merged back in the next Iteration.

So if you have a big restructure to be done; should you do it in It7 or It8? (Remember, there is no free lunch, you will have to merge it back!)