Towards an evolutionary design by Venkat Subramaniam

Recently I attended Venkat's seminar on "Towards evolutionary design". Thanks to ASCI and Binary Essentials for sponsoring this event. The event was a huge success and a lot of people attended the event inspite of heavy rains.

Image copyright

Venkat, is a proven software architect and an Agile expert. One can easily feel the passion when he speaks about the evolutionary design and architecture. Here is the summary of key points that I learnt from the seminar

1. Design can be of two types, strategic (high level design, modeling, etc) and tactical design (TDD, Refactoring, etc)

2. He recommended the audience to read the two good articles, "Who needs an architect" and "Is design dead ?" both by Martin Fowler. Another good book he recommended us to read was the Humane Interface by Jef Raskin

4. He explained Kent Beck's Triangulation concept very well. He mentioned that frameworks should be selected based on the need rather than emotions, and he wanted the development team to avoid "Resume Driven Development(RDD)" :-)

5. He encouraged the architect to apply the "Tracer bullet" concepts while architecting solutions. That is, create a prototype first and use this as the tracer to create a robust architecture.

There were many more take aways from this seminar and I would let his presentation speak about the rest.

The Agile Zone - Papers

I found this web site  The Agile Zone - Papers  with interesting papers, articles and presentations on (or related to) Agile Software Development.   The site lists the articles/white papers alphabetically. 

Technorati Tags: Agile resources,presentations,articles

Summary of Slack

I have been reading slack and also making notes of key points from the book. I always wanted to share the summary of the book on this blog, and incidentally I found that somebody has already done this. Thought would the share the summary here without reinventing the wheel.

You can also read the following summary here written by the author

* In our constant quest to make our organizations more efficient (reduction of overhead, standardization of processes, overworking management and resources), we have actually made them less effective. The solution lies in (re)introducing `slack'. Slack is the lubricant required to effect change, it is the degree of freedom that enables reinvention and true effectiveness.
* Multitasking and overtime, thought to be ways of getting the most out of the teams, are actually having a negative impact on productivity. Multitasking, specifically for knowledge workers, causes at least a 15% penalty in productivity. It is much higher for tasks (such as troubleshooting or design for instance) that require complete immersion before the resource can actually make progress. Systematic overtime is also proven to be an ineffective way of improving project cycle-time. While it may provide short term gains, the demands it puts on resources quickly reduces their productivity and effectiveness. An alternative to systematic overtime are well calculated and well timed sprints (focused and value-added, yet handled as exceptions).
* Overworked managers also have a very negative impact on organizational effectiveness. It is indeed managers, and more specifically middle managers, that can the most effectively champion and effect change in organizations. The more overworked they are, the less time they have to reinvent the ways of working. Those same middle managers will be most effective in bringing about positive changes if they can collaborate with each other, which in turns requires that organizations stop fostering destructive internal competition.
* Prescriptive processes, pushed top-down, are a form of disempowerment. They are a result of fearful management that is allergic to failure. These processes succeed in dictate every aspect of how you should do you work but fail in providing guidance in doing the `hard parts'. They are often heavy and form an armor that reduces the mobility and agility of teams, hence resulting in less competitive organizations. The solution is to put the ownership of processes between the hands of those who do the work.
* An effective change manager is a person that can remonstrate, repeat, correct, encourage, cajole, motivate, and has great powers of persuasion. He/she is less of a boss and more of a negotiator. Great change managers have a lot of markers to call in. Markers come from favors done and confidence earned in the past. They have built a reservoir of trust and tap into it to entice their people to embrace change. Change managers have to come from within the organization, a stranger has no markers to call in, just a little `honeymoon capital'.
* The best time to introduce change is in a period of growth. Decline causes anxiety and makes people more resistant to change.

Human angle in Software development

No matter what methods(Agile, traditional, Evo, FDD, RUP, etc) that is applied for software development, the only thing that decides the fate of the project is people.

There are many traditional projects that have been delivered successfully, and Agile projects that have failed miserably. The success or failure of projects doesn't depend on the process or framework that is being used.
According to me, it all depends on the people who are planning ,executing and maintaining the project. When I say people, it need not be the poor software developers, it could be PMs, customers themselves, marketing/sales people, finance team, etc.

The project's fate gets decided right from the time the marketing/sales person starts selling the skills/services to the prospective customer. I have seen many instances where the marketing/sales team over commit with the customers for the sake of winning the project. Ultimately when the actual work reaches the architects/project managers/developers, there will be little room left to make any changes. In most of the projects, the timeline is fixed, the only thing that is allowed to be flexible would be resources(a few lucky ones).

Even after so much of campaign happening around software process improvement, the project stakeholders add/remove people to the projects based on simple arithmetic. They don't look at software developers as humans but instead like chairs/tables/"things" that can be replaced and used right from the time it is purchased.

Here is an example and explanation of the above paragraph:

Let us say it takes 400 person days worth of effort to implement a feature . Naturally the stakeholders will calculate and say that if 20 people work on this feature for the next 20 days this work could be completed.

There is no flaw in the above calculation. However, the stakeholders never even think of buffers due to attrition or addition. What I am trying to say is, let us say the above team of 20 people start working on the project and they have completed 10 days (i.e. 20 P * 10 D = 300 PD complete). Let us say, the 11th day a team member quits the project. Consider the best case scenario where they found a new replacement person the same day.

My question is,

Even after finding the replacement the same day, what are the chances of completing the project as scheduled within the remaining next 10 days ?

According to me, the delay would be more than 5 days. Reason being, when a new person is introduced into any project, it not only takes some effort to psychologically adjust to new team but also takes effort in understanding the work. Unfortunately, in most of the cases I have seen the stakeholders don't consider the human angle and still push people to complete the work as planned because the new replacement was found the same day !!. This push in turn leads to reduced thinking due to time line pressure and ultimately reducing the quality of the work.

In Slack, Tom Demarco puts this process of replacement as "personnel turnover". As per research, the effort and the cost associated with personnel turnover could be as big as 25% of overall project effort. The cost may not be visible directly but it gets incurred due to delivery delay, training new personnel and defects fixing.

Until human angle is not given at most importance in any project, the project will go through turmoil no matter what method they follow !!