Agile Way of Delivery

There is a one apple tree in your back yard. Of course, you like apples, so you take care of the tree very diligently throughout the year. You irrigate it regularly; spray insecticides and pesticides to protect it from menacing insects and pests throughout the year.  You also provide fertilizer to the tree. In short you invest your time, money and mental space in the hope of plucking some sweet apples during spring.

Now consider two different scenarios. In the first scenario, you check on your tree every morning.  You   watch the blooming flowers and their getting transformed into tiny green fruits. Slowly these apples get bigger and ripe. You see the value is getting delivered incrementally.

In the second scenario, even the tree is invisible forget about the flowers and the fruits. But you are assured by some divine power that on 3^rd week of spring, the tree will become visible loaded with lots of sweet apples. In anticipation of those sweet apples, you keep on taking care of that invisible tree for the whole year.

I don’t think you will like the idea of the invisible tree. Why? Because, you are not sure that value will be delivered on a particular day, you cannot check whether the tree needs any trimming or some other extra care. You are not getting value incrementally and can’t correct the course.

Aha! I can relate this to the Agile Way of Delivery. In agile way of delivery, you get several chances to correct the course, because you have short feedback loops. Also value gets delivered incrementally which keep on justifying the investment and allows the sponsors to change the investment patterns if required.

Agile Way of Criticism

Let’s consider two big parliamentary democracies – India and Germany. In both cases chief executive of country is the Prime Minister. In Germany that person is called the Chancellor.

For a moment presume that the Indian prime minister loses his majority in the parliament.  He can be removed by passing a no-confidence motion. Country can be thrown into limbo and may result in a costly and lengthy process of general elections even if they’d had one before. What a tragedy!

Now jump to Germany. Opposition does not like the current Chancellor and would like to remove her. Can the opposition move a no-confidence motion? The answer is No. In a no-confidence motion, the opposition must also propose a new Chancellor’s name. No chaos but a positive no-confidence motion!

Enough politics! Now let’s come back to the software industry. How many times you have faced criticism of your work – code, architecture, documentation, or any other artifact without suggestion of alternatives. Do you criticize the work of others and but also suggest alternative way of doing the same? If your answer is YES, then you are following the Agile Way of criticism.

Obesity Matrix

Obesity matrix is used to find reasoning in architectural decisions.  This matrix is a set of one table and a two dimensional matrix.  Obesity matrix should be prepared for two scenarios:

1.       To choose one or more architectural option/s to implement a feature

2.       To visualize architectural decisions across product’s features

Case 1: To choose one or more architectural option/s to implement a feature

To create Obesity matrix, you will be listing technical options to achieve the feature and their consequences in a table similar to following:

#	Feature	Technical Options	Consequences
1	Self-serving customer management but if required support personnel should be able to intervene.
1.1		Implement as one enterprise service	1.    One big  complex service 2.    Performance may be better because of absence of multiple layers of indirection 3.    Difficult to maintain
1.2		Implement as two services – one for customer and another  for customer support personnel	1.    Clear cut separation of code on the basis of who is accessing the service 2.    Duplicate code between services
1.3		Implement as not only vertical slices (user and support personnel) but also in horizontal slices (common layers serving both user and support personnel slices)	1.    Highest level of separation and possible reusability 2.    Performance might be a hit due to two horizontal layers.
1.4		Use off the shelf identity management system	1.    Requires upfront money to purchase (do we have any open source option?). 2.    Need to evaluate multiple options 3.    May reduce maintenance cost in terms of man power but consider licensing fees.

This table lists technical options available for one of the feature of RentOMusic application. Though technical options list is not comprehensive but it gives an idea.

The next step is to layout these options in a 3x3 grid. The X-axis represents cost of maintenance and Y-axis is about cost of current development.  Since in agile, difference in development and maintenance blurs, so cost of maintenance also incorporate updation in existing feature during active development phase as well as impact on other features as they get developed. The cost should be estimated in terms of time required and skill set availability within team.

The matrix has three types of blocks:

F:  Fat – High to medium cost of current development and cost of maintenance.  These blocks must be avoided otherwise it team will bleed in medium to long term.  Product will be obese and will lose agility to change previous architectural decisions as time pass by.

M: Muscle – Low cost of current development and cost of maintenance. You must strive to bring architectural decisions in these blocks. Product will gain architectural resilience and cost of changing architectural decisions will not be high. Resultant product will be lean and muscular in architectural and design sense.

?:  Dilemma –  Here context plays important role. If team is making a decision which falls in one of these blocks, team must have very good reason to justify the choice.

Following matrix represent technical options and their location in Obesity Matrix for customer management feature for RentOMusic application:

In above example, might choose “1.3: Implement as not only vertical slices (user and support personnel) but also in horizontal slices (common layers serving both user and support personnel slices)” because of initial investment required.  Choice 1.3 is falling under dilemma blocks.

Case 2: To visualize architectural decisions across product’s features

This matrix is for documentation purpose.  This matrix is consolidation of decisions made for individual features.

This matrix is 3x3 grid. The X-axis represents cost of maintenance and Y-axis is about cost of current development.