We would like to implement agile in our team but somehow integrations are depending on other teams. What’s is the best practice of making integration loose couple so that agility is possible?

Hi Sai,
To me, best practice is a "SCRUM of SCRUM". Briefly it's two teams, one is the "main team" , the other team focuses on integrations (or it could be reports, data migration, etc...) that might have a different cadence or even implementation method. There is a "Scrum of Scrum" meeting where the two projects status' are merged in a Scrum wall and the two teams "Walk the Wall". Activities and tasks with dependencies are discussed in typical Standup fashion (what was done, what is being worked on, blockers...). This is a very brief description of the method but I use it all the time on all my Agile based projects.

Regards, Art

another option would be SAFe

looks to big, but reduces the big picture on the release train topic

http://www.scaledagileframework.com/

in Jazz RTC there are build in templates for Scrum and SAFe

Not only is this a loaded question, but it is a very broad topic.  Agile is a framework, and is at the heart of many software development / delivery methodologies.  Scrum is a specific implementation of the Agile framework and is found in the IBM Garage methodology, Pivotal's methodology, etc.  When we engage with customers on Agile, we often look to scrum as the specific implementation methodology, and suggest training up and certifying scrum masters.

If you are looking for support of your own transformation, I would make the assertion that bringing in a firm to assist with that is generally more successful than having a go on your own.  This can alleviate political issues, quickly scale, or bridge skill gaps - as well as bring experience and unique perspective into the transformation to help break out of ruts.  These challenges are often the underlying concerns which drive the agile transformation.

If you are looking for information in general for your own education, there are numerous studies on high performing teams and the role agile plays in it.  You also will want to look at innovation or requirement gathering methodologies as complimentary to the execution framework (agile) because only addressing the way work gets done is not addressing the end-to-end story. 

Hope this helps, and I would be more than happy to have an off-line conversation with you to explore deeper.

David Greenstein

 Sai,

To your specific point of loosely coupling your diverse teams, that is something that you will have to manage outside of your chosen methodology.  In  other words, you have to plan to be flexible.  In practice, this means making educated guesses regarding the requirements, etc. of the other teams.  You have to treat them as if they are External Actors and out of the scope or control of your immediate effort.  

These "Actors" therefore also represent risk and so therefore present a need to be managed by your project.  Establishing informal communications, communicating in-progress work and findings, and building a community all help to mitigate the risk.  Finally, the basis for the changes across all of the related groups come from the same two areas:  (1) Business Requirements and (2) Technological constraints (data, Systems specifications, etc.).  If you can focus on these areas in initial design, the lower level changes should not be to burdensome.  Again, you have to both plan and design for flexibility in these situations.  

Good luck.

Regards,

Glen Brumbaugh