Agile and an Undivided Hindu Family

Another one that stems from the Agile delivery is something that I have closely seen, an undivided Hindu family, essentially a large family which grows as people in the family expand by marrying or having children but live in the same house.

Let me explain what happens in a large undivided family, the home they live-in will be a traditionally owned large house having the ability to expand to support additions. Any new additions are only a matter of extension of a room rather than buying a new one. The roles people play within a family are very well organized and in fact self organized. There is no clear roles and responsibility but everyone put their hands together to get the job done. In fact, sometimes skills are cross learnt to support lean times. But the beauty is that they all savour dinner or lunch or breakfast with complete enjoyment. These are the short term milestones that brings back the entire family together to talk about long term and short term impediments to resolve. The advantage of such a family is that the family addition which normally needs a lot of planning is actually a common and welcome change. This change is managed very effectively with open arms.

In an agile team the same is expected. There is a constant infrastructure in CI, Test Framework and teams are expected to work in a way that they organize by skills and work as a team to commit to the goal. Frequent demos are the frequent savouries that the team take pride showcasing and enjoying. Any change in the scope is taken very openly and managed very well through self organization and minor tweaks to CI and test framework.

I will come back with more of the moving train and the Hindu undivided family metaphors shorlty. However, I saw a comment by an anonymous person in Dave's blog (I should declare that I am a follower of his blog) about agile leaving the long term picture outside of focus and worrying about only the short term ones and treating software work as a mundane brickwork - Software Results: Agile is Fragile. I will take liberty to extend Dave's answer. This is a problem I have encountered as well. Are we working on a technically complex piece which is not 'Agileable' is a common question I asked myself and so did my folks. But the key is how well are the User Stories are broken to provide incremental value is a challenge in those cases and that needs maturity in requirement articulation. The key principle in agile is the acceptance of the fact that the "soft" nature of software makes it difficult to predict what may have to be built irrespective of how much the requirment is engineered and hence it is the focus on the need of the hour that make the value more effective rather than a software which can handle the future while being late for supporting the need of the hour. However, if the value of a small increment is seen as only a stepping stone and no value can be derived with that work, you need to relook at how you are breaking the solution. One key value could be that it helps arituclate better requirement which is often not construed as a significant value but it is of big value in terms of Business-IT alignment which is one of the most difficult problems in the 'Waterfall' world. The fact that any complex problem can be split into multiple small (yet complex) solution is a realization that helps agile succeed. I guess Newton proved this to us through differential calculus, we are just going ahead with that as a basis of converting everything to a solvable sprint! Finally, It is infact agile that promotes refactoring code to help maintain code effectively with long term in mind.