I was part of a Large Scale Agile transformation in my organization and I was one of the Agile coaches there. As part of transformation we have created LeanOps teams to manage the technical debt, production incidents with a focused concentration. This article covers the following:

 

- Why the trasnformation required?

- What are the structural changes implemented?

- LeanOps inception

- Lean Ops working Model

- Challenges with the LeanOps

- How we addressed those challenges?

- Goal oriented approach

- Q & A

 
18 favorite thumb_down thumb_up 12 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

It will be a PowerPoint based presentation

Learning Outcome

Audiance can learn the practiccal insights of Lean and Kanban implementation from this session

Target Audience

Scrum Masters, Lean practitioners, Agile Teams, Managers

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Tathagat Varma
    By Tathagat Varma  ~  2 years ago
    reply Reply

    Vijay - Can you share more perspectives on what stage of the development did you organize this team? Was it a 1.0 effort that was reorganized as such, as an existing product already in product where you reorganized LeanOps to address some of the sustaining issues, etc.? Also, the last alide has metrics on a few of the elements. Would be great to have some more data points, e.g., on quality (I see one on new / closed bugs, but anything on turnarounds, regressions, reopens, etc.)

    -TV

    • Vijay Bandaru
      By Vijay Bandaru  ~  2 years ago
      reply Reply

      Hi Varma, thanks for your comment.

      We were working in waterfall model earlier, and we had a strategic decisoin made by management to switch to Agile. At that point of time we had planned to have both forward engineering teams and LeanOps teams. The team members from LeanOps will rotate for every few months so that they have a better understanding on the production environment and they share the learning with other team members and produce production ready code. So it will give them an idea on how to write good quality code and avoid production defects. Over a period of time everyone in the organization will get a clear knowledge on the production system. The products are already built over a period of time by the time we started Agile, there was also technical debt incurred in them so having a dedicated LeanOps teams would have made a better way to address that.

      Coming to the metrics point, we also have cycle time, SLAs on incidents and CRs, MTTD, MTTR metrics. If you suggest, I can add them also to the presentation.  

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

        please include whatever data you have to support your proposal. 

        -TV

        • Vijay Bandaru
          By Vijay Bandaru  ~  2 years ago
          reply Reply

          Varma,

           

          I have updated the slide deck with some more information and metrics also added. Please see the latest file and let me know if you have any further queries. Thanks

           

          Vijay

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

            Thanks Vijay. The review team would like to understand if you can present this case study / experience report in 20minutes. IF yes, pl update the proposal so that a final decision could be made.

            -TV

            • Vijay Bandaru
              By Vijay Bandaru  ~  2 years ago
              reply Reply

              Varma,

              That is fine, in fact the same I had presented in Lean India Summit recently in Bangalore. If the review team would like to watch the video I can provide the link. If they want me to present that is also fine. Please let me know what is conmenient to them.

              Vijay

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

                Thanks Vijay. Please update your proposal for a 20 mins experience report. Also please share the link to the video you mentioned.

                • Vijay Bandaru
                  By Vijay Bandaru  ~  2 years ago
                  reply Reply

                  Naresh, I will update the proposal by tomorrow to make it into 20 minutes experience report. Below is the link for my previous session on the same topic in Lean India Summit (it was a 45 minutes talk)

                  https://www.youtube.com/watch?v=UVkJAmb48i4 (From 10:15 minutes my session will start)

                  Let me know if there are any further queries

                  • Vijay Bandaru
                    By Vijay Bandaru  ~  2 years ago
                    reply Reply

                    Hi Naresh, I have removed some slides and make it a shorter version of 25 slides. I hope this will be fine for 20 minutes or max 5 more minutes. I have updated the new file LINK also in the proposal.

                    • Vijay Bandaru
                      By Vijay Bandaru  ~  2 years ago
                      reply Reply

                      Naresh, please check the updated version and get back if I need to provide any further details. Thanks

  • Prasad
    By Prasad  ~  2 years ago
    reply Reply

    Vijay

    Will you also be brining prespectives of how it got interfaced  and alligned with upstream teams and challenges around that.

     

    ~PP 

    • Vijay Bandaru
      By Vijay Bandaru  ~  2 years ago
      reply Reply

      Prasad, we have people rotate from forward engineering teams to Lean Ops teams for every two months. This will give all the members over a period of time to know the production environment and have hands on experience in managing that.


  • Liked Nanda Lankalapalli
    keyboard_arrow_down

    Happy Teams are key to successful agile transformation– Teams’ self-design

    Nanda Lankalapalli
    Nanda Lankalapalli
    schedule 2 years ago
    Sold Out!
    45 mins
    Experience Report
    Advanced

    Agile Teams' self-design is very important (though not very common) exercise in a large-scale agile transformation. In teams’ self design, team members choose their own teams in a collaborative way. This concept here is that the teams will gel quickly and excel when they are self-designed.

    In this session I am going to present my experience with such exercise. I facilitated at least 4 such sessions to help an organization as part of a large-scale transformation. The session is going to explain

    1. Benefits of Feature teams over Component teams
    2. Self-design of feature teams
    3. Pilot exercise of self-design of 2 feature teams.
    4. Large scale self-design of 4 product groups with 30 to 50 members per group.

     

  • Liked Krishnamurty VG Pammi
    keyboard_arrow_down

    6 X 2 Planning Errors in Scaled Agile Delivery Model

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    2 major errors across 6 agile planning events give us 12. Learning “what not to do”, can sometimes help us identify risks early in the cycle so that, as a team, we can effectively respond to these risks.

    Agile planning happens at multiple levels. In scaled agile delivery model, effective outcome of one planning event can influence the other significantly either positively or negatively.

    Come and learn top 12 experiential insights. These will help you alert your teams on “what not to do” during Scaled Agile Planning events. I tried capturing top 12 errors across 6 planning events namely Strategy Planning, Portfolio Planning, Product Planning, Release Planning, Iteration Planning and Daily Planning.

  • Liked Vijay Bandaru
    keyboard_arrow_down

    Scrum Master Experience Report

    Vijay Bandaru
    Vijay Bandaru
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    This presentation brings a different perspective for the Scrum Masters and helps them to become more powerful Scrum Masters through their enhanced soft skills. I am going to cover how the teams evaolve, how the change is resisted, how the teams behave, how Scrum Master can handle all these effective to make the teams deliver working software every sprint continuously.

    The information explained below is from my experience as Scrum Master and Coach. Below are the points that will be covered in the presentation:

    Primarily I am planning to cover the anti patterns that will push the teams back and where the Scrum Master can support the teams with his knowledge, experience and interpersonal skills. For example please find below some scenarios:

    1. In effective sprint planning: Team might miss some of the tasks while doing the sprint planning part 2 so they will anyway identify them during the development of the stories so these tasks take additional time which is not budgeted. So they will have to miss some stories which will impact the sprint goal. So I encourage the scrum masters to collect all such unidentified tasks on a separate colr sticky notes and during retrospective discuss with the team to see how much % of the capacity is gone for that tasks. At the same time are there any tasks in that list can be repeatable tasks (Eg: Code review) so this will help the team to come up with a tasks checklist which will help the teams to do effective sprint planning part 2 

    2. Partially ready stories pushed into the sprint: Sometimes product owners push the stories that are not fully ready and the team cannot say "No" in this case either the story gets changes during the sprint or it cannot be finished due to unknown factors. So Scrum Master to encourage the team to have a proper DOR (Definition of Ready) and get a working agreement between the PO and team so that they will work around it whilst they understand "Responding to change over following a plan"

    3. Cross functional behavior: Team generally does not want to become cross functional because they are fine with what they are. Scrum Master has to bring a change in their thought process and get them agreed to become cross functional. For this it takes time so SM has to also manage the management expectations with respect to set the expectation in the dip in productivity

    4. Pale retrospectives: This is another area where Scrum Master has to provide support to teams and get the liveliness and make the teams high performance teams

    5. Timeboxing: Most of the teams do not respect this important guideline. Again SM has to get the importance of this characterstic in to the teams and get them aligned towards this. So there are some examples which I can quote such as if different people arrive at different timings, how much time is wasted and how many times we need to recap on the points already discussed, how much gap created etc

    6. Stop starting and start finishing: This will cover to complete the stories/tasks that you are working before you pick up something. In general the teams pick up many items at a time and complete them close to 100% but not 100% so this will impact the sprint goal. In such case the SM has to provide inputs to the team to pick as few as possible but close them as soon as possible so this way the value delivery at the end of sprint is guaranteed

    7. Lack of importance for quality: In the hurry of completing the stories the team at times give less or no importance to the quality. So the probability of escaped defects or getting rejection for the stories is high. So the Scrum Master has to educate the teams to strictly define/refine/follow the Definition of Done for each story. I saw many teams having their DOD in the tools like VersionOne but not infront of their eyes. 

    8. I know when I see it: Information radiators. This will be the key for the teams to adjust their pace as per the principle #8. So creating big visible information radiators and updating the underlysing details frequently will bring attention in the team and they naturally tend to adjust their delivery mode as per the requirement 

     

  • Liked Prasad Kunte
    keyboard_arrow_down

    Implementing Agile Engineering Practices in Legacy Codebases

    Prasad Kunte
    Prasad Kunte
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    Afraid of legacy code? Don't be!!!

    Most successful product companies are confronted with the problem of legacy code.

    What is a legacy code?

    • A code which is in production for several years.
    • A super-complex, hard to understand code base, written by different set of developers. 
    • Outdated Technology stack.

    But the most hurting reality is:

    Lack of confidence in the code due to zero or poor test coverage.

    Due to this reality, developers are often scared to touch it. They have very little confidence that "their code change wouldn't break the existing application in production."

    Recently at IDeaS, we came across such situation, where we needed to enhance one of our products containing legacy code. We started looking into the code and soon figured out that it was developed in 2007, hardly ever touched (& still working in production :)). The original team, which has worked on this product, could not be traced anymore.

    As this product has expanded to attract new customers, we had to change it significantly in order to support new customer's specifications. We had to make sure that the product was backward compatible and supported the earlier specifications, while we enhance the new specification.

    One simple option was to COPY PASTE every single method which needs to be modified and use an if-statement to decide which method to call. This certainly seems like an easy method, since the chances of breaking existing code is very little. 

    Today we all know this is a BAD option!!!

    Instead, our team decided to refactor the existing code to support plug-and-play approach for different specification. But before we started refactoring code, we had to build a safety net of tests around the existing code.

    How do we put the safety net? Ideal way would be to implement the Test Pyramid first. But, that would have taken significant time to be ready with the pyramid before we start touching the legacy code. And obvious, we would have missed the business goals.

    What do we do?

    Instead of building the entire test pyramid, we decided to attack different layers of the test pyramid, one at a time. Along the way, we followed the following approach:

    1. Re-structuring the Project code-base
    2. Establishing a baseline database: After taking a dump from the production database, we cleared out surplus data from the DB and setup a seed database with automed scripts
    3. Creating/fixing the build script 
      1. Setting up an auto DB deploy tool and integrating it with build scripts
    4. Set up basic CI pipeline
    5. Write a few work-flow tests to capture the system's flow from user's point of view
      1. Find the inception point in the code from where we can exercise the code
      2. Restify the application at the inception point (one service at a time)
      3. Setup authorization for production and test environment
      4. Build minimal test-data set for different environment 
      5. Create a few work-flow tests via the inception point (Test itself should not be coupled with the underlying database or implementation level components)
    6. Write business logic acceptance test to capture various complicated business rules
    7. Test drive the new enhancement or bug fixes
    8. Every time we touch legacy code, refactor the code and improve test coverage at unit level

    This really helped us test driven the new code and implement all the layers of the test pyramid.

    If you've a similar situation, join us, as we share our experience on how to confront legacy code.

  • Liked Sophie Freiermuth
    keyboard_arrow_down

    Integrating UX into the Agile Development Cycle - A case study over 3 projects

    Sophie Freiermuth
    Sophie Freiermuth
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Beginner

    User Experience design is a product design discipline which sits throughout a product's lifecycle, from inception to development to maintenance and all the way to retirement. Waterfall enabled the discipline to have ample time and produce extensive design, in a "big design upfront" approach which rarely involved technical capabilities, and resulted in difficulties in build. The adoption of agile by product development team has offered UX a unique opportunity to work in a much more joined-up manner, and expend the design into the development, enabling the entire team to react to change.

    As a UX designer, I have over the last 7 years developped a solid appreciation of working embedded in an agile development team, and would like to share my experiences through 3 specific projects, sharing my learnings to help development team on-board the UX practitioner, their tools, practices and skills.

    This session will be a case study over 3 projects, highlighting the learnings and steps of the integration of UX into the development cycle. I'm taking Alistair Cockburn's sequence of SHU-HA-RI to detail the progress of my practice and will pay great attention to sharing sufficient context that my experiences and outcomes can be translated to your own projects and team setups.

  • Liked Madhavi Ledalla
    keyboard_arrow_down

    Deep dive into RETROSPECTIVES- how do we break the usual norms so that these reflections could be made thought-provoking ones!

    Madhavi Ledalla
    Madhavi Ledalla
    Jerry Rajamoney
    Jerry Rajamoney
    schedule 2 years ago
    Sold Out!
    60 mins
    Workshop
    Intermediate

             Retrospectives are the primary learning, reflection and readjustment techniques on agile projects. A good Agile team is always striving to become better than before. And an effective retrospective enables the team to sieze its opportunity to improve! 

    Retrospectives enable whole-team learning, act as catalysts for change, and generate action.

    R-> Realize where you are and where you want to be

    E-> Engage the teams in fruitful discussions

    T-> Team work to build “We over I” attitude

    R-> Relish the power of Inspect and Adapt cycles

    O->Openness and Transparency to make retrospectives efficient and effective

    In my view, this is not any new concept or a jargon the team needs to really master, but yes in reality sometimes it becomes challenging to keep the momentum lively all times! Over a period of time, we see these symptoms in a retrospective. 

    R-> Repeated issues pop-up

    E-> Engrossing & Engaging discussions are missing

    T-> Team present virtually, loses trust.

    R-> Routine stuff, nothing interests the teams.

    O->Observably gets boring over time.

    To catalyse conversations among team members, retrospectives need to be viewed from a different perspective. This presentaion talks about why the retrospectives efficacy fades off over a period of time and then talks about some very interesting techniques that I used with the teams to make these meetings lively!  Teams need to do out-of-box thinking and appreciate that these short gatherings need not  be done only by using the techniques or methods prescribed in the book but could be done by quoting some situational specific examples that would make the teams really think and speak!

     

  • Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    90 mins
    Tutorial
    Intermediate

    In order to achieve my goals, as a buyer of your product, I want awesome feature.

    AT: make sure your users stories don't get in the way.

    Users Stories, the tool teams use to break big ideas into small demonstrable deliverable, are easy to describe and challenging to write effectively. In this hands-on workshop you'll learn how to write great user stories that adhere to the INVEST principle. We'll learn various techniques to slice your stories using the vertical-slicing approach. We will discuss what elements should be included in the stories, what criteria you should keep in mind while slicing stories; why the size of your user story is important and how to make them smaller and efficient.

  • ShriKant Vashishtha
    ShriKant Vashishtha
    schedule 2 years ago
    Sold Out!
    60 mins
    Talk
    Intermediate

    Way back in 2008, when I started working in Agile, there was enough material available on Scrum and. However when it came to distributed aspect of it, people were still struggling with it. Based on working for years in this fashion, I realised that communication, trust, transparency and innovation are the core fundamental values towards successful distributed Agile implementation.

    In other words, as most of the problems were caused by softer aspects of skills (misunderstanding, miscommunication, non-availability of people, mistrust etc), humanizing the distributed team experience looked like the key for successful distributed Agile implementation.

    Based on working with distributed teams over the years, we discovered some distributed Agile patterns. Some of them got blogged from time to time. Those already available in form of blogs are as follows:

    The session is to share the these patterns and more (when to go for distributed Agile and when not etc)

  • Sriram Narayan
    Sriram Narayan
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Advanced

    Good engineering practices and fail-fast, iterative, low-ceremony processes help achieve team level agility. They are necessary but not sufficient to scale agility across the IT organization. In this talk, I'll address what else is needed and why. In particular, I'll address:

    1. Why plan-driven IT projects are a bad idea why we need value-driven projects instead
    2. Why a matrix org is a bad idea for IT and why we need cross-functional teams instead
    3. Why IT budgeting needs to change from being project-based to being team-capacity based
  • Liked Pooja Uppalapati
    keyboard_arrow_down

    Scaling Agile in a Mainframe Product Development Organization

    Pooja Uppalapati
    Pooja Uppalapati
    Ravindra Chebiyam
    Ravindra Chebiyam
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    Agile transformation in any organization will go through myriad of challenges that involves people, existing organization culture, technology/domain etc. Instead of seeing these challenges as obstacles, if you view them as opportunities to grow and improve, transformation will be more impactful and long-lasting. If neglected, the very same obstacles would severely damage the motivation and trust of employees.

    In this experience report we would like to walk you through the agile transformation journey in a Mainframe product development enterprise by unraveling the challenges and the remediation steps that has helped us in keeping this journey alive. Specifically we would like to touch upon 

    1. Self-organizing teams
      • Resistance to change
      • Culture shift
    2. HR
      • Lack of role clarity and
      • Effective R&R in agile space
    3. Agile Engineering Practices adopted in Mainframe product development
      • Unit test automation
      • Continuous Integration

    Along the presentation we’ll highlight few anti-patterns and the effects of ignoring them.

  • Sneha Kadam
    Sneha Kadam
    schedule 2 years ago
    Sold Out!
    60 mins
    Workshop
    Intermediate

    After revolutionizing the automobile industry, Lean principles have been successfully applied to different knowledge areas including software development. This workshop is intended to master Lean concepts like Waste, Push&Pull systems, systems thinking, Kaizen etc. & practicing cross-functional collaboration, self-organisation and safe-fail experimentation! In this interactive game, the participants will work in a small production lines, experiencing problems and applying Lean practices to overcome them.

  • Liked Sophie Freiermuth
    keyboard_arrow_down

    Prioritizing user stories: using value to users as a key criteria

    Sophie Freiermuth
    Sophie Freiermuth
    schedule 2 years ago
    Sold Out!
    60 mins
    Workshop
    Beginner

    Product development in agile is always at risk of favouring velocity and developer's skills.

    Favouring velocity means that when it's time to select stories, the team will elect to do many short stories to keep velocity on the rise, or stable.

    Favouring skills mean that easy implementation may be selected, or sometimes tricky solutions which will give the developper the satisfaction of solving a difficult problem.

    The outcome of the story's execution and value to users is an important criteria, and I'd like to introduce you in this session to a technique that helps prioritize against two sets of criteria: technical difficulty and value to users.

    Using Personas, a tool from product design which I will explain, and a simple grid, this technique makes prioritization incredibly easy - which then enables the team to focus on getting stories done, rather than figuring out which stories.

  • Liked Vijay Bandaru
    keyboard_arrow_down

    A retrospection on a Large Scale Agile Transformation

    Vijay Bandaru
    Vijay Bandaru
    schedule 2 years ago
    Sold Out!
    60 mins
    Case Study
    Advanced

    This is a case study prepared based on a large scale agile transformation happened at a product based company with over 5000 employees across 5 different locations. The transformation journey started with a clear vision and a timeline. There was a detailed plan and management buy-in for this transformation. I am presenting the key details of the transformation in this case study. This case study covers the critical activities carried out as part of the transformation and what went well and what went wrong during the transformation.

    “Challenges” are to be expected in any rapidly changing enterprise in a dynamic and exciting market, and they must be addressed to survive and thrive. The enterprises which stand out and set an example to the rest are the ones which handle these challenges in a different way leaving the foot prints for others to adapt these good practices and benefit out of them.  Healthy organizations continuously learn and re-invent themselves to go from good to great, and this is what we are striving to do.

     This is a practical Agile Transformation case study of an organization.  Our key drivers for change include:

    • Improve platform and gaming availability
    • Reduce feature cycle time
    • Reduce defects in production
    • Develop flexible, multi-skilled teams
    • Produce high value features first
    • Enhance cross site business collaboration

    We started our agile journey during September 2013.  In the presentation the following points would be covered:

    - Why did we choose transformation?

    - What was our roadmap of transformation?

    - What was our approach towards the transformation?

    - What were our challenges during the transformation?

    - Solutions to the challenges that we faced during the transfformation?

    - What tools we have selected?

    - What are the outcomes of the transformation?

    - What is our current status and what is remaining?

    - Any questions and answers

  • Liked Krishnamurty VG Pammi
    keyboard_arrow_down

    Role of Scrum of Scrum meetings in achieving Transparency and Speed - Experiential insights on what it takes to reflect “shared team goal” in scaled agile framework

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Are you in need of stepping up “Transparency” & “Speed” in your scaled agile framework? Are you experiencing the difficulty that most of your scrum teams are focusing on their individual team specific goals and thus missing “whole-team” thinking towards “Shared Project goals”?

    Learn our practical case study on how our teams could able to establish “Transparency and Speed” through realizing the connect among our “Daily Scrum”, “Scrum of Scrum”, “Scrum of Scrum of Scrum” events on a happening project that comprises of 18 scrum teams belonging to 10 business components located at 4 different countries.

    Experience how our teams are able to instil the sense of urgency among the virtual teams and understood the noble purpose/role of “scrum of scrum” events in resolving cross site dependencies promptly through our 3 step framework “Plan, Perform and Adapt”

    (1)    Plan:  Easy to use planning practices adopted by our teams to make our scaled “scrum of scrum” agenda simple and relevant.

    (2)    Perform: Ground level challenges resolved by our teams and how our team could able to implement the agenda set in achieving transparency, speed and thus quality.

    (3)    Adapt: Practices our team implemented in responding to the change and adopted “whole team thinking” in achieving“ shared project goals”

    Scrum of Scrum events helped our team progress quickly and easily. Our team could able to coordinate and integrate their work effectively. The interesting thing is that our teams could able detect the risks early in this game and came up with apt response strategies to address them.  

    Keeping the discussions short and focussed in these events comes with practice and preperation. Our teams are kept current with “cross team dependencies”, “Risks with response plan”, “Issues and their progress” and “number of added stories and defects since we last met”.  Our teams leveraged Visual communication channels when it comes to “scrum of scrum of scrum” across different sites.

    Come and experience our case study and take-a-way “useful” learnings to make your scaled agile project achieve “Transparency”, “Speed” and thus “Agility” with teams reflecting “whole-team thinking” and working for “Shared project goals day after day….

  • Liked Michael Harris
    keyboard_arrow_down

    Agile Competency Development For Enterprises

    Michael Harris
    Michael Harris
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    For agile to work at scale in enterprises, there needs to be clarity around the hierarchy (or lack of hierarchy) of roles across teams and products to ensure sound governance and, perhaps more importantly, to offer career (and salary!) progression.  This presentation will propose a competency-based approach for the development of skills and competencies of the workforce, and thus creating a sustainable transformation in an enterprise. We will include experiences of implementing those components of the proposed model that have already been tried and tested.  Feedback will be sought from the participants.

  • Liked Alexey Pikulev
    keyboard_arrow_down

    “Help Me Do It Myself!” Growing a self-organization by using the Montessori Method

    Alexey Pikulev
    Alexey Pikulev
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    “Help Me Do It Myself!” Montessori is an innovative, child-centered approach to education, developed a century ago by Dr. Maria Montessori who was struck by how avidly the children absorbed knowledge from their surroundings. The goal of the Montessori method is to foster a child’s natural inclination to learn, where Montessori teachers guide rather than instruct, linking each student with activities that meet his interests, needs, and developmental level. But is this method only suitable for children?

    In this talk, I will demonstrate how to apply the Montessori education method in growing self-organized teams. We’ll discuss what Leaders may find useful and how to adapt this methodology in the day to day work of your organization.

  • Shiva Krishnan
    Shiva Krishnan
    schedule 2 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    My journey as an agile coach has been a great learning experience.

    In this session i intend to share some key learnings that contribute to effective coaching.

    I have aggregated my presentation under the following topics:

    • Coaching with Compassion vs coaching for compliance - why it is important to understand the team's needs instead of running the coach's transformation agenda. How do we involve teams in the transformation?
    • The coach’s mindset defines his/ her coaching - Many times coaches are not able to identify team problems due to their own biases. How can a coach be aware of such biases and overcome them?
    • Making your coaching visible - A common failure in transformations is that coaches are unable to make their progress visible. We will look at some interesting techniques to make  coaching progress visible
    • Involving stakeholders -How do we involve stakeholders other that the teams? why is it important?
    • Coach for a coach - Every coach needs a mentor . How do we effectively utilize mentors? what role do they play in a coach's growth?
    • Celebrating success - We often fail to talk about our successes and acknowledge teams. How did we do this in our organization?

    In each topic i will be sharing my experience, learnings and techniques that i used to overcome challenges.