Setting agile teams for success – Use of Operations Research to improve agility

While there is a good amount of literature on how an existing agile team can self-organize to deliver higher business value, very little has been said about how to use learning from one team on another or how to set new agile teams for long term success.

In our organization, a typical engagement lasts for 6-8 weeks, leaving very little time for team ramp-up. Setting teams for success was not aspirational but a core ingredient to our service delivery. We explored the field of Operations Research (OR) and applied some of the techniques to software engineering. In this experience report, we are going to share how we leveraged OR concepts such as “Queueing Models” and “Network Optimization” techniques to identify

- What should be the ideal size of a story to deliver optimal value

- What should be the optimal team staffing for a given scope of work

- How to get more predictability on release plans of agile projects

While our research in this field has been tailored to a very specific type of work we do, the concepts and learning can have wider application.

 

 
2 favorite thumb_down thumb_up 10 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Session Outline (prefer a 60 mins slot):

- Who are we, where we come from? (2 mins)

- The problem we set out to solve (3 mins)

- Intro to the OR concepts we explored, how we mapped them to Software engineering? (10 mins)

- Volunteer driven game to illustrate the OR concepts (20 mins)

- The data driven insights we derived from our experiment, how we applied these insights (10 mins)

- Recap of Key learnings (5 mins)

- Q&A (10 mins)

 

Learning Outcome

For program managers/ Functional Managers running multiple agile teams

- How to get better predictability during release planning

- How to staff a right sized team for a specific project

 

For Product Owner:

- What is the right size of a story? How to be more scientific about (instead of going by purely gut feel) what granularity the team should aspire for?

 

For Agile Coaches:

- A whole new scientific perspective of looking at software engineering

- A potential new area of further research

 

Target Audience

