Retrospectives with large projects and (or) multiple teams

schedule Feb 27th 11:30 AM - Jan 1st 12:00 AM place Esquire

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.

 
15 favorite thumb_down thumb_up 11 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

In the first 15 minutes I will be discussing the following topics. I briefly explain the format of the large retrospective followed by our group.

  • Do's and Don'ts of Retrospectives
  • Typical Agile retrospective lifecycle with single team
  • Retrospective with large projects ( multiple teams)
    1. Select a venue
    2. Setting the goal

                                                               i.      Do and don’ts

                                                             ii.      Working arrangements

                                                            iii.      Aim  of the discussion

  1. Gather data

                                                               i.      Find important email, documents , notes which can be used  for discussion

  1. The Act

                                                               i.      Create a timeline for events

                                                             ii.      Explain the events

                                                            iii.      Note down the important points

  1. Discussion

                                                               i.      Categorize topics

                                                             ii.      Create sub teams

                                                            iii.      Present ideas

                                                           iv.      Vote for the hot topics

  1. Presentation

                                                               i.      Summarize the output

                                                             ii.      Reveal the hot items

                                                            iii.      Circulate the key leanings

                                                           iv.      Circulate the action items and method to track them

  1. Toolkit for Large Retrospectives

Next 5 minutes I will  disuss some of the challenges faced while implementing this, followed by Q/A session. 

Learning Outcome

  • Understand the do and don't of retrospectives
  • Knowledge/Understanding of a typical framework for doing retrospectives with a large audience or multiple teams

Target Audience

