Designing agile feedbacks for agile learning - an experience report

Feedback is perhaps the most important aspect of the overall agile lifecycle. If the feedback is too wide and shallow, it won't give enough actionable feedback. If it is too narrow and deep, it might fail to register feedback outside its focus area. So, how does one go about designing feedbacks that enable agile learning. We call them agile feedbacks.

In this brief session, we will share an experience from designing agile feedbacks for agile trainings and workshops. The objective was to get most critical feedback in shortest amount of time to enable quick action planning. We created feedback that took a maximum of 5 minutes and enabled the most important learning in both, focussed as well as open-ended manner that allowed us to focus on the most critical items. We employed elements of Design Thinking and Rapid Iterative Testing and Evaluation (RITE) to improve the process and quality of feedback themselves. We will also be touching up these concepts and how effective they were.

 
 

Outline/structure of the Session

1. What is agile feedback - 5min

2. How did we design agile feedbacks - 15 min

3. What did we learn - 5 min

Learning Outcome

1. Importance of agile feedback

2. Applying Design Thinking and RITE to design Agile Feedback

Target Audience

Trainers, Coaches

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Doc Norton
    By Doc Norton  ~  3 years ago
    reply Reply

    Hi TV,

    Many of the conference attendees are requesting presentation slides. We find that your proposal onhttp://confengine.com/ is not updated with your session slides. Could you please update the talk at your soonest convenience?

    - Doc

     

  • Sachin goel
    By Sachin goel  ~  3 years ago
    reply Reply

    Hi TV,

    Have you done this session in 20 mins earlier - will it be stretched? Do you have any material to share at this stage?

    Thanks

    Sachin

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

      Sachin - I haven't done this presentation earlier (this is work in progress as we speak). However, I believe I can contain it within 20 minutes as I am taking up a very specific/narrow aspect of it in my experience report. I don't have a finished presentation material right now, but I have started working on it and should have some strawman in about 2 weeks time. Would that do for now?

      regards,

      TV

       

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

        TV:

        If you could get the strawman to us sooner, that would be great. We'd love to be able to anounce you as an early accepted speaker rather than wait until the final deadline. Our concern is primarily around the length of the session. The review team feels this may better fit into a 45 minute slot. I don't want you to pad it with filler to satisfy our thinking, but we also want to make sure you are able to cover the report will in the time allotted.

        - Doc

         

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

          Sure Doc, I understand. Let me get that started. I am shooting for end of Sep for the first-cut - hope that works for the team as well.

          thanks, TV

  • Sachin goel
    By Sachin goel  ~  3 years ago
    reply Reply

    Hi - enjoyed your session in 2013 conference. thanks.

    Seems like I am struggling here between feedback and Retro. Do you use them interchangeably? if not, how do you differentiate them?

    thanks - sachin

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

      @Sachin - thanks for the feedback on 2013 session. Hopefully I have the opportunity in 2014 again :)

      I think retro is one form of feedback in agile frameworks, specifically on the process that was used to create an increment. To that end, we might say feedback is a broad term that encompasses various levels and frequency throughout a lifecycle, e.g. :

      - TDD loop 

      - CI / commit builds

      - Daily builds / component builds

      - Sprint review

      - Sprint retro

      - Release feedback

      - and so on...

      While the aspect of feedback is well-recognized within the context of software development, we often don't associate similar importance to adjoining activities, for example, training and coaching. Traditional training (from HR / L&D point of view) often relies on bulky feedback, typically in two stages - the one right after the training is more euphoric in nature and doesn't offer much help (except perhaps giving brownie points to the trainer for a great training session) and most organizations stop at that. Very few organizations go to the next level of getting a feedback, say, after 3 months on what has been the real effectiveness of the training. The premise here is that the true effectiveness of a training should be seen only from the results obtained after applying the learnings. This might not always be possible, for a 'transfer climate' (i.e., the environment where a learner can 'transfer' their skills to a real-world problems) might be minght away, and by the time we get to that point, much of the learning might be forgotton.

      Another aspect of training is that they tend to be rather one-way street. The trainer, or the subject matter expert, comes with a canned presentation on what is to be 'taught' to the class. While this might be needed in some situations, in many situations, people are smart and knowledgeable enough aleady and need higher level of engagement than simply being asked to sit through a training. 

      In this session, I will talk about two things that I did differently in the agile trainings that I recently delivered at my organization:

      - training itself was broken down into two components. one was the learning aspect (doing by playing games, sitting through powerpoint, discussions, etc.). second was when the team got together to come with specific recommendations on 'what must change' in order to improve our processes. So, the takeaway of training session was not imparting 'gyan' but the get the team to think how they want to improve processes bottom-up.

      - right after the training, feedback was taken from attendees on what they learnt out of out (as opposed how good/knowledgable the trainer was), how much they believe they can apply at workplace and how much improvement they believe that can bring to their current performance. All this took just 5 minutes of each attendees time. The idea was to 'hear' from attendees rather then make them fill up some meaningless forms that do no real service to teams.

      - finally, after each 'iteration' of such training sessions, the content was modified to incorporate in the subsequent training session. Since training sessions was spread out just by 2-3 days, it was critical to get such agile feedback and incorporate them just-in-time for the next session.

      - lastly, we haven't come to it this last stage, but the plan is to follow-up with each of these group on a quarterly basis to 'assess' if they believe they were able to accrue the 'benefits' that they thought they might be able to accrue by acopting some of those agile practices. This feedback completes the time period between classroom and actual practice and will improve future offerings even further.

      The key takeaway is- agile feedbacks are all about focusing on 'vital few vs. trivial many' and must be rolled-out quickly, and key changes must be incorporated before the next iteration. While an agile feedback might not solve all problems under the sun, the idea is to take up one or two key issues at a time and quickly iterate on it, and build a virtuous cycle of improvement.


  • Liked Nitin Ramrakhyani
    keyboard_arrow_down

    Lean Roots to Grow, Wings to fly!

    Nitin Ramrakhyani
    Nitin Ramrakhyani
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    A lot has been said about Kanban and how these can be implemented in Software development, but the learning remains superficial till we go deep down to its roots to understand the core underlying practices and principles and why/how these practices evolved over a period of time. Infact the roots of most of the Agile methods can be traced back to Lean/Toyota Production Systems, a set of practices and techniques used by Toyota to build great set of cars with limited amount of resources. Even though building software is much different than building a car, there are many lessons and practices that can be learnt and applied nonetheless.

    In this interactive and visual talk, we'll take a virtual trip to Japan and learn some of the best practices/concepts that originated at Toyota for building "world-class" cars and see how each of these can be applied to software development. Learning about the roots of Lean should help the attendees in sowing the seeds of Lean improvement in their organizations and would help in building better software and improving the efficiency of the software delivery lifecycle.

  • Liked Colin O'Neill
    keyboard_arrow_down

    Achieving Enterprise Agility with the Scaled Agile Framework...and Have Fun Doing It!

    Colin O'Neill
    Colin O'Neill
    schedule 3 years ago
    Sold Out!
    90 mins
    Tutorial
    Intermediate

    Scrum, XP, Kanban and related methods have been proven to provide step changes in productivity and quality for software teams. However, these methods do not have the native constructs necessary to scale to the enterprise. What the industry desperately needs is a solution that moves from a set of simplistic, disparate, development-centric methods, to a scalable, unified approach that addresses the complex constructs and additional stakeholders in the organization—and enables realization of enterprise-class product or service initiatives via aligned and cooperative solution development.

  • Liked Tathagat Varma
    keyboard_arrow_down

    Agile, Management 3.0, Holacracy...what next?

    Tathagat Varma
    Tathagat Varma
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Advanced

    Pesentation deck is now available at http://www.slideshare.net/Managewell/what-next-31791295

    Modern management methods are still based on the then seminal work by Henri Fayol some 200 years back, followed by Frederick Taylor's work some 100 years back! Sadly, those models were predominantly based on industrial work, and don't really work that well in knowledge industry and today's sociological dynamics at workplace. Classical Agile methods codify several people practices that allow for a self-organizing team to evolve, but doesn't offer a lot of guidance on how to develop and groom leadership for agile organizations beyond a software team. Management 3.0 takes this issue further and develops it into a separate discipline altogether. On similar lines, Holacracy seeks to create social technology for purposeful organizations, though not specially targeting software organizations. So, the issue of leadership still continues to be unresolved and rather left to pave its way on its own. Unfortunately, when we want to achieve true end-to-end agility, it is not enough for software teams to be charging at top speeds but leadership not evenly matched to support them well in their endeavors. We clearly have a problem at hand...

    In this talk, we will study how the role of leadership has evolved and what does it look like for agile organizations at present. Many agile methods take an extreme view that limit leadership to team-level collective ownership of leadership. However, that might not be enough because of various reasons. In any non-trivial organization, whether a software organizations or any modern business employing software for business advantage, the reality is that organization units beyond a plain-vanilla software teams do exist. So, how does one go about grooming their top talent for playing an effective part in this process?

    Finally, we will also try to take a shot at some of evolving paradigms. For example, all these management thoughts are still based on the kind of outdated premise that an organization is based on 'boundaries' of operations. However, already we see that model being broken down, and the future teams look more like boundaryless entities bound with nothing but a unifying purpose that brings a bunch of volunteers together for a period of time. If our success increasing depends on such teams being able to effectively self-manage themselves, what role does leadership have to play in it, and are we getting ready for it? 

  • Naresh Jain
    Naresh Jain
    schedule 3 years ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    "Release Early, Release Often" is a proven mantra and many companies have taken this one step further by releasing products to real users with every commit a.k.a Continuous Deployment (CD).

    Over the years, I've built many web/infrastructure products, where we've effectively practiced CD. However at Edventure Labs, when we started building iPad games, we realized there was no easy was to practice CD, esp. given the fact that Apple review takes a few days.

    Our main question was: As mobile app developers, how should we architect/design our apps for CD?

    We were a young startup, learning new behavior about our users (kids aged 5-8) everyday. We could not afford any delay in releasing latest, greatest features to our users. To solve this problem, I believe we've built an innovative solution to enable any mobile app developer to achieve CD.

    If you are building real products, which have platform/3rd-party dependencies and you want to practice CD, this session is for you.

  • Liked Anand Bagmar
    keyboard_arrow_down

    Build the "right" regression suite using Behavior Driven Testing (BDT)

    Anand Bagmar
    Anand Bagmar
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Intermediate

    BDT is a way to identify the correct scenarios to build a good and effective (manual & automation) regression suite that validates the Business Goals. We will learn about how this is different from BDD, and do some hands-on exercises in form of workshops to understand the concept better.

  • Liked Tarang Baxi
    keyboard_arrow_down

    1000 Words - Illustrating Project Challenges with Visuals

    Tarang Baxi
    Tarang Baxi
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    A project can face varied challenges through its life, foreseen and otherwise - runaway scope, high defect volumes, depressed velocity, and many more. Addressing many of these first requires recognition of the problem and then action from one or more sets of project stakeholders. Telling the story with simple visuals can be a very powerful way to articulate a challenge (the what), the potential root causes (the why) and the options available to fix it (the now-what). Teams typically already track a lot of data related to throughput, quality, scope and cost. Creative use of this data combined with simple, hand-crafted visuals can be much more effective than hundreds of bullet points. In this hands-on workshop, you get to exercise your visual thinking and visual communication skills. We introduce some simple visual thinking techniques like Look-See-Imagine-Show, and then let you apply them in a project simulation, so that you can practice hand-rolling simple visuals that speak volumes (no fancy tools needed!).

  • Liked Sudipta Lahiri
    keyboard_arrow_down

    Forecasting with confidence

    Sudipta Lahiri
    Sudipta Lahiri
    schedule 3 years ago
    Sold Out!
    45 mins
    Demonstration
    Advanced

    Forecasting has always been a subject of interest to all project management teams. Team have used multiple methods (from detailed MS Project scheduling to Earned Value Management) to try and estimate when a project will finish. People spend a lot of effort to come with one precise hard date knowing fully well how their past predictions have failed, how their assumptions have been invalidated, etc.

    If one were to discuss further with a Project Manager, they will understand that there is a level of confidence that a Project Manager associates with this date.  Perhaps, he is very confident (90% - it is rarely 100%)! It could be even as low as 60-70% depending on the number of issues and risks in the project. In other words, an end date is always associated with a probability, which we in our management talk and presentations, ignore or fail to highlight. In reality, a Project Manager would like to say - I am 70% confident that can deliver this scope of work within the next 3 months but 90% confident that I can deliver this in the next 4 months.

    Kanban systems predict the future by extrapolating current throughput on the present backlog. Most Kanban tools use the CFD for the same. This gives you the gap between the rate at which you need to finish your work versus the rate at which you are finishing work at present. Like MS Project, it also gives one date when this backlog will finish, assuming current throughput.

    Fact is that future is not definitive! Project risks change, requirements change, team resources change... the list goes on! So, just like this inadequate for traditional tools, it is inadequate to limit ourselves to this analysis in the Kanban Method also.

    This session, using Kanban Tool, will demonstrate:

    1. The use of probabilistic theory to have a confidence % associated with a particular delivery date
    2. Once you know the gap between the current throughtput and the desired throughput, what resourcing changes can be done to bridge this gap. While it is understood that resourcing is not the only option to bridge the gap, it is perhaps the most commonly used method. 

    This approach has been vetted by David Anderson and has been presented in the LSSC 2013 conference by one of my colleagues.

  • Sudipta Lahiri
    Sudipta Lahiri
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    Fixed price (and fixed scope) projects dominate the offshore industry. These projects have offshore/onsite teams. They often have large team size (over 100s of people in one team).

    Agile thinking uses team velocity/ throughput and uses that to project an end date (Kanban system) or how much scope can be accomplished in a given time duration (number of sprints in SCRUM). They assume a stable team. However, this is not applicable for projects. They experience resource and productivity ramp-up issues. Often, resources keep changing as new projects come in. Projects do not have past velocity or throughput data. Extrapolating historical data from other similar projects, though possible, is inaccurate for multiple reasons.

    This talk is based on our experience of working with such project teams. They want to adopt agile methods. We show how they can adopt the Kanban Method and yet do: A) Initial Capacity Planning B) Assess the impact of scope creep to the project end date.

    The session assumes a basic understanding of the Kanban method.

  • Liked Pradeepa Narayanaswamy
    keyboard_arrow_down

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

    Pradeepa Narayanaswamy
    Pradeepa Narayanaswamy
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    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.

     

     

     

  • Liked Manik Choudhary
    keyboard_arrow_down

    "Design Thinking" - Create Innovative Right Products

    Manik Choudhary
    Manik Choudhary
    schedule 3 years ago
    Sold Out!
    45 mins
    Case Study
    Advanced

    Design Thinking is an approach to solving Design/Wicked problems by understanding users’ needs and developing insights to solve those needs. It helps to address the right questions and to create the “Right products”.

    Design Thinking is an iterative innovative approach. It is not meant as a replacement for the organization’s standard development approaches; rather Design Thinking works inside of agile projects, offering frameworks for collaboration and innovation.

    Design Thinking ultimately helps you to address the right question and to create the right solution for it. It Means creating innovative "Right Product" by combining diverse people, creative space and an iterative approach.

  • Liked Ellen Grove
    keyboard_arrow_down

    Build Your Dreams: User Requirements Gathering with LEGO Serious Play

    Ellen Grove
    Ellen Grove
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    Let your hands be the search engine for your brain! LEGO® Serious Play® is a powerful thinking, communicating and problem solving technique that can help you and your team do serious work through structured play activities using a popular and playful 3D modeling toy. Through a facilitated process of building models that, storytelling and reflection, every person at the table is engaged and actively participating in the discussion, whether the topic is individual aspirations, team relationships, developing a new product or solving a wicked organizational problem. Everyone builds and everyone tells their story – all participants have equal opportunity to put their own points of view on the table, unlocking new perspectives and exposing the answers that are already in the room.  LEGO Serious Play has been used successfully for team-building and problem solving in a variety of organizations, from NASA to RBC to academic settings and public utilities.  

    This presentation provides a hands-on introduction to LEGO Serious Play, so that you can experience firsthand how using LEGO to do real work unleashes creativity and enables meaningful conversations in a very short time. We will explore how to use this playful technique to collaboratively elicit information about user requirements and strategic design issues using the open source User Requirements with Lego methodology developed by a team at the University of Lugano, Switzerland.  This approach is particularly suited to Agile teams that want to get team members and stakeholders sharing their different perspectives on common goals in an open and light-weight manner.

  • Liked Neil Killick
    keyboard_arrow_down

    The Guessing Game - Alternatives to Agile Estimation

    Neil Killick
    Neil Killick
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Agile promotes empiricism and change, yet many practitioners continue to scope out and estimate delivery times and costs for software products and projects.

    Defenders of the art of estimation claim that we need to estimate software projects in order to answer common business and customer questions such as:

    • Should we go ahead with this project? (go/no-go)
    • How much will it cost? (bottom line)
    • When will it be done? (predictability)
    • Should we do project B instead of A? (prioritisation)

    This session challenges participants to flip these questions on their heads and seek alternatives to estimation rituals. It covers the many risks inherent with an estimation culture and demonstrates real, practical alternatives, both at the portfolio and the sprint level.

  • Liked Tathagat Varma
    keyboard_arrow_down

    Agility @ The Scale of Busine$$

    Tathagat Varma
    Tathagat Varma
    schedule 3 years ago
    Sold Out!
    45 mins
    Case Study
    Advanced

    [24]7 Customer, Inc started out in customer service space from Bangalore in 2000. Today, it is a sucessful mid-size company in voice-based customer support that also creates IP and products in big data and predictive analytics for some of the biggest names in business, and is a a high-growth company headquartered out of US. The growth in product R&D happened both organically as well as from acquisitions across multiple geos. While the initial / startup stage processes had been extremely successful in building the company's strong foundation, it was felt that the next stage of growth might not be a linear extrapolation of the past successes. Recognizing this futuristic need, it initially embraced agile software development methods in Q1 of 2013 to improve responsiveness, predictability and time to market in the product development organization. In Q2 of 2013, it embarked upon an ambitious company-wide program. The charter was to establish an end-to-end execution framework to make the entire operations efficient and effective - right from marketing and pre-sales to delivery, deployment, operations and ongoing optimization. 

    In this session,

    • We will analyze challanges involved in scaling-up agile adoption outside the software team across the entire organization.
    • Specifically, we will also discuss how we addressed some of those unique challanges that are associated with growth and scale, and
    • What does it take to achieve true end-to-end agility. 
  • Liked Dinesh Sharma
    keyboard_arrow_down

    Thinking Environment - Do you have one?

    Dinesh Sharma
    Dinesh Sharma
    schedule 3 years ago
    Sold Out!
    90 mins
    Talk
    Advanced

    Everything we do depends for its quality on thinking we do first. Our thinking depends on the quality of our attention for each other.

    A Thinking environment is the set of ten conditions under which human being can 'think' for themselves - with rigour, imaginaton, courage and grace. A Thinking Environment is natural, but rare. It has been squeezed out of our lives and organisations by inferior ways of treating each other.

    Thinking environment is based on ten behaviours that generate the finest thinking, and have become known as The Ten Components of a Thinking Environment. These components are

    • Attention,
    • Equality,
    • Ease,
    • Appreciation,
    • Encouragement,
    • Feelings,
    • Information,
    • Diversity,
    • Incisive Questions and
    • Place.

    Each Component is powerful individually, but the presence of all ten working together gives this process its transformative impact.

     

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