Structured approach to start distributed agile project


Criteria for selection of Partner

  • Experience in running agile projects
  • Talk directly to teams executing agile projects
  • Talk to the clients that are executing agile projects with the partner

Agile Working Model

  • Involve agile coach(with distributed agile experience)
  • Take good practices from both onsite and offshore teams(code reviews, communication models,tools,….)
  • Discuss and agree the model with both teams

Recruitment of the Team

  • Recruitment should check the agile fitment
    • Skill fitment(refactoring,…..)
    • Strong concepts
    • Readiness to learn.
    • Some members in a team with domain knowledge.

Infrastructure in Place

  • Communication and collaboration tools(wikis, messaging, video conference,…)
  • Access speed to the existing  infrastructure(dev,test,…)
  • Development and Test
    • Continuous Integration(common for entire project)
    • Developer setup(tdd, static code analysis, code coverage,…)
    • Access to test infrastructure or setup of local test environments

Knowledge Transition Plan

  • Multiple models
    • Offshore team members can embed in current agile teams
    • Travel of existing projects members to offshore location on rotating basis
  • Prepare backlog items(less complex, with less dependencies, …) that the offshore team can pick up in initial sprints

Training the team

  • Technical skills – Refactoring, Test Driven Development, …
  • Specific technology/tools used in the project

Scaling the Teams

  • Start with 2-4 team and then grow after the current team stabilises
Posted in Uncategorized | Tagged , , , | Leave a comment

Is quality a pond or a flowing river across the software development organization.


Many times we notice that quality is not practically followed across the software development organization but is found in some pockets or is decorated on the walls of the company in nice fancy frames.

Quality is to be followed from team formation to delivering value to the customer. Lets look at each stage on how quality can be imbibed in all the stages of development.

Team formation –

Recruitment needs to focus on recruiting members, who would imbibe quality values in practical sense. This can be achieved by giving practical problems during interviews, which will validate their approach to solve problems and would also validate their understanding of the fundamentals, which is critical to quality.

Planning –

Business needs to invest time to infuse quality in delivering value to customers.If the management is pushing hard with deadlines all the times – the team might try cut corners. I liked the statement from spotify’s blog, which states that “We don’t deliver on date but we deliver on quality”

Rather than start developing business features from day one, Initial stories should include some of below mentioned items(as needed)

1. Development teams should be trained on skills, such as domain, engineering practices(refactoring,Test driven development,..), process, tools and any other skills required for development.  or else it will be like sprinting without wearing right shoes, and eating right diet.

2. High level architecture should be laid out.

3. Infrastructure such as continuous integration, tools for unit, functional,.. automation should be made ready during initial sprints.

4. Practices such as Acceptance test driven development(ATDD) needs to be followed during the iteration.

Development –

The team  needs to follow practices that will provide instant feedback about the quality, such as Test driven Development, peer code review, team code review, static code analysis, Continuous Integration(CI) and automated test system.

Reviews needs to be very open and directed towards the objective of delivering quality product.

As there is no end to improvement, team should think in every retrospective on ways to improve the quality. 


Shift left strategy needs to be applied for testing the sprint output as early as possible.

Look at all the testing and make sure to move to left to identify the issues early on.

For example – Team should look into moving even performance testing to start, and it does not have to be perfect from day one.


If the team does not have the skills for adopting the practices of agile, it is important to to get a hands-on coach, who can coach the team on technical practices such simple design, refactoring, TDD and also general agile practices. As this practices require attitude shift, coaching is important to adopt these practices.

Knowledge Sharing –

Team members with similar skill set(developers of specific technology, testers,…) can meet on some defined frequency to share the good practices that are used in different projects within the company.

Quality needs to be a common denominator across locations.


Metrics should be based on the customer value, how efficient are we and are we continuously improving and striving to improve.

Example – how much time it takes to get feedback from customer, product usage

what is the usage of features by customers, ROI from features being built. 

Metrics should be transparent at all levels so that same metrics is available to all members. so that teams can retrospect and strive to continuously improve.

IT , R&D, business should work together as only one section of the team cannot deliver quality.

Customer –

Quality is also providing what exactly customer wants and not to flood customer with unwanted features that we want the product to have. Customer does not care about the technology or methodology used for development, they are are interested in the end product.

Business team needs to have courage, in removing existing features from product, if they are not providing value to customers.

How much closeness is maintained with customers to understand their needs, context to provide them the solutions.

Quality needs to flow from the time members are recruited and should involved all the stakeholders that are contributing directly or indirectly in the software development process.

