My photo

18 Aug

Sunil Mundra

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?

Be Like Salt

5 Feb

Be Like Salt (published on ThoughtWorks’ website).

Having worked on consulting engagements for a fair amount of time, I have realized that consulting is both a science and an art. The science lies in the domain knowledge or the ‘hard’ skills. In my case, it is currently Agile and Lean. The art aspect relates to the ‘soft’ skills, which in my view, are as critical as the hard skills for the success of any consulting engagement.

The art of consulting, like any other art form, gets better with practice. A successful consultant is often adept at both skill sets. It is therefore no surprise that experienced consultants are highly valued. This art, like innovation, is something which everyone talks about, but very few seem to have an intuitive grasp.

Be Like Salt

Here’s a simple metaphor that I have used over a number of years of practicing this arcane art. My point – think of consulting like salt.

You may be wondering what salt has got to do with consulting. Let me explain. I believe that characteristics of salt can be mapped to consulting skills directly.

  • By itself, salt is of hardly any use

The real value of salt lies in adding it to food to enhance its flavour. Similarly, a consultant cannot add much value by working in isolation. A consultant needs to work closely with the concerned stakeholders and win their trust quickly, in order to not only understand the context, but also to get a buy-in to the recommendations he/she would like to make.

  • Salt is not visible, but its presence is always felt

Similarly, a consultant, especially on Coaching and Enablement type of engagements, should let the teams own and drive the implementation of the recommendations as soon as possible. The consultant should be available at all times to the team, but he/she should resist the temptation of doing things himself/herself and ‘being in your face’ at all times.

  • No salt or very little salt will leave the food insipid or inedible

Not focusing adequately on the areas to be impacted and/or not getting under the skin of the core issues will result in consulting not being impactful at all, or not being impactful enough. On the other hand, if the consultant focuses on too many areas, he/she may risk spreading too thin, making only a diluted impact.

  • Too much salt will also leave the food inedible

A consultant should strike the right balance between advising and letting the team discover for themselves, between showing how to do it and letting the team do it themselves, and on occasions, even fail a bit. The goal of a consultant should be to make the team self-reliant, and thereby making himself/herself redundant as quickly as possible after the engagement objectives are achieved.

  • Salt cannot be added to everything, e.g. dessert

Similarly, a consultant should know which areas to stay away from. This could be due to lack of expertise in a given area and calling that out candidly, inadequate appetite for change at that moment, something not being high priority at that moment etc. A consultant also needs to keep in mind that not every battle is worth fighting for, at a given point in time.

The points I’ve mentioned above have worked well for me in most situations. However, by no means am I implying that one should operate in this way at all times. There are times when I’ve changed my consulting approach, based on my assessment of the situation. At the end of all this, if you ask me what the best approach is to your situation, I may just give you the most cliched consulting advice there is – “it depends…” 🙂

Distributed Development Enablers – Part 3

5 Feb

In the previous posts, we have examined People Enablers and Process Enablers, which can help in alleviating challenges of Distributed Development. In this post, the final one, let us look at Tools and Infrastructure related enablers.

 

  • Electronic Story Wall

A key challenge faced in a distributed working environment is ensuring that regardless of the location, everyone should have a common view of story wall, team metrics and so on. This can be best achieved through having an electronic story wall, which becomes the ‘single source of truth’ for all team members across various locations.

An electronic story wall can be a huge enabler in terms of bringing in shared understanding of iteration progress, blockers and dependencies. It can also help is ensuring that duplication or work is avoided.

The ‘real time’ nature of an electronic wall helps in avoiding communication overheads and constant transparency helps a great deal in building trust as well. This applies not only to the development team, but also to client and business, if the electronic wall is shared with them.

A criticism leveled against electronic walls is that these do not ‘throw information in the face’, like physical walls do. There is definitely some merit in this assertion, as the benefits of ‘information staring in the face’ at all times are immense. However, this limitation of the electronic wall can be overcome by either maintaining a physical wall, in addition to the electronic wall, or even better, by projecting the electronic wall in the area where the team is sitting. In case the team decides to maintain a physical wall as well, it is imperative that utmost discipline is required to ensure that the physical and electronic walls remain in sync at all times.