Scrum Teams members, Scrum Masters, Product Owners, Agile Coach, Project Managers, dev Managers

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Naresh Jain
    By Naresh Jain  ~  4 years ago
    reply Reply

    Hi Abhilash,

    This is an important topic to many teams in India. We are sure many people would be interested in hearing your experience about how you scaled retrospective and what challenges you faced.

    Would you be willing to move this to the offshore-distribtued agile theme? We think its a better fit under that theme. Also would you be willing to change the format to a 20 mins experience report? We are only able to accomodate a 20 mins session at this point. 

    • Abhilash Chandran
      By Abhilash Chandran  ~  4 years ago
      reply Reply

      Naresh

      I have updated the proposal for a talk of 20 minutes

       

       

  • Ellen Grove
    By Ellen Grove  ~  4 years ago
    reply Reply

    Hi Abilash

    I think you've got an interesting story to tell about scaling up retrospective practicees (which in my mind are a critical part of any agile adoption - it's about the learning cycle!) Would you consider presenting your story as a 20 min experience report focusing specifically on the experiences of the large team retro?  The presentation will be accompanied by a 2-3 page written report of the experience.

    I'd also like to know more abour your presentation experience.  Do you have a link to a video or slides?  Or perhaps you could video a very short elevator-pitch for your talk (30s-1min) and share it with the review team? (No slides, just you talking about the esssence of your story).  This would help the team have a fuller picture for assessing your proposal.

    Thanks!

    Ellen

    • Abhilash Chandran
      By Abhilash Chandran  ~  4 years ago
      reply Reply

      Ellen

      I can present a 20 minutes experience report also on this topic. By the time I present this topic, I will have few videos of the session. Before that I will try to get a small video "elevator pitch" 

      Regards

       

      Abhilash

  • Archana Joshi
    By Archana Joshi  ~  4 years ago
    reply Reply

     

    Abhilash, Have you implemented this approach in practice? You have mentioned the audience will also form multiple teams and do retrospective. Is there a particular topic on which audience is supposed to retrospect on coz in workshops there will be diverse audience and hence finding a common thread on which all can provide inputs for retrospective is important.

    • Abhilash Chandran
      By Abhilash Chandran  ~  4 years ago
      reply Reply

      Archana

      Last time we did this, it took us two days to complete all the ceremonies. In the proposal I have listed the format followed by us. Today also I was having a discussion with my scrum masters to do a combined retro for all the teams after the current release.

      I see your point about the need of a common topic. We can do a retro on the agile conference itself! Surely we can find some common topics which everybody can contribute. My intension is not to have a full fledge retro on the topic but on the format we have used successful with large audience.

      Best Regards

       

      Abhilash

      • Venkatraman L
        By Venkatraman L  ~  4 years ago
        reply Reply

        Hey Abhilash,

        Looks like a great exercise across 10+ teams. Can you elaborate if you indeed feel a 2-day retrospective is the best way to go ? Or have you guys found a better way or more optimal way of doing this multi-team retrospective ?

        Thanks
        Venkat

        • Abhilash Chandran
          By Abhilash Chandran  ~  4 years ago
          reply Reply

          Hi Venkat

          This is a new exciting territory for us.

          I am also implementing a mini version of this which can be competed in a single day.  I reserve this for multi-team from same department or project.

          I will go for two day retrospective

          ·          If I have team (or people) from different departments

          ·          Number of team is greater than 5 (7 member team)

          ·          People haven’t met vey often ( on shore/offshore or in different buildings)

          With more people we will have more ideas and suggestion to brainstorm. A two day retrospective helped my team to come up with some creative solutions. This was the first time many had a formal retrospective also.

          Ultimately it depends on the people attending the retrospective. If people are coming from the same background then the discussion becomes easy.

          Even though I suggest 1 -2 day retrospective, the actual preparation lasts couple of days (or more). Once I set a date, I usually ask the team to get all the relevant data regarding the topic we are going to do retrospective.

          Regards

           

          Abhilash

  • Karthik Sirasanagandla
    By Karthik Sirasanagandla  ~  4 years ago
    reply Reply

    Hi Abhilash,

    A few things that I wish to know from you:

    • Have you delivered this workshop before?
    • If yes, do you mind sharing when and where you presented, the presentation deck, video etc. and the number of participants that attended your workshop.
    • If no, do you mind sharing links to your previous work with regard to talks, demos, workshops, etc. anything that gives us an idea of how you think through things.

    Cheers, Karthik

    • Vijayanand Nagaraj
      By Vijayanand Nagaraj  ~  4 years ago
      reply Reply

      Hi Abhilash,

      I am unable to comprehend the problem statement in your abstract, I have few questions on the following statements, kindly clarify them.
      1. "The problem starts increasing exponentially when many teams work on a single product. All the teams have ideas to improve the process and production." 

      Even if many teams are working on same product, still each team is standalone and will have there own sprints, have their own sprint goals, there own user story commitments for the sprint, create their own sprint backlogs, etc and in the end all teams have to retrospect for their own sprints and improve the process of their own sprints.
      However, from your statement it looks like instead of limiting themselves to their own sprints, each team is retrospecting for the entire project or product. Is this how it is?


      2. "One team may have an entire opposite idea of another. How to bridge this gap?"
      The scope of the retrospective for each team will be their current sprint and what happened during their sprint will vary from team to team hence the ideas for improvement will definitely be different or may be opposite. So where is the gap to bridge?

      • Abhilash Chandran
        By Abhilash Chandran  ~  4 years ago
        reply Reply

        I have updated the proposal with a scenario which led us to do this type of retrospective. 

        Each team may have a separate sprint goal and they might be doing an effective sprint retrospective but the program which this team, is part of  might be losing focus. Multiple teams in this program may lack a proper synchronization. Just like Scrum of Scrum, this gives a platform for all the related team to do a common retrospective at a program level as a big single team. There is no harm in individual team coming up with opposite retro actions if they contribute to overall health and progress.

         

        Assume that two teams A & B are working on two separate sections/modules of a big project. They are independent teams, can have their own definition of done. Suppose because of lack or skills/understanding team a decides to do their internal implementation in a different way to that of team B. There are no issues as long as the implementation works.  But at a program level this might not be the most efficient way of implementing this feature. This deviation can cause higher maintenance, poor performance and even in certain extreme cases non-conformance to certain standards.  I have seen this happening to new teams (and some old) which is added to the existing large programs. When we brought these teams together, it led to a positive flow of information and exchange of ideas.  Team themselves took some corrective action from the subsequent sprint to avoid that mistake again. 


    • Liked Victoria Schiffer
      keyboard_arrow_down

      Victoria Schiffer - Agile Coaching? Sure thing! What about Life Coaching in Agile Thinking?

      Victoria Schiffer
      Victoria Schiffer
      Agile Coach
      SEEK
      schedule 4 years ago
      Sold Out!
      45 mins
      Talk
      Beginner

      I love being around awesome people, who build great products customers desire. 
      I love learning from and together with these amazing minds. 
      I love creating the right environment for teams to flourish. 
      I love change, and learning from new experiences. 
      I love working in Agile environments.

      How about you? 
      I bet there are some elements of this list why you're in Agile, too. And you can probably add even more elements to it.

      The Agile Manifesto states amongst others individuals and interactions, customer collaboration and responding to change.

      In our everyday life doing Agile we already respect these aspects in many ways. 
      But do we practice what we preach as best we can?

      I'd like to challenge your current way of thinking about people and processes. 
      I'd like to challenge you to focus on you, before you focus on others. 
      I'd like to challenge your current way of reflecting. 
      I'd like to inspire you to go different ways. 
      I'd like to inspire you to inspire others.

      In Agile we're already good in improving our processes and creating well performing teams and hence building the right things in the right way. And in the Agile Manifesto's communication and collaboration piece we can even get better.
      "You have not yet reached the limit of what you're capable of!" means we can always further improve. And we do follow this idea in our Agile processes, too, through continuous feedback (Retrospectives) and improvement.

      And why not take it even further? Why not go "Beyond Agile"?!

      Here's where aspects of Life Coaching come in handy: through also understanding and improving ourselves (how do we interact with people due to how we perceive our environment) we will even further improve communication and collaboration.

      Life Coaches believe our clients know the answer. And even if Agile Coaching is slightly different than Life Coaching, I see it as very relevant in Agile Coaching, too. If we apply this in Agile, instead of giving our clients (team, colleagues) the answers, asking them powerful questions to help them be more aware of what's happening at the moment, they will find their answer for it and will have a much better commitment to making the change for themselves, their teams and the company. It's not for us to TELL them what to do, but to ASK them what's going on for themselves. Here's where I see a huge chance for improvement.

      In my session I give lots of examples on how to link Life Coaching ideas to our Agile work environments. I've given the session at LAST Conference Melbourne and at the Agile Coaching Circles Meetup Melbourne. The audience was engaged and the attendees were very happy about having some new ideas on how to improve their daily work life.

      Come along to be inspired by Life Coaching and thus to benefit our Agile Thinking!

    • Liked Giovanni Asproni
      keyboard_arrow_down

      Giovanni Asproni - Methodology Patterns: a Different Approach to Create a Methodology for Your Project

      Giovanni Asproni
      Giovanni Asproni
      Consultant
      Asprotunity Limited
      schedule 4 years ago
      Sold Out!
      90 mins
      Tutorial
      Advanced

      In the software world we have been looking for “The Methodology” to solve our software development sorrows for quite a while. We started with Waterfall, then Spiral, Evo, RUP and, more recently with XP, Scrum, Kanban, DAD, SAFe (there are many others, but, their impact, so far, has been limited).

      In this tutorial, I'll show why this search for the holy grail is bound to fail--each methodology has strenghts and weaknesses that make it suitable only in some contexts--and I'll describe a different approach based on patterns and pattern languages, that teams can use to create their own methodologies to suit their specific needs, which, in my experience, has a higher chance of success. 

      The approach is based on the observation that all the practices used in all modern methodologies--e.g., user stories, use cases, team self organization, TDD, unit testing, acceptance testing, continuous integration, iterative and incremental development, etc.--come from the same set. Different methodologies just mix and match them differently. All those practices can (and many have already been) described as patterns whose relationships with each other form a set of pattern languages.

    • Liked Naresh Jain
      keyboard_arrow_down

      Naresh Jain - Scaling XP Practices inside your organization using Train-the-Trainer Model

      Naresh Jain
      Naresh Jain
      Founder
      ConfEngine.com
      schedule 4 years ago
      Sold Out!
      90 mins
      Workshop
      Advanced

      How do you effectively scale skill-based, quality training across your organization?

      Over the years, I've experimented with different ideas/models to scaling skill-based training across an organization. In the last 4 years, I've pretty much settled down on the following model. Its very useful when mentoring teams on skills like Test-Drive-Development (TDD), Behavior-Driven Development (BDD), Product Discovery, Writing User Stories, Evolutionary Design, Design Patterns, Problem Solving, etc. I've successfully implemented this model at some very prominent fortune 500 enterprises.

      The goal of this workshop is to explore what other successful models organized have used to scale skill-based training in their organization.

    • Liked Mike Burrows
      keyboard_arrow_down

      Mike Burrows - Kanban through its Values: An Agenda for Scale

      45 mins
      Talk
      Intermediate

      Introducing the Kanban method through a 3-layered value system - a familiar core that stimulates and drives change, a middle layer that is about direction and alignment, and a protective outer layer of discipline and working agreements.

      This humane, values-centric model aligns Kanban with the concept of the Learning Organisation and suggests ways to seek resonances with other methods. It has some practical benefits too: it can help us engage more effectively with the organisation as it currently is; it encourages us to self-reflect on our effectiveness as agents of change; it provides a convenient framework for the capture of stories.

    • 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 Evan Leybourn
      keyboard_arrow_down

      Evan Leybourn - From Lean Startup to Agile Enterprise (beyond IT)

      45 mins
      Talk
      Beginner

      Traditional models of management and corporate governance are failing to keep up with the needs of the modern economy. Change, both technological and cultural, is occurring at faster rates than ever before. In this climate, modern enterprises will live or die on their ability to adapt. This is where Agile, and Agile Business Management, come in. Agile is change; changing how you think, changing how you work and changing the way you interact. This is important whether you are a software developer or a CEO.

      In this presentation, Evan will provide engaging and enlightening case studies of Agile beyond IT; from lean startups to large enterprises. These will be reinforced with practical approaches for the leadership of teams, divisions and businesses. 

      Taking the successful concepts and methods from the Agile movement and Evan's new book, Agile Business Management is a framework for the day-to-day management of organisations regardless of industry, size or location. We will discuss processes, techniques, and case studies for the 4 key domains from Agile Business Management;

      1. You, the Agile Manager - What makes a good manager and how do their responsibilities change?
      2. Integrated Customer Engagement - Collaboration and communication techniques to build trust and deliver Customer needs efficiently, with minimal waste, and to everyone's satisfaction.
      3. The Structure of an Agile Organisation - Efficient, transparent and collaborative techniques to manage empowered staff.
      4. Work, the Agile Way - Managing all types of business functions, from software, HR, finance to legal, by using Just-In-Time planning and Incremental or Continuous Delivery processes.

      Ultimately, the goal of this presentation is to make you think about your role as a leader. 

    • 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 Herry Wiputra
      keyboard_arrow_down

      Herry Wiputra - Crossing the T's and Dotting the I's

      20 mins
      Experience Report
      Intermediate

      The term "cross functional team" has been made popular by the Agile movement. In cross functional team, we put people with different roles to work together for a common goal/purpose.

      I have seen this worked really well in many agile teams. People are no longer on silo and everyone have better understanding what each other's role is and consequently, what each other do. This leads to better self organising within the team.

      However, I strongly believe we can take this concept to the new level. The concept of cross functional team should be extended to not just the team but also to the individuals within the team. Scott Ambler wrote an essay on "Generalising Specialist". The term T-shaped developer was introduced by Mary and Tom Poppendieck in her famous book "Lean Software Development". By nature, people don't like to get out of their comfort zone, hence the tendency to keep working in area that they are familiar with. When leaders can create an environment where everyone is encouraged to learn, grow and make mistakes, amazing things can happen.

      In my experience leading teams, I have witnessed many transformations that enabled individuals to go beyond their traditional role, such as a manual QA assuming Scrum Master role, a BA doing deployment, a developer doing QA for a story, etc. Not only this enablement help develop the individuals to widen their horizon and skillset, it also helped the productivity of the team through better collaboration. When a team reach this stage, we no longer have problems such as "The QA has nothing to do because there are no stories to test", "The developers have nothing to do because the cannot keep up", "The deployment took longer than expected because the Ops person was not aware of the special configuration".

    • 45 mins
      Talk
      Intermediate

      ‘One bad apple soils the barrel’ is a very true saying even in an Agile environment. Not identifying and managing poor behavior and performance can completely undermine any Agile transformation effort.

      How can Leaders, both within and external to Agile teams, set higher standards of accountability and hold people to it? Is self organization, peer pressure and the wisdom of the crowd enough to handle the wiles of organisational psychopaths?

      The fact remains that most teams will have a few difficult personalities and underperforming members.

      Agile is seen in many senior management circles as a softer, less accountable, way of working. Is that true?

      This talk will delve into how the human psyche works, drawing on latest studies in neuro and psycho analysis, combined with Harvard studies, to outline the best ways to define, identify and deal with ‘bad apples’ in an Agile environment while honouring the values and principles of Agile

    • Liked Archana Joshi
      keyboard_arrow_down

      Archana Joshi / Sheshadri Shekhar - How do I know if Agile is working for me or not? – An Executive’s Dilemma

      20 mins
      Experience Report
      Intermediate

      As Agile coaches, several times when we talk to the Sr. Management in a company to taking agile to a bigger level and adopt it across their business units a common response we get is "I have seen agile working for our project teams. I am also in midst of an agile transformation where we are applying it in large programs. But how do I know the transformation is helping me achieve my goals at an organizational level. Our organization typically tracks executives on finance, people & delivery parameters. In an agile context, how do I ensure that I am on track with the executive-level dashboard (finance, people and delivery)?" As part of this session, we plan to share our experience of how "Balance Score Card" technique was implemented at one of the financial services company following agile. By using concept of balance score card we were able to map the agile goals with the IT organization goals and ensure that the agile methods were giving the desired results.

    • Liked Natalie Warnert
      keyboard_arrow_down

      Natalie Warnert - Confessions of a New ScrumMaster

      45 mins
      Workshop
      Beginner

      So, you just got out of your CSM class, overflowing with your newfound Scrum knowledge and renewed faith in software development practices. You're ecstatic to share your new view of the world and show how Agile can benefit your organization, and you can't wait to get started. But, in your first Agile project, you meet resistance, opposition, and worst of all, modified Scrum practices. What's a ScrumMaster to do?

      Don't lose hope! You're definitely not the first ScrumMaster to meet these barriers, and you're not alone. I've encountered these situations in projects and have some tips to make the transition to Scrum easier on the team, the leadership, and you. Learn to overcome these problems in this interactive workshop and you become a better ScrumMaster and will help lead the team to the high performance you know they're capable of!

    • Liked Ram Srinivasan
      keyboard_arrow_down

      Ram Srinivasan - The Shared Mind: Essence of Interpersonal Neuroscience

      90 mins
      Workshop
      Advanced

      Why are some leaders socially adept while others show lack of maturity? Why some teams are high performing teams and others just are not? Ever wonder why people behave the way they behave? I did too.  As a coach, my quest to help teams collaborate better (and organizations create great culture) took me through an extraordinary journey through the maze of gamification, motivation, psychology, coaching, system thinking, organizational development and group process, and interpersonal neurobiology. Through this journey, I discovered why Lean/Agile principles are brain-friendly and how they help teams and organizations. In this session I share some of the insights that I have gained applying some of these principles coaching teams and organizations. You will also learn how you can share these concepts with other and gave teams and organizations a “language” to have crucial conversations, thereby increasing the system’s (team/organization) self-awareness.

    • Liked Aruni Siriwardene
      keyboard_arrow_down

      Aruni Siriwardene - The Waterfall enthusiast and The Agile Contract

      45 mins
      Talk
      Intermediate

      A traditional software development project entails specifics around elements in or out of scope, tied up to deliverables, all ensconced within specified estimates and timelines, subjected to legal clauses for everything from acceptance to indemnities. For Agile contracts, the boundaries of legal intervention must stand; merely due to the marriage of parties when a project is executed; the definitions of boundaries must be established be it scope, budget or timeline and all standard deliverables from a traditional project stands; yet, the execution is as diverse as chalk and cheese.

      What are the key criteria to be aware of when we define Agile contracts; as in typical agile projects, should the client be involved in mutually drafting the contract? How much legal intervention can we allow? What happens to deliverables and expenses when delays occur and scope boundaries are reduced? Can blame be apportioned to an extent that each party will have to indemnify themselves?

      An Agile contract needs to reflect the nature of the engagement; no template contract with standard clauses can be coaxed upon a true agile project. In line with the Agile principles and values and targeted to the agile manifesto; Agile contracts should be just that – Agile!

    • Liked Abhilash Chandran
      keyboard_arrow_down

      Abhilash Chandran - Workshop- Agile user story and Behavior Driven Development (BDD) using Gherkin

      90 mins
      Workshop
      Beginner

      In this session I will introduce the audience to the concepts of Gherkin language. Gherkin is a popular language used to encapsulate the requirements in agile world.

      This was successfully implemented in our group across India & USA. I will go through this case study also.

       

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

      Abhilash Chandran - Agile Appraisal: Sprint Iterations for Appraisal reviews

      45 mins
      Case Study
      Beginner

      Appraisal reviews are always hard. Traditionally it is done once a year. The manager and employee undergo a tough period of reviews, discussions and ratings. At the end no one is happy.

      • Manager
        • Manager is forced to provide a feedback of an entire year in few minutes.  
        • Because of time constraints and lack of useful data, a constrictive feedback is not given.
        • In most of cases this ceremony is reduced to mere salary negotiations.
      • Employee
        • Employee feels cheated because of lack of any concrete feedback
        • Employee is not able to proactively discuss his/her career objectives and create a proper plan to bridge the talent gap.

      In this talk I will discuss some of the approach we are trying to follow in our group to align appraisal feedback also along with agile sprints.  

      I will present the experience report of how we are converting the age old waterfall appraisal process to Agile. I will discuss the need for this change, the general idea and the challenges we are facing.

      In this new way of appraisal management the focus is on the individual. Just like we have a Scrum/Kanban board, each employee will have a talent and improvement board. Instead of developing a product, the focus is to develop an individual. Like the scrum there are Ceremonies

      • Release planning – Organizational agenda
        • Decide Group & team goals
      • Sprint planning
        • Work with each team members to identify some “traits”/action points to improve
      • Review
        • Review the outcome
      • Retrospective
        • Based on the outcome revisit the individual goal & do a re-planning
    • Liked Rituparna Ghosh
      keyboard_arrow_down

      Rituparna Ghosh - Driving Continuous Improvement for Excellence through Lean Agile

      45 mins
      Experience Report
      Advanced

      Despite being a CMMI Level 5 company, in the early 2000 business exigencies prompted Wipro to look towards a sustainable continuous improvement drive.  Wipro started it Lean-Agile transformation initiative way back in 2004-05. In the initial days, the euphoria of a new subject helped in the adoption. The evangelists came from the ranks and their success stories helped us in broadbasing the initiative. In the past decade or so the organization has grown 5 fold – not to mention the increase in the complexity of operations. The early adopters and evangelists too were not in a position to take ahead the journey. They often took up different roles either within the organization or externally. Knowledge became tribal in nature without there being a continuous cycle for continuous improvement. 

      This is a live case study of how the organization took ahead the transformation initiative and breathed fresh life into it, in an environment which was much more challenging. We built a cadence of Continuous Improvement by

      1. Adopting a SuHaRi model of Inform-Perform-Transform  
      2. Aligning the roles and responsibilities to aid Continuous Improvement
      3. Building a rewards and recognition programme for increased participation
      4. Involving Senior leadership to drive the cultural change by aligning policies and principles
      5. Measuring engagement and effectiveness – not only in terms of measurable metrics, but also in terms of intangible benefits
    • Liked Pradeepa Narayanaswamy
      keyboard_arrow_down

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

      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 Howard Deiner
      keyboard_arrow_down

      Howard Deiner - Contracts in the Age of Agility

      45 mins
      Talk
      Intermediate

      “Fixed price, fixed deliverables, and fixed schedule” contracts are just about the worst way to write contracts involving software, yet they are the most popular – so what are some techniques to use to fix that?

      Organizations that perform professional services for software development or develop software on a work for hire basis are usually engaged bound by extensive contracts.  These contracts are typically characterized as “fixed price, fixed deliverables, and fixed schedule.”  These, of course, are the vertices of the “Iron Triangle of Software Development” and foreshadow a poor outcome due to issues that make the requirements gathering and project estimation phases that precede contract negotiation so prone to error.

      Given this, the question becomes one of “how can I engage clients in a way that allows us each to achieve our goals?”  If Agile and Lean methods are the status quo for good development practices, how can I write contracts for development services that embrace this mindset and let each side achieve it’s goals better?  This lecture and roundtable explores the many facets of this question and provides the attendee answers that they can use going forward.

    • Liked Howard Deiner
      keyboard_arrow_down

      Howard Deiner - The Agile PMO - Creating A Lean Organization from the Inside-Out

      90 mins
      Talk
      Intermediate

      For many, the idea that you can transform an organization from the PMO outwards seems odd, if not impossible.  But my experience says that this is becoming a trend that more and more clients are asking advice for. 

      We know that for an Agile transformation to work, we need to engage not just the Delivery Teams to approach work differently, but we need a change agent high in the organization to support that change in mindset.  I’ve always found it difficult to find that right person in an executive leadership role who is willing to have the courage to “bet the company” on a new and unproven approach such as Agile and Scrum.  As coaches, we tend to start “pilot” projects, and hope that traction will occur “once everyone sees the great results that we get.”  But I think that this approach is fraught with peril of not getting the right project to start with, not getting the right results immediately, and not motivating people by seeing results from a process that they are not comfortable with.

      I think I’ve come upon a new approach that works better.  Instead of trying to “sell” Agile at an Enterprise level, embrace pure Lean principles high in the organization and work with the PMO leader at the organization.  Once they are comfortable with ideas such as “more leadership and less management”, “shorter concept to cash cycles”, “enabling Lean Startup mentality for disruptive product development”, “always looking for the elimination of waste”, “exploiting variability through appropriate cadence control and appropriate utilization rates”, “delegated authority”, “continuous improvement”, and “rolling planning”, the PMO becomes a terrific agent for instituting change, because they are usually already endowed with the right responsibilities and accountabilities that can push the organization forward.