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

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.

 

 

 

 
41 favorite thumb_down thumb_up 8 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Testers’ responsibility in traditional projects
  • I am an agile tester, now what?
  • What is agile testing?
  • Agile testing goals
  • Agile testing mindset
  • Topics that testers care about:
    •             Defect Management
    •             Metrics – What to measure?
    •             Documentation – How much?
  • Conclusion
    •             What is NOT Agile testing?
    •             Common myths and truths about Agile testing

Learning Outcome

Let’s get back to the basics of Agile testing to drive out waste caused by the pitfalls of traditional thinking. Attendees for this presentation will be able to learn about

  • What is Agile testing?
  • Goals of Agile testing
  • Agile testing mindset
  • Testers’ responsibility in agile teams
  • Testing skill sets and gaps and how to address that?
  • Defect Management
  • Metrics
  • Documentation
  • When do you stop testing?

 

 

Target Audience

Tester, developer, business analyst, coach, manager, Test lead, or anyone else with a stake in delivering high-quality software

schedule Submitted 4 years ago

Comments Subscribe to Comments

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

    Hi Pradeepa,

     Would like to know what you define as "Agile Testing" as? You are also refering to T shaped talents in response to Joel's comment, would like to know if the breadth of the skillset of tester will go across development also?

    When you refer cross-functionality its across entire team, not just testing isnt it? So could you help me understand how getting T shaped talent applicable only specific to agile testing? - I assume it would be for entire team.

    Would you also cover about metrics? that seems very interesting section that is need of the hour! Let us know what type of metrics you refer to.

    • Pradeepa Narayanaswamy
      By Pradeepa Narayanaswamy  ~  1 year ago
      reply Reply

      Hi Deepak,

      Thanks for your questions. Please see my responses below.

       

      Would like to know what you define as "Agile Testing" as?

      An Asynchronous, incremental way of testing in parallel to development is how i would define in a nutshell.

      You are also refering to T shaped talents in response to Joel's comment, would like to know if the breadth of the skillset of tester will go across development also?

      It totally depends upon the project. The more the teams are responsible for innovation and learning, the more they need to be cross-functional. Its good for testers to be cross-functional and the areas of the cross-functionality varies from the project. It can be anything from programming, designing, unit testing, pairing testing with developers, working with PO, so on  and so forth...

       

       

      When you refer cross-functionality its across entire team, not just testing isnt it? So could you help me understand how getting T shaped talent applicable only specific to agile testing? - I assume it would be for entire team.

      It is preferred for any agile team member( including testing specialties) to be cross-functional. How much cross-functional depends upon the project needs.

       

      Would you also cover about metrics? that seems very interesting section that is need of the hour! Let us know what type of metrics you refer to.

      I am covering the basics about Agile Metrics. Its worth a topic by itself and i can always have an after conversation with the attendees on this topic.

      Few things i wanted to cover here are: How you want to measure up, focus on Customer side metrics instead of build side, and the only thing that matters is "What your customers says about the product?".

       

      Hope this helps. Please let me know if you have further questions or need clarifications.

       

      Regards,

      Pradeepa

       

       

       

  • Naresh Jain
    By Naresh Jain  ~  4 years ago
    reply Reply

    Pradeepa, request you to move all your links out of the abstract and add it to the links section. Please don't stuff your abstract with links.

    • Pradeepa Narayanaswamy
      By Pradeepa Narayanaswamy  ~  1 year ago
      reply Reply

      Thanks for the feedback. All Links moved to links section.

       

      Pradeepa

  • Joel Tosi
    By Joel Tosi  ~  4 years ago
    reply Reply

    Hi Pradeepa,

      Your submission does fit a nice niche.  Will you also talk about skills, gaps, and how to address those?  Will there be any kind of handouts or takeaways (outside of presentation) for the audience?  Do you address anything in your presentation around 'how much is enough testing', story level / release level, etc?

     

    Best,

    Joel

    • Pradeepa Narayanaswamy
      By Pradeepa Narayanaswamy  ~  1 year ago
      reply Reply

      Hi Joel,

      Thanks for your feedback and questions. Please see my responses to your questions.

      Will you also talk about skills, gaps, and how to address those?

      Yes, i will be talking about T shaped talents with respect to this question. T shaped people will be very effective when it comes to cross-functional teams. And as a team you need all the talents collectively to produce a superior quality product. Even if your team lack in some, as a team you need to figure out on how to fill that gap. Sounds very generic, but i believe that this goes well for testing as well.

      Will there be any kind of handouts or takeaways (outside of presentation) for the audience? 

      Haven't really thought about this. Are we required?

      Do you address anything in your presentation around 'how much is enough testing', story level / release level, etc?

      In my initial thoughts i am not addressing this in specific. But i can definitely insert a slide or 2 to talk about this topic.

       

      Thanks again. Please let me know if you have any further questions or need additional clarification.

       

      With Warm Regards,

      Pradeepa

       

  • Naresh Jain
    By Naresh Jain  ~  4 years ago
    reply Reply

    Hi Pradeepa,

    I agree with you that this is an important question many organizations have. If you were to summarize in one line, what is your recommendation to deal with this crisis situation? Looks like you are suggesting "re-skilling." Is that the right approach? I'm not sure. As a community, I don't think we have consensus on this or any other approach. This is still being debated.

    I would suggest you turn this talk into an experience report and actaully share concrete details and specific data about your approach with the community. Cover what challenges you faced and how did you overcome them. This will clearly add value and is something people cannot debate about. Its stuff you've already done successfully.

    As it stands currently, I'm concerned that your current proposal might sounds quite basic and dare-I-say too theoritical to some of the audience. The audience is really interested in hearing first-hand experience report (successful or failed, does not matter.)

    • Pradeepa Narayanaswamy
      By Pradeepa Narayanaswamy  ~  1 year ago
      reply Reply

       

      Hello Naresh,

       

      Thanks for your feedback, Please see my responses below.

       

       I agree with you that this is an important question many organizations have. If you were to summarize in one line, what is your recommendation to deal with this crisis situation? Looks like you are suggesting "re-skilling." Is that the right approach? I'm not sure. As a community, I don't think we have consensus on this or any other approach. This is still being debated.

       

      First of all, I am NOT just suggesting re-skilling here. If I have to summarize in one line, this is what I would say- An asynchronous, collaborative, incremental way of testing in parallel to development as a cross-functional team. This idea, the spirit behind these set of things I mentioned are NOT debated any more. They are embedded in the Agile Manifesto and its Principles. It is the “how” we do these have been debated ever since.

       

      I would suggest you turn this talk into an experience report and actaully share concrete details and specific data about your approach with the community. Cover what challenges you faced and how did you overcome them. This will clearly add value and is something people cannot debate about. Its stuff you've already done successfully.

       

      I could deliver an experience report, but that is not my intention. I have collected all these details over many years working with many agile teams and it will not do justification to use just one example over the others.

       

      As it stands currently, I'm concerned that your current proposal might sounds quite basic and dare-I-saytoo theoritical to some of the audience. The audience is really interested in hearing first-hand experience report (successful or failed, does not matter.)

       

      In terms of being basic, Yes, that is the intention. Hence this is marked for the “beginner” level. On being theoretical, Not exactly, I will be giving real world examples that is grounded on the Agile Principles.

       

      Hope this helps. Let me know if you have further questions.

       

      -Pradeepa

       

       

       

       

       

       

       


  • Liked Tathagat Varma
    keyboard_arrow_down

    Tathagat Varma - Agile, Management 3.0, Holacracy...what next?

    Tathagat Varma
    Tathagat Varma
    Founder
    Thought Leadership
    schedule 4 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
    Founder
    ConfEngine.com
    schedule 4 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.

  • 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 Abhilash Chandran
    keyboard_arrow_down

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

    20 mins
    Experience Report
    Intermediate

    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.

  • Liked Colin O'Neill
    keyboard_arrow_down

    Colin O'Neill - Achieving Enterprise Agility with the Scaled Agile Framework...and Have Fun Doing It!

    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

    Tathagat Varma - Designing agile feedbacks for agile learning - an experience report

    Tathagat Varma
    Tathagat Varma
    Founder
    Thought Leadership
    schedule 4 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    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.

  • Liked Prasanna Vaste
    keyboard_arrow_down

    Prasanna Vaste - Should we stop using Story Points and Velocity?

    Prasanna Vaste
    Prasanna Vaste
    Business Analyst
    Thoughtworks
    schedule 4 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    On Agile projects we estimate user stories in order to allow team to

    1. 1. Track velocity
    2. 2. Decide scope for the Iteration
    3. 3. Help Prioritize stories
    4. 4. Help Release planning

    But most of the time we faced issues with estimation. It takes lot of time in estimating user stories, managers tend to relate estimate to number of days it will take to complete the story, in some teams estimate is equal to deadline. Most of the teams which use story points to estimate the work face these issues. This results in lack of confidence on development team when stories are taking more time to complete.

    Here I am going to talk about better alternative for both the suppliers of software products (financially and ethically) and their customers (internal and external). This alternative is being used in real companies delivering to real customers with great effect where team uses count of stories completed in an Iteration as measure of progress. Will talk about how this alternative can be used to track velocity, prioritize stories, planning Iteration and for release planning.

    I will share some exmples from my past projects where team did not use story points/velocty but used count of stories completed in Iteration to measure progress and also as best indicator of future performance.

  • Liked Allen Rutzen
    keyboard_arrow_down

    Allen Rutzen / Sunil Roy - Nokia Maps Agile Journey.....(Agile Transformation, Scaling and Overcoming Challenges)

    45 mins
    Talk
    Intermediate

    We (at Nokia Maps Division) began our Agile Journey in 2009, with a Top Down approach for Agile Transformation. The formation of an Agile Working Group (with members having Agile experience behind them) at two major sites was instrumental in shaping the transformation and scaling and also overcoming the challenges from time to time.

    The challenges were huge, but our spirit was bigger, and the high level strategy was decided. Interestingly, the Agile Working Group itself ran the whole Transformation and Scaling program using Agile values and Scrum frame work. Scrum was also used as the preferred framework for the agile projects (after success in our pilots), except where Scrum would not work. Kanban or hybrid methods were used in those few teams.

    What were the challenges faced, and how did we overcome them? What values helped us in our transformation journey?

    How did we migrate to the Scaling phase? What helped us in scaling and stabilizing?

    Can we rest easy now? Of course not!

    What are the next steps? And of course, the challenges ahead?

    Let us share our Nokia Agile journey with you, and help you all be successful too, in your Agile journey!

  • Liked Tathagat Varma
    keyboard_arrow_down

    Tathagat Varma - Agility @ The Scale of Busine$$

    Tathagat Varma
    Tathagat Varma
    Founder
    Thought Leadership
    schedule 4 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 Naresh Jain
    keyboard_arrow_down

    Naresh Jain - SAMPLE PROPOSAL - Product Discovery Workshop

    Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 4 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 Neil Killick
    keyboard_arrow_down

    Neil Killick - The Guessing Game - Alternatives to Agile Estimation

    Neil Killick
    Neil Killick
    Lead Agile Coach
    MYOB
    schedule 4 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 Pradeepa Narayanaswamy
    keyboard_arrow_down

    Pradeepa Narayanaswamy - WORKSHOP- Defining Behaviors as a team

    45 mins
    Workshop
    Intermediate

    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.

     

     

  • Liked Pradeepa Narayanaswamy
    keyboard_arrow_down

    Pradeepa Narayanaswamy - Agile Testing- What is my success mantra??

    45 mins
    Talk
    Beginner

    As more and more organizations are transitioning to agile, it’s inevitable that Agile testing is not just a concept any more. It is also not just about placing a tester in every team. What is so radically different now? How to be successful at agile testing? How to be an effective cross-functional team that embeds and honors all specialties including testing?

    In this presentation, I am going to share my teams’ success with Agile testing and how we incorporated these 3 aspects – people, process and tools/techniques. This talk will benefit any members in an organization who has a stake in the product quality. It is also highly beneficial for those agile testers (from aspiring to veteran) to understand the 3 main aspects as it relates to testing and why we need to embrace- not just one, not two, but all these 3 aspects to be successful in Agile testing. 

     

     

  • Liked Abrachan Pudusserry
    keyboard_arrow_down

    Abrachan Pudusserry - Manager and Photographer

    Abrachan Pudusserry
    Abrachan Pudusserry
    schedule 4 years ago
    Sold Out!
    20 mins
    Talk
    Advanced
  • Liked Kanchan
    keyboard_arrow_down

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

    Kanchan
    Kanchan
    Portfolio Manager
    McKinsey&Company
    schedule 4 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 Shrawan Gaur
    keyboard_arrow_down

    Shrawan Gaur - Learn from Mistakes, Retain Your Strong Holds: Sprint Retro: Do As WE Do at John Deere

    45 mins
    Talk
    Beginner

    As the 12th Agile Principle states : "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.", it is quite easy to understand the importance of continuous evolvement which involves retaining learning and corrective actions.

    John Deere has started its Agile journey in year 2010 and since then has gone through various phases of transformation. Scrum teams has learnt alot and are continuously learning. Retrospection is one of very important scrum ceremony which paves path for team to advance in right direction.

    Here, I will demonstrate some retro techinques and its applications according to sprint work.