Regardless of whether a team is distributed or not, and electronic wall helps immensely in generating metrics accurately, with minimal effort.

 

  • Electronic Build Radiator

Similar to electronic story walls, the benefits of knowing the build status on a real time basis are immense. In fact, knowing whether build is broken prior to checking in code is almost a hygiene factor, which can save the team from a lot of rework.

Knowing when the build is broken not only can prevent check-ins in the broken state, but can galvanize the team to resolve the issue together, should someone be struggling with fixing the broken build.

A build monitor also helps in ensuring that teams do not ‘pass on the baton’ to another location when the build is in broken state.

 

  • Communication and Collaboration Tools

The most difficult and persisting challenge in distributed development is the barriers encountered in communication and collaboration between people across locations. While nothing can be more ideal than having face-to-face conversations, both individually and as a team, constraints in doing this is a major limitation of distributed working. Inability to communicate and collaborate face-to-face not only not only creates huge strain on team members, but also has potential for serious consequences like trust deficit.

Hence, it is imperative that distributed teams are provided with appropriate tools for communication and collaboration, with the aim of getting as close as possible to being face-to-face. These tools should facilitate both individual as well as group level communication and collaboration and should allow for as much online communication as possible. Moreover, to the extent possible, tools should aid video based communication, as seeing a person, even if it is via video, greatly enhances the quality of communication.

Examples of such tools include GTalk or Lync for point-to-point communication between individuals, Campfire for conversations at team level, Google Hangout for team meetings, IdeaBoardz for brainstorming and retrospectives, Trello for any activity requiring collaboration etc.

Organizations need to find tools which adhere to their security policies. This can be a challenge if the teams/people in charge of security are not sensitive to the challenges faced by distributed teams. It is important to work closely with the security team to identify tools which don’t compromise security and which meet the needs of distributed teams.

Another meaningful way in which communication and collaboration challenges can be eased is by permitting team members to use their own devices, when they are outside the office, viz. at home and while traveling. The organization will need to define and implement a policy for BYOD (Bring Your Own Device), which fits within the boundaries of the organization’s security policy.

 

  • Source Control System

Distributed teams should work with a source control system which encourages trunk based development, and minimizes the need for branching. Sometimes, there is need for team members to maintain source code on their respective machines and make local commits. If this is a valid requirement for the team, the source control system should have the flexibility to support this. Given that distributed teams put together may form a large unit, the source control system should support check-ins in large numbers, without having to grapple with conflicting pieces of code or juggling multiple versions. Team members should be able to view code changes across locations quickly and give feedback, as needed, before syncing with the repository.

A source control system which has a Wiki feature can help a great deal in effective context sharing among team members.

 

  • Network Connectivity

Network connectivity and bandwidth are actually more of hygiene factors than enablers for distributed teams. Teams working across locations, especially across countries, can pose network related challenges, which may not occur if the team is co-located. It is often seen that these challenges are not proactively anticipated, and are usually dealt in firefighting mode, once they become showstoppers or serious impediments to the functioning of distributed teams. Choice of network, access rights and bandwidth should be addressed ideally before the distributed team begins functioning.

Network related issues may get magnified when 2 different organizations need to access a single server, e.g. Client and Vendor. Complexities arising out of this scenario must be anticipated and dealt with in advance, to ensure smooth functioning of teams.

An important aspect which comes into play for distributed teams is security of the network. This aspect also should be dealt with proactively, as security lapses on the network can lead to devastating consequences.

To summarize, distributed development does create additional challenges, but with appropriate enablers, these can overcome quite effectively.

Please share enablers that have benefited your distributed teams.

 

 

 

 

 

 

 

 

My interview in IT-Online

13 Jan

http://it-online.co.za/2014/12/09/fostering-agility-reap-immediate-benefits/

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 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.