Tag Archives: Agile Coaching

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?

Advertisements

Distributed Development Enablers-Part 2

18 Nov

In the previous post, we examined People related enablers. In this post, let us look at Process related enablers.

  • Co-Located Meetings
  • Inception/Project Kick off Workshop

The importance of Inception workshop, though held perhaps only once in the lifecycle of the project, cannot be overemphasized as some of the key decisions which impact almost all aspect of the project are made in this meeting. These include business and technical scope, key project drivers such as time to market, cost, quality and so on. Moreover, arriving at a common understanding related to business vision, as-is and to-be processes, end user journeys, risks, dependencies, and assumptions also happens in this workshop, which is spread over multiple weeks. Not to be forgotten is the fact that relationships between stakeholders are cemented in this period, as most stakeholders get an opportunity to spend time with each other during and after business hours.

Obviously, it may not possible for the entire team, to participate in person in this workshop due to travel and logistical constraints. The exception would be when the team is quite small, and there is adequate travel budget. Nonetheless it is absolutely critical that all roles across all locations be represented in this meeting, in order to maximize the effectiveness of meeting the key stakeholders in person. No amount of documentation can be a substitute for the richness of conversations in person, and this benefit becomes even more important when team members are distributed. The team members who have attended Inception are in a much better position to pass the context to the rest of team in the respective locations.

The option of those not attending the Inception in person, participating in this meeting through Video Conferencing should be seriously explored. The time and effort invested towards this is bound to pay off big time.

Should the project span multiple releases, the option of those who have not attended the Inception Workshop going for Release Planning meetings should also be considered.

Inception Workshop turns a Group into a Team. This fact should be leveraged to the maximum possible extent, especially when team members are distributed.

  • Joint Stand-Ups

The importance of stand-ups meetings in effective working of an Agile team in undisputed. Stand-up meeting provides an opportunity for the entire team to get together and focus on the work at hand, progress towards the goals for the iteration, and risks and blockers, if any. This practice assumes even greater importance when the team is distributed, as the need for the entire team to be aware of who is doing what work, dependencies and blockers, if any, is critical.

Given this fact, the team has to strive to do standup meetings which include all members of the team. This can be quite challenging if the time difference between the locations of the team members is big. This is one of the main reasons to ensure overlap working time between the locations.

As far as possible, video based tools should be used for the joint stand ups. Dialing in to a teleconference number will obviously be the next best option.

As in case of co-located stand-ups, the team members should be to speak with reference to the story card wall. In case of a distributed team, an electronic card wall should be used as a reference, as it is the single source of truth for the entire team. Electronic story card wall is particularly useful in cases where team members are dialing in to the stand ups from their homes.

  • Joint Retrospectives

Just like stand-ups, the importance of this practice is heightened when the team is distributed. For things that have not gone well, it is very easy to fall in the trap of blaming the team members who are not part of the retrospective, if the retrospective is not held in a joint manner. Even a single instance of this has potential to cause serious dent to the trust between teams.

Given that the entire team is not in one location and consequently the nature of communication being complex,, the team needs to provide adequate time for the meeting. The complexity arises due to all team members being required to vote on action items, maintaining anonymity during ‘safety check’ etc.Strong facilitation skills are also called for due to the above mentioned reason.

A tool which helps in radiating information real time and which acts as the ‘single source of truth’ is a must for retrospectives of distributed teams. There are several tools available which serves these purposes, and many of them are free for use. E.g. Ideaboardz, Scrumble etc.

  • Periodic ‘Dev’ Showcases

By definition, a Showcase is supposed to be done at the end of iteration to demonstrate working software to the Business stakeholders. A practice which helps distributed teams to reduce unpleasant surprises and to build trust and confidence is for the teams to showcase their work in progress to those who are distributed, without waiting for the end of the iteration. It can be done on completion of each story, but it need not always be that way. Even showcasing code and interfaces through use of mocks, if necessary, adds a lot of value to the entire team. These Showcase meetings can be kept short and crisp and once the teams get into the cadence of doing these on a regular basis, the time taken for these will be minimal and non-disruptive.

