Tag Archives: Agile

The Implicit Agile Principles

23 Nov

The essence of Agile is supposed to be brought out by the Manifesto and 12 principles. However, there are few Principles which I believe are extremely critical for ‘Being Agile’, and these appear to be either unstated or implicit. Following are the ones I could think of:

  • Build Quality In

 It’s quite surprising that the word ‘Quality’ does not find a mention anywhere in the Agile Manifesto and Principles.  Better quality is perhaps one of the most underrated benefits of Agile (assuming Engineering Practices are also implemented, Practices like writing Acceptance Criteria upfront, Test Driven Development and Test Automation, combined with QA collaborating with the BA and Developers throughout the development cycle has resulted in Quality usually being a non-issue. Agile promotes the notions that Quality is the  responsibility of every single member of the team and that Quality is to be built in right from the beginning.

If the list  12 principles is to be expanded, this principle should be right at the top of the list

  • Shorten Feedback Loops

Almost all Agile Practices help in getting early and robust feedback from various dimensions:

  • Feedback from the ‘Product, through Unit Tests and Continuous Integration
  • Feedback from the Customer, through Acceptance Tests and Showcases
  • Feedback from the Team, through estimation and scheduling based on prioritization
  • Feedback within the Team, through Retrospectives
  • Feedback between the above mentioned entities

Shortening feedback loops across all entities as mentioned above helps to take corrective course of actions more quickly and effectively, and also enables a culture of Continuous Improvement

  • Fail Early, Learn Fast

A principle similar to Early Feedback, this principle too is extremely valuable for both Business and the Development Team. Businesses love Agile because they can the MVP to the market, and come to know if early if it is not going to work, thereby save on costs which they would have to spend if they had taken the ‘Big Bang’ approach. By showcasing Working Software at frequent intervals, any mismatch between expectations of the customer and what has been developed can be identified early  Engineering Practices like using Assertions in Unit Tests can help detect typo mistakes immediately, which can otherwise not only lead to, for example,  mysterious slowdowns of thee system, but also make it quite difficult to detect the defect. Given that the cost to fix a defect rises exponentially from the time the defect the defect is to introduced to when it is fixed, the ;fail fast’ principle in writing code is immensely valuable.

Agile recognized that if failure has to happen, it should happen early so that it provides an opportunity to learn/correct and, as in case of Early Feedback, adjust course more quickly.

  • Practice Brutal Transparency

Transparency is an absolute precondition for being truly Agile. Transparency helps in avoiding unpleasant surprises, mitigate risks and, most importantly, build Trust.  Transparency is about having the Courage, a core value of both Scrum and XP, to share bad news early, about acknowledging one’s limitations and asking for help, about making the work pipeline and key metrics visible through ‘single source of truth’.

This is probably the most difficult principle to follow in true spirit. However, without Transparency, chances of succeeding in implementing Agile are very bleak.

  • Accuracy over Precision

Given the nature of software development, and perhaps any other knowledge driven work, the unknowns and uncertainties between providing the estimate and delivery are far too many. The situation was very similar to days of ‘Carpet Bombing’ when technology was not advanced enough to deal with the uncertainties between the dropping the bomb and it reaching the target. Being precise about dropping the bomb on the target was not working and hence multiple bombs were dropped with the hope that at least one or some would hit the target.

The reason why Estimation and hence Planning have much more credibility is because Agile recognizes that precision is immaterial and it is accuracy that matters.  How useful it is the precise estimate that something will get done in 11.75 days, knowing very well that it is highly likely to change, or that it will take approx.. 2 weeks, for planning purposes?

Agile is helping us move away from having pointless precision to having meaningful accuracy. Hence, this principle, though explicitly unstated, is quite important.

  • Embrace Discipline

One of the stated 12 principles is ‘Build projects around motivated individuals’. There is perhaps an implicit assumption here that motivated individuals, who belong to a self-organizing team, are disciplined. In reality, this is often not the case, as the importance of discipline is not clear in the stated principles.

Agile is about team enjoying autonomy, and also about team practicing ‘brutal’ discipline. Imagine the amount of discipline which is needed to deliver working software regularly at very short intervals. Examples where discipline is always expected include the ‘ceremonies’ (stand up meeting etc.), writing unit tests, regular check-ins etc.  Discipline is an essential ingredient of a self-organizing team, which is such a critical element of Agility.

Can you suggest additions to this list?


My interview in IT-Online

13 Jan


Distributed Development Enablers-Part 1

7 Aug

Having examined the challenges of distributed development, let us look at some enablers that can help in alleviating the challenges under three broad categories – People, Process, and Tools and Infrastructure.


In this post, let us look at People related enablers.


  1. Proxy Product Owner

We all know the importance of having a Product Owner(PO) in the team. Product Owner provides business context to the team, ensures requirements prioritization and provides sign off on the developed features or stories delivered. However, in a distributed set up, it is most likely that the PO is located away from most of the team members. In this scenario creating a Proxy Product Owner role helps. Proxy Product Owner needs to be co-located with remote team(s). She needs to spend adequate time with the PO to understand the business context, the drivers for the solution and the key requirements in detail. Most important, she needs to win the trust and confidence of the PO.

The Proxy PO should be in a position to provide context and clarifications to the team, to a large extent. She will take the responsibility of being the single point of contact with the PO, and will continue to interact regularly with the PO on operational matters. While the PO may still be involved in bringing in new requirements in the backlog, making prioritization decisions in release and sprint planning meetings and signing off developed features, the Proxy PO can shadow the PO very closely in all of these and thereby, over a period of time, may play a key role in significantly reducing the dependency of the team on the PO.


An effective Proxy PO will lead to better collaboration with the business, faster decision making and an increase in end user satisfaction.


  1. Cross Pollination


A key to working effectively in a distributed environment is the level of Trust between the team members. People meeting face-to-face and spending time together is the first and most important step towards building trust. There are 2 major anti patterns, which need to be avoided:

  • Only onshore team members visiting offshore, implying that offshore teams members need not visit onshore. This is ‘one way street’ and will not bring in optimal results.

People traveling both ways, i.e. people onshore traveling offshore and vice versa is necessary for cross pollination to be effective. It gives people across locations an opportunity to understand and appreciate the context and constraints under which the distributed team members are working. Moreover, it helps in building stronger relationships among distributed teams.

The value lies in people spending time together not only in office, but also when they socialize together outside office hours. That is a huge enabler towards building trust.

  • The visits are for a very short period time, perhaps just a week. This is especially a waster when people are visiting from very different time zones-the jet lag does have a negative impact on the visit. In a week-long visit-the first day is spent in warming up and getting to know people, the next 2-3 days is when work momentum begins to gather pace, and the last day is spent on wrapping up and good byes.

Subject to visa and family constrains, the duration of visits should be anywhere between 2-4 weeks long, with preference for the longer time. Assuming that the necessary infrastructure, including communication channels are in place, the people traveling away from their home office should be able to continue their work with minimal disruption while they are on the road.

The main obstacle to people being able to travel is the travel budget constraint. Typically, leaders look at money spent on travel as an expense. In distributed development, the money spent on travel is not an expense, but an investment. This investment is necessary for people to be able to work better, in a distributed environment. And the payoff on this investment is huge.

  1. Cultural Sensitivity

When we discussed the challenges of distributed working, we examined how lack of cultural sensitivity can become a huge impediment towards people gelling together.

It is important to invest the time and effort to educate people travelling, especially for the first time, to a location which has a different culture from theirs. These orientation sessions can be done by outside experts in this area or even by those within the organization who are well travelled and have good exposure to the particular region in reference.

It also crucial to hold cultural awareness sessions in general, across locations, to orient team members about cultures in other locations. This is because culture will come into play when people communicate. E.g. many people in India nod their head in a particular way to communicate a yes, which is very different from how people nod their head in many parts of the world for the same reason. If, for an example, a team is distributed between India and USA, it is advisable to educate the people in USA about this particular aspect of way of nodding in India, and also to people in India, it is important to make them aware how this specific way of nodding can be misinterpreted as a No by people in USA.


  1. Feedback Culture

Feedback is one of the key elements of Agility, and it becomes even more important when the team members are distributed. Positive feedback to team members helps a great deal to strengthen relationships and creating a ‘one team’ feeling, while feedback on what is not working or right helps to avoid misunderstandings and resentment.

Team members should be encouraged to give feedback, both positive and otherwise, as appropriate to other team members. The timing of the feedback is critical-feedback given late can actually become counterproductive.

Here is an example of how feedback on a small but important thing helped a team. The team was distributed between USA and India, and was quite new to working in a distributed manner. During joint meetings, the team members in USA would sit at a rectangle shaped table with the telephone in the middle of the table. The team members in India would be able to hear the people who were sitting closer to the telephone but could hardly hear those who were sitting at the corners of the table. This not only impacted the effectiveness of the meetings, but also made the team members in India quite frustrated. The team members in USA were absolutely not aware of this problem, until it was pointed out to them. Once they got feedback about the issue, the team members occupying the corner slots started either walking up to get closer to the phone or moved the phone instrument closer to them when they wanted to speak.

It is important to understand possibly why the team members in India did not give the feedback to their USA colleagues, until they were prompted to do so. It could be because of the ‘onshore-offshore’ syndrome, where the offshore team members have an inferiority complex (and the onshore team members have a superiority complex). Or it could be because it did not strike them that the problem can be resolved with some very minor adjustments. Regardless of the reasons, the team was getting negatively impacted. If the problem would have continued further, it might have led to the team members in India feeling even more frustrated and also perhaps resentful towards the USA team members.


  1. Leveraging Effective Communicators

It is a fact that working in a distributed environment requires superior communication skills.. It is also a fact that not everyone in a team has the same level of proficiency in communication skills.

It is important that a team takes stock of the communication skills of all team members and ensure that team members with better communication skills lead the conversation/communication. This is particularly important when

  • Team is new to distributed way of working
  • Trust is yet to be established with team members who are not co-located
  • Something unpleasant or negative needs to be communicated


Communication, particularly verbal, is not just about fluency but also about using the right vocabulary and tone. These can become very important in situations mentioned above.


While some people have a natural flair for communication, it is not a rocket science and the skill can be developed over a period through observation, mentoring and practice. While the team members with better communication skills may take the lead for some time, they need to consciously work towards capability development of other team members.


In the next part, we will examine Process related enablers.



Where is code created?

1 Aug

Are you surprised by this question? You are thinking the answer is so obvious, isn’t it? Of course, the code is created in the computer!

Just think about it. Is the code really created in the computer? In my humble opinion, No. The code is created in the head of the developer. “What happens (while creating code) in the mind is some discovery or decision. What we do at the keyboard is turning that discovery or decision into useful form”. (credit: Paul Oldfield)

Profound, isn’t it? I cannot think of any argument against this fact.

If we accept this as a fact, several questions come to my mind:

  • Given that people are the most important ‘resource’ for software creation, why are people treated like nonliving ‘things’?
  • For something which people primarily create in their heads, why is intrinsic motivation not given the importance it deserves, and why is it (wrongly) believed that incentivizing with monetary rewards is the best way to motivate people?
  • Why are we obsessed with applying manufacturing relevant productivity measures to people? E.g. Typing code for at least 6 hours a day.
  • Why is effort spent towards communication and collaboration between team members seen as nonproductive/waste, when in effect this will actually lead to better product/solution?
  • If we take into account the collective experience of the team and the fact that all human beings are capable of thinking, why are Managers more powerful than the teams?

Answers please, anyone?

I am extremely saddened by the colossal waste and non-utilization of human brain’s potential, in the IT industry. Hope to see a revolution happening for changing this. As of now, moving to the Agile mindset is my only hope.

Distributed Development Challenges – Part 1

13 Oct

By definition, Distributed Development is difficult due to the ‘tyranny of distance’. In fact, in the early days of Agile adoption, some purists believed that Agility and Distributed Development could not co-exist, going by the principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Distributed Development is a reality today. In most cases it is a necessity due to some very convincing reasons. Despite all the technology advancements related to communication and collaboration of virtual teams, distributed development still has challenges as people are ‘not in the same room’. Let us examine five of these challenges in this post.

1. Barriers to Communication and Collaboration
Distance between teams not just inhibits face-to-face communication, but poses some additional challenges as well. If teams are working in vastly different time zones, e.g. San Francisco (US West Coast) and Pune (India), the challenge is about overlapping working hours. Either or both sides would have to start work early or end work late, and this can lead to another problem, i.e. resentment.

Another situation can be where both teams are different parts of the world, and their primary language is not the same. E.g. A team in China, whose mother language is Mandarin, while the other is in Brazil, whose mother language is Portuguese. These teams would have to use a language common to both, say English. Given that it is not the primary language of both teams, the ability to communicate clearly and crisply, and keeping an accent as neutral as possible can become quite challenging.

2. Requirements Misunderstanding
In a Distributed Development environment, it is possible that the Product Owner and sometimes even the Business Analyst are located ‘onshore’ while the rest of the team is located ‘offshore’. This can naturally lead to higher documentation for communication requirements, and clarifications over phone. This poses a huge risk of requirements being misunderstood, especially if there is no common primary language.

3. Low Morale
This is typically seen at offshore when onshore has a superiority complex. When onshore team members carry the belief that the work done by offshore team is relatively of low value as compared to their work, they seldom appreciate the team across the shore. This can lead to a feeling of being taken for granted and result in low morale.

4. Lack of Trust
Developing trust between team members is a ‘chicken and egg’ problem. When people are separated by distance, there needs to be more trust between them to work collaboratively. And trust cannot be built between people unless people connect in person and spend meaningful time together. Absence of trust leads to ‘throw over the wall’ mindset and finger pointing when things slip or fail. In this situation, there is a very high risk of negative feedback being given or taken in the wrong spirit.

5. Lack of Co-ordination
This is an important challenge when teams are distributed and have high level of dependencies between them. Imagine a day when a team in Pune(India) leaves behind a broken Build as the other team in the San Fransisco starts the workday. This will result in loss of productivity for the team in San Francicso. There would be very reason to believe that leaving for the day with a broken build was an inadvertent slip up by the India team, it could easily result in US team feeling resentment, thereby leading to other problems like increasing the trust deficit.

Agile Is Not Fragile

10 Jun

Agile Is Not Fragile

Stand Up Meeting Anti Patterns

21 Oct

Stand Up Meeting Anti Patterns