We have adopted agile to deliver fast but have we also adopted all the practices that needs to be taken care from quality perspective.

Quality cannot be enforced at just one step of the software development process but should be thought considering the entire flow.



Posted in Uncategorized | Leave a comment

How to adopt reuse in agile development model for reducing Time to Market



With increased competition to get the products out in the market, software development teams are all looking for ways to reduce the time to develop software.

Reuse is one of the ways that can help to reduce the time to market and increase the quality of the deliverables.

Reuse practices can be imbibed within the agile framework in various stages of the development cycle.

Let’s look at how we can avail the benefit of reuse at multiple levels in the agile software development life cycle from release planning to deployment.

Release planning
After the team get overview of the goal of the release planning and details of the user stories planned, the team can look at the internal/external assets such as reference frameworks, similar projects ,similar existing user stories that could be used for the planned user stories.

Every user story in the release plan can be updated with list of reusable assets that have been identified so that teams can discuss it during sprint planning.

For using any external asset(open source, 3rd party,..) licensing of the assets can be planned before the start of user story implementation.

Sprint planning
Team can get into details of reuse assets discussed during the release planning for the user story.Team can also discuss about the low level code reuse that could be applicable for the user story.

This activity needs to be under taken couple of weeks before starting of the sprint to make sure that we can plan about the reuse technicalities.

Stand up meeting
5 minute planning(before scrum meeting) by each team member to identify how effectively the work done by them(What i did from last scrum meeting) can be shared with the scrum team during the scrum/standup meeting will enable reuse of code, design during the sprint execution.

Sprint Execution
Before starting on any task, Team member’s should think and try to search for existing asset that will help in task implementation rather than reinventing the wheel.

Good coding practices such as using common coding guidelines, design patterns,etc w, code reviews(by pair and once a week by entire scrum team with couple of members from other teams) will also help team share the knowledge about the code and in turn spike the code reuse.

In multi scrum team setup, Demo meetings provide platform to share the work(business and technical) done by multiple teams, which is a big input for reuse activities.

In retrospective, team can reflect on how reuse of design, code and test was considered during the sprint.

Knowledge Sharing
Knowledge sharing sessions about the design, code,etc regularly by teams will help to know the right people to approach for specific assets/knowledge area.

Enable tooling to put each work product, whether they are requirements, code snippets, frameworks, requirements, test cases onto a common platform, where members could search, rate, discuss and download.

Build communities for areas such as architects, testers, development tools, practices, technologies. These community forums will help to share the assets across the projects and departments

Posted in Uncategorized | Tagged , , , , , , | 1 Comment

Agile developer day

Over 8 million developers worldwide are using agile practices for at least 50% of their projects based on Global Developer Population and Demographics Survey.

There is big shift in way of working, when you move from waterfall development to agile development. Lets look at how the agile developers spends his day.

The day of an agile developer unfolds with planning for the day, which involves recalling on whats left in the plate from last work day and planning the task(s) that can be accomplished during the day. This planning also helps to prepare the short udpate( 1. What has been accomplished from yesterday, 2. What is planned for today ,3. Any impediments) that  needs to be shared during the scrum meeting with the entire team.

Every developer needs to understand that they are the owner of the task(s) they pick and they are accountable to deliver them. They need to raise any impediment, which prevents them to complete the task. They should not wait for the next scrum meeting to talk about their impediments.

Once the developer picks up the task, he/she would use test driven development approach to write the code, continuously refactor the code to maintain the quality of code. He would have the eyes and brain of his pair to provide ideas and keep tab on quality of the code.

After the code is build successfully in local environment, the code is checked-in into the version control. Continuous Integration server is waiting for this moment and it grabs the entire code to make sure that the checked-in code does not break existing application

Continuous integration server helps to provide instant feedback on checked-in code so that we can rest assure, before leaving home that we have not broken the system and show can go on.

Agile developer's day v1

Its satisfying to see the quality product output getting unfolded with every task being completed by the scrum team members.

I have also found the pomodoro technique very useful for work to be done during the development period of the day.

Posted in Uncategorized | Tagged , , , , , | 2 Comments

Reduction of Time to Market during SDLC

Usage of agile methodology tops the chart, when discussing about reducing time to market in development process.

Of course agile methodology gives the framework for reducing time to market.

There are lots of other areas within the R&D domain that can be worked on to reduce “Time to Market” in a short and long term.

1. Reuse of Code/frameworks/tools/test cases/ etc.

  • Reuse will reduce the time to write new code/test case/ etc.
  • Reuse can be achieved in many ways – By using reuse repository for assets, knowledge sharing sessions, discussion groups, competencies, etc.

