Agile Micromanagement, the good and the bad

Jim Highsmith wrote an interesting post about micromanagement. He mentioned Steve Jobs and Bill Gates are good examples of successful product manager micromanagement. I totally agree with that.

He also talks about the Agile process micromanagement. Experiencing both worlds, waterfall and agile as a developer and a manager. I have a strong opinion about it. Agile is all about micromanaging!

Consider these:

• You are coding and someone is talking about your code as you type it (Pair programming).
• Every day you stand up and tell the whole group what you did yesterday and what you will be doing today (Daily Scrum meeting).
• You retrospect about what you did well and what you can improve on (Retrospective)
• You show everybody exactly which task you are working on and how it is progressing (Visible card wall)
• You respect work in progress limits (Kanban WIP limit)
  
• You make a code commit and let everyone know about it. (Continuous Integration)

The more I think about it, the clear it is to me: Agile is all about micromanagement. The good or bad depend on how people adopt its principles and practices. I have experienced many benefits that come from such micromanagement. In fact, when I look back at all projects I participated on, the projects I consider more successful (people enjoying working, delivered great products and improving the work process) are the ones with lots of micromanagement.

CruiseControl: the open source that changed the way we develop software

I finally uploaded the presentation for the session Luiza Pagliari and I (Paulo Caroli) gave at the FISL 2010 conference. Enjoy it!

FISL 2010: CruiseControl: the open source that changed the way we develop software

Continuous Integration and CruiseControl history

Luiza Pagliari and I, Paulo Caroli, gave a talk on the history of Continuous Integration (CI) and CruiseControl at the 2010 FISL conference (International Free Software Forum).

We talked to Martin Fowler and other colleagues at Thoughtworks and to gather (and validate) data on CI and CruiSeControl history. Below is short presentation with this data.

Continuous Integration and CruiseControl history

Please contact me if you are interested in the CI history topic and blog about it. I will add your links to this blog post.

Continuous Integration adoption path

Luiza Pagliari (my colleague at Thoughtworks Brazil) and I, Paulo caroli, will be giving a talk on the history of Continuous Integration and CruiseControl at the 2010 FISL conference (International Free Software Forum) held in Brazil.

Caio Kinzel, another colleague at Thoughtworks Brazil, have shared a blog entry with me that I find really useful. It is the Continuous Integration Maturity Model created at last year’s CITCON (Continuous Integration and Testing Conference).

My friend and co-worker Patrick Kua have presented a similar topic in the XP 2009 conference: XP2009 – Climbing the Dreyfus Ladder of Agile Practices.

I am not sure I will use these for the session to be presented at the FISL conference. But these models are definitely helpful for Agile teams to understand the Continuous Integration adoption path.

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!)