Product Owners, Program Managers running multiple agile teams, Agle Coaches driving agile transformation

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Jerry Rajamoney
    By Jerry Rajamoney  ~  4 years ago
    reply Reply

    Hi,

    Interesting topic. After reading your blog I have the following query:

    1. you have mentioned about the flow of feature request and used the OR to arrived at solution #2. But what is the ROI for each of those feature request? Are they going to be the same? Is this parameter is considered? Becasue with out the ROI of each feature how will you justify the returns?

    Could you kindly clarify?

    Jerry

    • Lalatendu Das
      By Lalatendu Das  ~  4 years ago
      reply Reply

      Hi Jerry,

      thanks for going over the topic and responding to this thread. 

      You raised a valid point whether RoI for each feature (= Kanban card) is same. Just to clarify, In our context there are two distinct group at play in the process of solution development. The Product Mgmt group does the RoI calculation at the Overall product level, breaks down the requirement into small managable features, assign priority to them and puts them in the "To Do" bucket of the Kanban board.

      The second group (dev team), simply pick the features based on their priority and move them to 'In progress' and then to 'Done'. The use of OR, capacity planning etc, are all targetted at the second group, that is the dev team. This team simply goes by the order or priority set by the business/ Product Mgmt team, without worrying about the RoI for each feature.

      Hope this clarifies. Would love to get your reactions.

      Meanwhile, I have prepared a very crude strawman of the eventual presentation on this topic. Please have a look at the link below and let me know if you have any questions, suggestions.

      https://docs.google.com/presentation/d/12pjQqhyYMvfWPfJQ9RlYK3Ggdj_Am1nHZOeMnHm0Ckk/edit?usp=sharing

       

       

      • Tathagat Varma
        By Tathagat Varma  ~  4 years ago
        reply Reply

        Hi Lalatendu - Thanks for putting together a strawman. I would like to see specific examples from the field in that. As much interesting and educational it is to have simulation exercises to illustrate the point, at a conference like this, I would expect people to be kind of aware of basics. So, the question is - how exactly did you apply these learnings in the real-world and what were your learnings from it? 

        -TV

        • Lalatendu Das
          By Lalatendu Das  ~  4 years ago
          reply Reply

          Hi Tathagat, 

          Thanks for the feedback, it helps tremendously in refining our pitch.

          In this experience report we want to demonstrate how we applied OR to solve specific challenges we were facing in Kanban projects

          Application #1

          Situation - We wanted our capacity planning / team staffing for our Kanban projects to be more scientific, given our short project cycle

          Application - We used MM1 queueing model to arrive at an optimal recommended team capacity

          Learning - Still work in progress. The challenges we faced in using MM1 queueing technique is that the model doesn't factor in relative skill level of diff individuals. It predicts the optimal service rate and recommends how many dev capacity is needed. However not all devs have the same productivity.

          As a next step, we are gathering productivity data at group level. over period of time, the avg productivity numbers can be fed into the model to enrich it;s prediction

          Application #2 

          situation - All our product owners realize that each feature/ kanban card should be as small/ granular as possible. However there is a trade off. Too small a feature doesn't deliver distinct business value. Too big a feature, slows down the flow by increasing WIP. 

          Application - Again we used queueing technique to see the implication of feature size on the overall flow.

          Learning - This approach was successful in two ways a) reinforcing the point on keeping features as granular as possible b) Indicating right size of a feature. However the model is based on estimated time taken for building a feature, as we run the model during planning stages. At times we encountered significant deviation from estimated vs actual time taken for building  a feature. Hopefully with time, these deviations will decrease and the preditions of the model will be more accurate.

          Hope this clarifies the proposal. Please let me know if you have any questions. LD

  • Ebin John
    By Ebin John  ~  4 years ago
    reply Reply

    Hi Lalatendu,

    The title looks very interesting. Can you elaborate a little more on how you use OR concepts to improve Agility? If you can share some links or blogs or feedback, that would help.

    Please have a look at the themes as well because i feel that the theme Scaling Agile Adoption is a better fit for your content.

    -Ebin

    • Lalatendu Das
      By Lalatendu Das  ~  4 years ago
      reply Reply

      Hi Ebin,

      please refer to this blog post describing one key aspect of this talk..

      http://techno-realism.blogspot.in/2013/08/use-of-operations-research-to-plan.html

      please share your feedback. Will blog about certain other aspects shortly.

       

      Meanwhile about the appropriate theme for the talk, I still believe this talk fits more in "beyond agile" theme as we explore application of OR concepts in setting up agile teams right. This talk will stress less about how to scale agile teams. That said, I would love to hear your views about this..

      • Tathagat Varma
        By Tathagat Varma  ~  4 years ago
        reply Reply

        Hi Lalatendu - while the topic of your talk sounds interesting, the proposal is not very clear. I also checked out your blog and it was not very clear as to what problem we are solving and what is the context. For example, how/why are we getting 3 new feature request per day? Is it new product development or field bugs for a maintenance project? The reason behind solution 1 is also not clear - why should we 'maybe' pickup a team of 5 to 6 - this will surely be driven by business consideratins, among other factors. Could you make a strawman of your deck and share so that reviewer panel could get a better picture of what you propose to address?

        -TV

        • Lalatendu Das
          By Lalatendu Das  ~  4 years ago
          reply Reply

          Hi Tathagat,

           

          thanks for showing interest in this topic. Please see below a very crude strawman of the deck. Hope this gives you better idea of the topic. Please let me know if you need clarification on any specific aspects

           

          https://docs.google.com/presentation/d/12pjQqhyYMvfWPfJQ9RlYK3Ggdj_Am1nHZOeMnHm0Ckk/edit?usp=sharing

          LD

  • Prasad
    By Prasad  ~  4 years ago
    reply Reply

    Hi Lal,

    Good area to explore, will be useful, if we point us to a blog or some ofyour early experinces/ cases


  • Liked Bhuwan Lodha
    keyboard_arrow_down

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

    Bhuwan Lodha
    Bhuwan Lodha
    VP - Digital
    McKinsey & Company
    schedule 4 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

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

  • Liked Ted Tencza
    keyboard_arrow_down

    Ted Tencza - Creating a Great Engineering Culture in an Agile workplace.

    Ted Tencza
    Ted Tencza
    Director of Engineering
    Bigcommerce
    schedule 4 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Company culture, or its DNA, is one of the most important factors to determing if a company succeeds.  Many companies claim to have great company culture.  But what does this mean, how can you know if your company has a great culture, and how can you go about improving the culture?  This talk will explore what great companies have in common, and share experiences I have had in helping to develop engineering culture during my career.    

    Will also explore how Agile principles help to foster creating the best possible culture for your organization.

  • Liked Vibhu Srinivasan
    keyboard_arrow_down

    Vibhu Srinivasan - Coding with Geeks- De Code the secrets behind TDD, BDD and ATDD

    90 mins
    Tutorial
    Intermediate

    This session is a coding sessiont that takes a problem and shows clearly what is the difference between TDD, ATDD and BDD. Ths session uses code for the server layer as well as UI layer.

    This session is not for you if you do not code. If you do code, please bring your laptop as we delve into the details of all these styles of programming techniques.

    We will rotate between ATTD, TDD and BDD periodically and show it at use in different layers. This session will be using Java , Rails, Scala and C# together so that you can see how you can benefit do these techniques even when coding in different languages.

    We look at common pitfalls and wrong beliefs that programmers have when it comes to these concepts

    This session is purely keyboard and you will have to bring a laptop.

  • Liked Vibhu Srinivasan
    keyboard_arrow_down

    Vibhu Srinivasan - Working at a lean startup

    20 mins
    Experience Report
    Beginner

    I have had the oppurtunity to build and be part of a few successful and failed startups. One such succesful startup was my association with a startup called Evri.com. I have also consulted as a developer and coach for a gaming company called BigFishGames which went to become a largely succesful gaming company making one game a day today. 

    In this session I would like to tell the story of what happened at Evri and Big Fishgames that made them succesful. 

    This is a lessons learned, observatiosn shared being part of this startup as a developer. This session also looks at what makes a good product. Is product creation a pure idea of a bunch of geeks working together or something more than that. 

     

    Come see and learn