schedule Mar 28th 03:00 PM - 03:20 PM place Grand Ballroom 2

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 

 

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

Outline/structure of the Session

It will be a PPT based walkthrough

Learning Outcome

Scrum Masters will have loads of take aways from this session

Target Audience

Scrum Masters, Agile Teams, Agile Project Managers, Coaches and Trainers, team members

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Vivek Ganesan
    By Vivek Ganesan  ~  1 year ago
    reply Reply

    Hi Vijay,

    What do you mean by Sprint Planning Part 2?  Is it something that I am missing?  It could be an unintentional mistake also.

    Regards,

    Vivek

     

     

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

      Hi Vivek, The sprint planning ceremoney has 2 parts. In part one the PO and the Dev team will discuss, understand and size stories (if they are not already sized in the refinement meeting earlier). In part two they get the capacity of the team for the sprint and divide the stories into technical tasks and estimate them into effort hours to see how many stiries can be pulled into the current sprint. Of course high matured scrum teams may skip part 2 but for the teams that are in starting phase of their scrum will do this for better visibility on how much they can commit

  • Pramod Sadalage
    By Pramod Sadalage  ~  2 years ago
    reply Reply

    Vijay,

    We think you should change the title to reflect your experience of the scrum master role, take the description you gave to Prasad (which is very detailed and good) and put it in the proposal body. Then you can convert this proposal to a 20 min experince report. The attenddes will understand how you were effective in the Scrum Master role and makes the proposal effective

     

  • Prasad
    By Prasad  ~  2 years ago
    reply Reply

    Vijay,

    With the above information, nobody can help in any kind of review. Please bring more details and experience from trenches..

    ~~PP

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

      Prasad, good morning and thank you for coming back with your comments. 

      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 

      So the above are some of the points that I have observed from my experience as a coach. If the above are useful I can place in the presentation and resubmit it ASAP

       

      Regards

      Vijay

      • Jerry Rajamoney
        By Jerry Rajamoney  ~  2 years ago
        reply Reply

        Hi Vijay,

        Thanks for providing these extra points. Can you pleaes relook at the "Learning Outcome" with these points you had mentioned? The concern I have is some of the points mentioned are very specific to a certain framework. I would like to see more in depth soft skill parameters based on your experience.

        Thanks,

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

          Hi Jerry,

          Some of the soft skills related points are already coered in the slide deck such as understand the team current stage (frming, storming, norming,...).

          someadditional points I observed are listed below:

          1. Theory X and Theory Y: When the Scrum team contains more theory Xthe Scrum Master role is more challenging and he needs to struggle if his soft skills are not sufficient enough to tackle the situation. 

          2. Situational Leadership: Instead of alaways jump and help the team he needs to let them find the direction. This will help the teams to become self-organized rather than dependent teams

          3. Decision making: When scrum master comes with domain or technology backgrounnd he generally tends to make the decision which is close to dectatorship type. In this case the SM has to really wear the SM hat rather than a SME hat and let the team drive the decision

          4. Team building: One of very key soft skills especially for the SMs. I generally observed the SMs who spend more time with their teams, who truely behave like ervant leaders have got great positive outcome from their teams. Going to lunch together with the team, having team outing events, conducting inhouse games will really help team bonding

          As I mentioned the version is still draft and I am planning to add some more contrnt around the above points. Please let me know if I can add and uploada new version by Monday EOD

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

            Jerry, I have added 2 slides to cover the above points and uploaded the latest version. Most of the information will be discussed using some examples and experience from the teams I have been coaching. So the slides are the place holders to start the discussion and take it forward. Please check and get back if you need any further information


  • Liked Ravindra Chebiyam
    keyboard_arrow_down

    Ravindra Chebiyam / Serajul Arfeen - Mobile to Mainframe: Application Development and DevOps in the Application Economy

    20 mins
    Demonstration
    Intermediate

    Agile delivery at the speed of business requires a seamless integration of Application Development, Delivery, and Operations.

    We would like to present a fresh perspective of DevOps initiative and how it integrates with agile based development of mobile and web based applications.

    In today's world of Application Economy, enterprises are rapidly developing mobile and web applications to stay competitive.

    In this process, they are required to interact with the backend "system of record".

    Large enterprises utilize mainframe at the heart of the dynamic data center as backend system of record.

    This integration of agile-based mobile app development dependent on mission-critical mainframe-based operations is driving the importance of DevOps initiatives within the application development organizations.

  • Liked Nanda Lankalapalli
    keyboard_arrow_down

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

    Nanda Lankalapalli
    Nanda Lankalapalli
    Agile Evangelist
    Independent
    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

    Krishnamurty VG Pammi - 6 X 2 Planning Errors in Scaled Agile Delivery Model

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    Agile Coach
    IVY Comptech
    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 Madhavi Ledalla
    keyboard_arrow_down

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

    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!

     

  • Liked Pooja Uppalapati
    keyboard_arrow_down

    Pooja Uppalapati / Ravindra Chebiyam - Scaling Agile in a Mainframe Product Development Organization

    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
    Business Analyst
    ThoughtWorks
    schedule 3 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 Vijay Bandaru
    keyboard_arrow_down

    Vijay Bandaru - Lean and Kanban Implementation from Trenches

    Vijay Bandaru
    Vijay Bandaru
    Agile Coach
    IVY Comptech
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    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

  • Liked Vijay Bandaru
    keyboard_arrow_down

    Vijay Bandaru - A retrospection on a Large Scale Agile Transformation

    Vijay Bandaru
    Vijay Bandaru
    Agile Coach
    IVY Comptech
    schedule 3 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

    Krishnamurty VG Pammi - 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
    Agile Coach
    IVY Comptech
    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….