2. Automation testing (early the better)

  • It will help to reduce the time to verify the effect of the changes done to the code base.

3. Use easy to develop frameworks, language, tools

  • It’s difficult to get developers, testers with expertise in proprietary languages, tools.
  • It’s also faster to develop the code in most cases with non-proprietary frameworks, tools and languages.

4. Regular retrospective

  • Improve on continuous basis the areas that are hampering “Time to Market” and come up with new ideas to improve “Time to Market”

5. Design principles/Good coding practices – define at the start and review them on frequent basis

  • Logging, threading, etc. Its saves time by doing it right the first time. More time will be spent on fixing the code, if done after much development is done.

6. Review by experts

  • (Weekly) Frequent Review of code, design by experts to find the issues early rather than at later end of project.
  • It also helps to share the knowledge across members.

7. Acceptance test driven development

  • Acceptance test scenarios to be defined before start of the development/coding/.. This will help to reduce the defects.

8. Fast impediment solving

  • Management team needs to resolve the impediments faster to improve teams productivity

9. Cut down or eliminate Dependencies

  • Inspect all the dependencies that is causing the wait – Dependency of people, resources,
  • Easy and transparent way to log the issues, dependencies to highlight and get it resolved.

10. Better Collaboration Tools and Practices (video conference, wiki, messenger, travel across centers …)

  • Relevant for distributed R&D teams
  • Clarification with business team , other dependent teams faster – reduce the wait time and increase the clarity of understanding  the discussions

Please share what other practices worked for you in reducing time to market.

Posted in Uncategorized | Leave a comment

Integration of distributed teams

 As the companies are being acquired across geographies and companies are going global for utilizing the right talent for building products, distributed development centers are very common sight now.

Agile methodology, which started with collocated team concept, is being adapted to distributed teams. Collaboration across teams becomes most vital component to the effective working of the teams and for sharing the knowledge across the teams.

For distributed agile projects, either the distributed team is from the same company or it’s from the outsourced company.

Teams need to plan on the areas mentioned below, before and while starting the distributed projects.

  • Division of work based on technology or functional across distributed teams
  • Collaboration model, process and tools
  • Network connectivity
  • Access to similar/common Infrastructure, tools, resources across locations
  • Knowledge ramp up plan for the new locations

As there is no one size fits all solution for distributed teams, the projects are different by

  • Size
  • Complexity
  • Number of distributed centers
  • Expertise of teams across locations on the tools, technology, domain
  • Cultural diversity
  • Communication Language

I have come across teams that have started distributed development without understanding the challenges around it and then coming to conclusion that distributed models do not work. One of the biggest lacking areas is that teams don’t take steps to integrate them as one team and motivate them to work towards common goal.

Collaboration being very vital, tools and technology should be used to bridge the communication gap across centers and to bring more transparency and visibility. Apart from collaboration there needs to be frequent travel of members across locations.

Creating culture so that all teams share same values, trust each other, work towards creating high quality project and have the common goal will is important for the foundation of great distributed teams.

There needs to be continuous process of improvement in these areas to build a team that works like one team even if it’s distributed.

Posted in Uncategorized | Tagged , , | Leave a comment

Hackathon for multi team retrospective

Retrospective is one of the core concepts of agile methodologies and often one of the most neglected one not from the ritual perspective but from the effectiveness perspective and especially for distributed teams.

Retrospectives in agile is intended to help the team to reflect on the previous sprint and bring improvement to the upcoming sprint based on the wisdom generated from experiences.

Collaborative brainstorming or we can call it Hackathon could be one of the ways to generate improvement ideas/solutions for problem faced by large agile teams either collocated or distributed. It would utilize the knowledge and ideas of members across team and across locations.

This can bring innovative solutions to the table as team members from different locations, would bring diverse perspective to the issues based on their experiences and background

This would demand collaborative tools and good infrastructure for the teams to come together on a virtual platform.

Topics that need to be discussed could be released couple of days before with sufficient background about the problem for the teams to start thinking about ideas and it will give sufficient background to non-collocated teams about the problem topics. Hackathon could be limited from dedicated few hours to couple of days depending upon the team size. This process could be repeated in a frequent basis.

This is also help to increase the binding between teams and help to build the trust for members located in distributed locations.

It’s vital to create the culture of innovation so more members participate in such events, where the company is receptive to ideas from the team and implements them.

Posted in Uncategorized | Tagged , , | 4 Comments