location_city Bengaluru schedule Feb 27th 01:55 PM - Jan 1st 12:00 AM place Esquire

The webMethods R&D division of Software AG (wM) produces industry-leading enterprise products focused on application integration, business process integration and B2B partner integration. This division with more than 450 engineers across 7 locations in the world embarked on the journey of adopting Agile and Lean Software Development practices in 2010.

The Pain

The wM business line consists of about 40 Scrum teams delivering more than 30 enterprise products that constitute the webMethods suite across 7 locations in the world. Circa 2007, the suite was a loose collection of multiple products individually developed by teams, many of which were brought together by M&As. It was a hard, painful challenge to integrate and test these products as a single suite and synchronizing major releases. The teams embraced Scrum as the development model - a useful first step but still far from guaranteeing predictability, high standards of quality and productivity at the suite level.

The Challenge

  • Align multiple, small scrum teams distributed over many locations to one Suite Backlog. Focus them on delivering an integrated Suite by modeling an assembly line from a Lean Manufacturing system. The teams develop and contribute to a single value stream with continuous flow and deliver potentially shippable Suite Build Sets in predictable intervals (4-6weeks).

  • Retain the simplicity of the ‘Agile model’. Allow teams to grow at their pace. The teams work off their individual team backlogs, the suite complexities and priority conflicts largely hidden from them. They experiment with their processes, drive their own local changes and share the learning with the other teams.


Since embracing Lean and Agile practices, we have delivered three successful major Suite releases on time with measured quality. The customer situation has dramatically improved with steadily decreasing customer incidents, response times and hot escalations. More than a 100,000 automated regression tests  verify the suite and we have a potentially shippable Suite build set every 4-6 weeks guaranteeing the highest standards of quality. For faster value delivery, we are now transitioning to 6-monthly releases – the first of which is due to roll out in Q4 2013.

In this Experience report, I focus on how we aligned scrum teams operating from Germany, U.S, Bulgaria and India to a single backlog, a continuously integrated Suite and a potentially shippable single build set delivered every 4-6 weeks. We will look at the challenges we faced, custom solutions and processes that we designed to realize the Single Suite Vision.


Outline/Structure of the Experience Report

  • Single Suite Backlog – managing multiple product owners, technical debt and getting the priority and investments right.
  • Single Suite Value Stream -  Continuous Flow, eliminating bottlenecks and limit WIP.
  • Pulling the Andon chord - Protect yesterday's investment while delivering today's value increment.
  • Sustaining Vs Development – balance new feature development flow against high-response customer support.
  • A culture of Experiments and Continuous Improvement


Learning Outcome

A reference model to implement Lean development process in a multi-team, multi-product environment and achieve predictability, quality and productivity.

  • Continuous Suite-wide Integration – modeling a Lean Production Assembly line.
  • Visualizing the Flow, backlog, debt - metrics at multiple scales for different audience.
  • Some recipes to handle cross-product and multiple stakeholder conflicts
  • Ways to evolve custom processes to meet your unique challenges

Target Audience

Leaders, Managers, Coaches, Scrum Masters, Team members from a Product Development (R&D) environment.

schedule Submitted 7 years ago