This practice is particularly useful when iteration length is 2 weeks or longer. And it improves the predictability of iteration end demos.

  • Maximize Overlap Hours

One of the biggest challenges for distributed teams is maximizing overlap hours across locations. The challenge is accentuated when time zone differences are significant, like between India and US West Coast, and also when onshore team members ‘push’ their offshore counterparts to adhere to what is convenient for them.

It is critical that everyone, regardless of location, is ready to demonstrate flexibility towards maximizing overlap in working hours. The advantages of synchronous communication while being at work far outweigh the compromises, within reasonable limits, which team members would need to make. The goal obviously should be to maximize overlap with a bit of sacrifice and compromise by each team member. Teams can come up with creative ways to do so-some team members, by rotation, coming early / going late, teams across locations taking turns to come early / go late, being flexible about taking calls from home etc.

Not only does maximizing overlap hours help towards improving communication and collaboration, but the willingness to compromise and be adaptable helps tremendously in creating the ‘one team’ feeling.

In the next, and last, post in this series, we will examine Tools & Infrastructure related enablers.

Distributed Development Challenges – Part 2

29 Oct

In my previous post, we examined five challenges in Distributed Development.   Let us look at five more challenges in this post.

1.     Lack of Cultural Sensitivity

Distributed Development often involves teams spread across nations and continents. As we all know, cultures vary widely across the globe and ignorance of culture can lead to even an innocuous gesture, or lack of it, ill feelings among people.

 

An example will illustrate the point. People in countries like USA and UK are very conscious about maintaining a certain physical distance between people. Violation of this distance makes them distinctly uncomfortable. An apology/’excuse me’ is always given and expected for any accidental touch, regardless of who caused it, and not doing so is considered rude. On the other hand, in countries like Brazil, China and India, people, especially of the same gender, are simply indifferent to the distance maintained between them, as well as to accidental touches, thereby not offering any reaction when it happens. I have come across multiple instances of misunderstandings between people, due to lack of appreciation and understanding of cultural differences like these.

 

2.     Lack of ‘Big Picture’ View

This challenge typically occurs when the Product Owner and Business Analyst are in a remote location. While they may conduct a ‘big bang’ session to provide the big picture view, their conversations around the big picture may get ignored, and the most of the team members might just get to see limited pieces of the puzzle. The problem aggravates when a team might be doing the work as directed by the team at a remote location.

3.     Lack of Visibility

Working from a remote location, it is quite difficult to get good visibility of work happening in other locations, as radiation of information across locations is a huge challenge. This can lead to ‘multiple sources of truth’, which can result in a lot of misunderstandings and unpleasant surprises.

4.     Lack of Collective Code Ownership

Collective code ownership means no single member of the team owns a piece of code – rather the entire team does. This means the code is up for refactoring to all team members.  Implementing this in a distributed environment poses 2 major challenges First, .unless appropriate tools and Version Control System is used, maintaining collective code ownership can be challenge across locations. Second, lack of trust between team members can lead to a highly negative consequence, viz. no code ownership by anyone in the team.

5.     Risk of unpleasant surprises when ‘Everything Comes Together’

When multiple locations are producing work which needs to come together at some point, there is a huge risk of things falling apart, unless Continuous Integration is practiced rigorously. Inconsistencies between locations in types of tools used, an unsuitable Version Control system and lack of common quality standards can become major impediments towards achieving integration which is surprise free.

 

Reading all the above, it might appear that Distributed Development is doomed for failure. However, many organizations have worked towards implementing measures which significantly help in overcoming these challenges, if not fully eliminate them. I am going to share these best practices in my subsequent posts.

 

 

 

 

 

 

 

 

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.

Stand Up Meeting Anti Patterns

21 Oct

Stand Up Meeting Anti Patterns