Building a Team Backlog: The Power of Retrospectives

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

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

Outline/structure of the Session

5 mins - opening, intro and stage setting

5 mins - quick exercise to bring everyone on the same page of understanding the basic concepts

5 mins - overview and discussion on common challenges 

10 mins - common data gathering and facilitiation techniques for effective retrospectives

10 mins - unveiling the concept of team backlogs and discussion into the applicability of it in different situations

10 mins - mock retrospective session and demonstration of deriving actionable, impactful and measurable team-backlog items

 

Learning Outcome

- new and interesting ways to conduct retrospective sessions - what worked for us and why?

- learn to handle different team situations by tuning the styles of retrospectives

- a new way to bring rigor in the process of continous improvement - team backlog - how to build one for your team, and how to use it to see lasting impact.

 

Target Audience

All who practice scrum, or any other iterative agile processes

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • AgileSattva Consulting LLP
    By AgileSattva Consulting LLP  ~  1 year ago
    reply Reply

    Hi Bhuwan,

     While rightly you have mentioned about having discipline and rhythm of the ceremony, would you also cover the different types of retrospective Plans? When to use what? It would be interesting to know that!

    Good Luck!

    Deepak

    • Bhuwan Lodha
      By Bhuwan Lodha  ~  3 years ago
      reply Reply

      Hi Deepak,

      Thanks for your comment. Please check slides 15 onwards in the linked presentation. Like I said, it is from a previous talk, but usually we do cover a lot of content talking about various techniques of retrospectives and tips from our experience on applicability of styles based on team situations.

      Regards, Bhuwan

  • Doc Norton
    By Doc Norton  ~  3 years ago
    reply Reply

    Kanchan & Bhuvan - If you could please respond to our reviewer's questions, it would really help us in our decision process.

    - Doc

     

    • Bhuwan Lodha
      By Bhuwan Lodha  ~  3 years ago
      reply Reply

      Hello Doc, 

      I just responded. Apologies again for the delay.

       

      Thanks

  • Ram Srinivasan
    By Ram Srinivasan  ~  3 years ago
    reply Reply

    Hi Kanchan and Bhuvan,

    Thanks for your proposal. I saw your slides and I have a few questions

    1. Why are you reinventing the wheel? Scrum has a pattern called "Scrumming the Scrum" -  https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern-language/scrumming-the-scrum

    From the retrospective, the top item gets  estimated, (sometimes is written as a user story) and gets added to the product backlog. Yes, product backlog, because the teams should be able to look at only one place and that is the product backlog (and improving process is part of product backlog).

    2. Retrospective, like any other meeting, requires good facilitation and clear owners are assigned to all action items. And they have to be followed up in the next meeting (in this case it would be the next sprint review and sprint retrospective).  How is your "team backlog" with people assignment different from a session facilitated by a good facilitator? 

    3. Challenge #1 (from your slides - slide 7) - Unclear recipe

    Scrum is a framework and is not intended to provide you solutions. And there are multiple ways of doing retrospective. What are you really gaining by introducing it as a new framework (really a framework?)

     

    Thanks,

    Ram

     

    • Bhuwan Lodha
      By Bhuwan Lodha  ~  3 years ago
      reply Reply

      Hello Ram,

      Apologies for the late response, but both of us were tied up with project work and traveling.

      Thanks for your questions. Very thoughtful indeed.

      Here are our responses - 

      1. Yes, scrumming the scrum is a known pattern, and has been talked about with varying opinions in the industry. We are introducing the team backlog as a separate artifact in addition to the product backlog. The idea is to de-link the concerns of tracking progress of the product from that of the team. Two arguments for that - a) priorities are not to be mixed, while the PO who owns the product backlog calls the shots on the priorities in the product backlog, he can not do justice to prioritising the team backlog items (remember he represents the customer!). b) while the product is showcased and celebrated via working software and visible progress indicators, teams often fail to remind themselves of the journey they've gone thru over time. Tracking and measuring the impact of removed impediments, new ideas, initiatives that help the team..etc. is important in modern context.

      2. Yes, a good facilitator is needed, not just for retrospectives, but all scrum ceremonies to be effective. We intend to equip the team with a structure that can last over time, and be independednt of facilitation styles of individuals. In the same way that PO needs to facilitate an effective and goal oriented sprint planning session, he also needs a product backlog to keep everyone on the same page and ensure consistency of experience for team members, dependent teams as well as various stakeholders. 

      3. Yes indeed scrum is a framework (who'd deny that?). We are using that framework in a complimentary context of building great teams. Core to that is making retropsective sessions goal oriented and fun at the same time.

       

      Do let us know what you think, and if you'd like to speak with us to understand our proposal in a better way. 

       

      Looking forward,

      Bhuwan

       

  • Nitin Ramrakhyani
    By Nitin Ramrakhyani  ~  3 years ago
    reply Reply

    Bhuwan/ Kanchan,

    Good stuff here !. Just a thought/ question on why to link it to just retrospectives and not make it an inherent part of a 'Kaizen' culture. Just like Backlog can be added anytime, one needn't wait for the 'Team Backlog' to get added only during a retro.

    I'm not suggesting any changes to the prexo, but just leaving a food for thought, may be for any new presentations. :-)

    Thanks,

    Nitin

    • Bhuwan Lodha
      By Bhuwan Lodha  ~  3 years ago
      reply Reply

      Hello Nitin,

      Thanks for your inputs. And you are absolutely right. Tangible and visible indicators of team improvement should be at the core of any agile process. Introducing and building a team backlog via effective retrospectives is a quick win for teams. That is what our talk will try to bring out

      While the concept warrants sustained and constant engagement from the entire team - we are, in this talk, limiting the scope of available aveneues for data-gathering to retrospectives. We may add some more content as we explore further in the run up to agile india 2014.

      Looking forward,

      Best, Bhuwan

  • Sonik Chopra
    By Sonik Chopra  ~  3 years ago
    reply Reply

    Hi Bhuwan

    This is quite interesting. And are you going to present an extension of impediments list as team backog? It would be helpful if you can share the format.

     

    Thanks

    • Bhuwan Lodha
      By Bhuwan Lodha  ~  3 years ago
      reply Reply

      Hi Sonik,

      Please check slides 9, 10 and 11 in the linked presentation for more details on how we propose the structure of "team backlog".

      Of course this is from a previous talk, and we are continously refining it as we learn and implement this more in our teams and discuss with our audiences.

       

      Thanks,

      Bhuwan


  • Harish Krishnaswamy
    Harish Krishnaswamy
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    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.

     Success:

    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.

  • Liked Naresh Jain
    keyboard_arrow_down

    SAMPLE PROPOSAL - Product Discovery Workshop

    Naresh Jain
    Naresh Jain
    schedule 3 years ago
    Sold Out!
    90 mins
    Tutorial
    Beginner

    Many product companies struggle with a big challenge: how to identify a Minimal Viable Product that will let them quickly validate their product hypothesis?

    Teams that share the product vision and agree on priorities for features are able to move faster and more effectively.

    During this workshop, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.

    This 90 mins workshop teaches you how to collaborate on the vision of the product and create a Product Backlog, a User Story map and a pragmatic Release Plan.

    This is a sample proposal to demonstrate how your proposal can look on this submission system.

  • Liked Prerna Kale
    keyboard_arrow_down

    Cent Cent Business Value! A Sneak Peek at sprints from evolving design/UI, getting right priorities to delivering $$

    Prerna Kale
    Prerna Kale
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

     

    We want to share experience of working on a complex project, with deadlines set upfront and all players distributed. Perhaps argued as a complex combination to have but yet we were right there, on time enabling the new tool there. Reporting systems often have evaluation cycle that have imperative timelines to start and freeze, hence working for a huge system was not easy. Right agilist mindset with right agile practices helped us meet this. As a Product owner I jostled with eight experts using one system with some variation for their own service lines. We want to show how we leveraged the benefits of distributed teams balanced the challenges, kept the UI flexible enough to accommodate 8 expert reviews, and how our evolving architecture designed a system that had the most used and important features for the users to try hands on..

    Introspecting and sharing how we ensured Cent Cent business Value:

    - Kick off the project with eight stakeholders that got the ball rolling
    - Identifying the 30 % that was core to the business
    - Inspecting, and adapting to constant changes with modular designs
    - Getting stakeholder agree on priorities
    - Release Backlog with stories and design with validated acceptance criteria
    - Managing challenges and ensuring meeting needs seamlessly with truly distributed teams (Distributed PO/Designer/Architect/ Team/ Stakeholders)

    How important is it to dig the core 20-30% in projects with deadline upfront and ways to do that.. Prioritization techniques that enabled mutual agreement on the needs. Backlog with designs that reduced the development time. How work effectively with distributed teams, by building trust, keeping motivation and sharing the definition of done- yes we lived it and did it! We want the audience to explore it all with us and be open to take up and successfully meet the projects with distributed agile teams and tight deadlines yet agile :)

  • Liked Ted Tencza
    keyboard_arrow_down

    Creating a Great Engineering Culture in an Agile workplace.

    Ted Tencza
    Ted Tencza
    schedule 3 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

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

    Vibhu Srinivasan
    Vibhu Srinivasan
    schedule 3 years ago
    Sold Out!
    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

    Working at a lean startup

    Vibhu Srinivasan
    Vibhu Srinivasan
    schedule 3 years ago
    Sold Out!
    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

  • Liked Kanchan
    keyboard_arrow_down

    Come! Take a plunge with us into the world of Self Organization!

    Kanchan
    Kanchan
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Intermediate

    In agile teams there is a belief that the teams self organize. But do we really understand what this really means? The scrum guide simply says three things autonomous, self transcendent, cross functional.

    In this interative workshop we will experience what self organization is all about via a fun filled game. You will go back with key learnings through your own experience. 

    This session will be a combination of audience participation in activities, discussions combined with presentations and loads of fun!

    This interactive game session is for anyone who wants to learn more about  being self organized and what makes the self organized teams tick.

  • Liked Lalatendu Das
    keyboard_arrow_down

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

    Lalatendu Das
    Lalatendu Das
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    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.