Public Feedback

    • Abhilash Chandran

      Abhilash Chandran - Retrospectives with large projects and (or) multiple teams

      20 Mins
      Experience Report

      Retrospectives are the one of the most integral components of any agile methodology.  In scrum a retrospective is typically done after each sprint. This process is simple if team is small or only one team is working on a product. The problem starts increasing exponentially when many teams work on a single product. All the teams have ideas to improve the process and production.  One team may have an entire opposite idea of another. How to bridge this gap?

      Last project executed across different teams (onsite & offshore) and different departments was not a great success. How to learn from the past failures and apply it to future projects?

      In this discussion, I will be talking about some the points which can be easily followed in such scenarios. 

      Why did we did this?

      Normally in a scrum environment we have a single team with Product Owner; they do the retrospectives within team. Team identifies the issues and work on them. Many team falls into this category. It is pretty simple

      Let’s complicate this further.

      • A big product with 10 scrum team
      • Each Team has different PO

      Apart from these main stake holders there are many others who are interested in the success of this application

      • Sales team
      • Documentation team
      • UI design team
      • Architecture and performance team

      In such a scenario, a retrospective at team level will be effective only at granular level. But it leaves a gap in few areas; it helps to bring all the teams together for one big retrospective

      • Apply the improvements made at each team level to the whole program
      • A team's retro action item against the process followed by another team can be discussed at a higher level to find an optimal solution
      • Sometimes two team's retrospective action items may be contradictory. This gathering may point a third solution
      • Sr Product owners and manager will get all the teams together. A common focus and improvement plan can be shared across teams.
      •  All team gets to know about the key concerns at the program level and with other teams.
      • Ultimately it gave a feeling of one big family.

      My experience

      Last large retro organized in our group was a big success. The sales team & architecture team had many ley lessons to take back from this meeting.  Many issues were bought out which could have been solved with better co-ordination across team.  Concrete action plans were made by team for the subsequent release.  Some of the key findings were shared across other program teams also.

    • Bhuwan Lodha

      Bhuwan Lodha - Building a Team Backlog: The Power of Retrospectives

      Bhuwan Lodha
      Bhuwan Lodha
      VP - Digital
      McKinsey & Company
      schedule 7 years ago
      Sold Out!
      45 Mins
      Experience Report

      “Inspect and adapt” is one of the basic tenets of continuous improvement, and agility in general. Holding retrospectives is one of the core processes that allows teams to look back and reflect on their progress. However, over time, teams may focus only on the product work and lose interest in their own improvement as a team. Kanchan Khera and Bhuwan Lodha believe that one approach to solving this problem is to bring the rigor, structure, and discipline we use for maintaining healthy product backlogs to team improvement by creating a “team backlog”—items the team needs to do to improve itself. The team backlog introduces three keys to successful and sustainable team improvement—a structured framework, visibility of its impact, and creative ways for building the backlog. Just as a healthy backlog is the basis for a great product, so a healthy team backlog helps create great teams.

    • Zaheerabbas Contractor

      Zaheerabbas Contractor - Applying Agile Practices in the Refurbishment/Modernization of my housing society

      45 Mins
      Case Study

      In the rush to be a proud owner of a large independent penthouse apartment in a huge housing society I did not realize (or did not want to) the actual reason behind this good bargain!

      I ended up being party to the following list (product backlog) of pain areas (or business needs) of the society members:

      • 1.Need of Generator backup to cater to the frequent power cuts at least for the common areas and lifts (I had bought my condominium on the top floor and could realize the pain!) – Must have and High Cost
      • 2.Modernization of the ageing lifts across 18 buildings (thanks to the substandard quality lifts which I realized when I started staying there L ) – Must have due to high risk however huge Cost
      • 3.Need for the CCTV Camera – Must have considering the frequent untoward incidents
      • 4.Seepage and septic tank upgrade
      • 5.Pavements, speed breakers
      • 6. And the list goes on….

      This resulted into the society being least valued in that area and no ROI for the members who had invested in the society.

      The society committee members were clueless on where to start (prioritizing with business value) with the given evolving budget and how to manage the timeline.

       Through this report, I intend to share how I utilized following Agile practices to overcome the challenges faced by the society members for its refurbishment and converted the society into one of the most sought out society over the period of few milestones (releases)!

      • 1.Prioritization(MoSCoW) of the backlog by agreeing up urgent need of the society in the given budget
      • 2.Continuous planning and re-prioritization of product backlog
      • 3.Outcome(Value) based agreement with various vendors
      • 4.Managing discipline in the acceptance criteria and retrospection (i.e. PWD lift inspection and approval for lifts functioning with the given municipality specifications and taking learning to replicate the same for future enhancements)
      • 5.Delivering end to end(INVEST) in the production in short releases ( i.e. one lift modernization end to end and commissioning of Diesel Genset end to end through incremental approach)
    • Pradeepa Narayanaswamy

      Pradeepa Narayanaswamy - WORKSHOP- Defining Behaviors as a team

      45 Mins

      In lot of agile teams, often times, all the team members will be doing the grooming and planning exercise as a team. Often times, defining the behaviors is either ignored, overlooked, skimped or done by individuals on their own without a common understanding as a team.

      To solve this problem, I have used this hands-on time-boxed activity for all of my teams to define behaviors as they move along in the sprint. This will help all the team members to have a shared understanding on their users and their behaviors as it relates to their user story. This is an activity that any agile team member can take and implement the next day at work.



    • Pradeepa Narayanaswamy

      Pradeepa Narayanaswamy - We're Moving to Agile: What Do I Do with My testers?

      45 Mins

      As more and more organizations are transitioning to Agile, there still exist a lack of understanding on how testing fits in the Agile teams. Is it just about placing a tester in every team? How can we realign the team members including testers from being on silos to an effective cross-functional team? Pradeepa Narayanaswamy shares her insight on the key basics of Agile testing along with understanding the Agile testing mindset and testing goals. Pradeepa also shares her ideas on how to manage defects, what to measure as metrics and what to document. Learn what you need to know as a tester who are new to Agile. If you are an experienced Agile tester, review these important basics and realign the concepts that may have been overlooked or forgotten in your teams.