location_city Bengaluru schedule Mar 28th 02:30 - 02:50 PM place Grand Ballroom 2

Based on my experience of coaching/ training agile teams for 5 years, one of the important reasons for agile teams are impacted, is the personal leadership style of Agile Leaders(Scrum Master, Senior Managers etc) . I have summarized following, factors or impediments for creating effective agile teams

  • The agile teams effectiveness depends on personal leadership style of agile leaders(Scrum Masters, Senior Management etc)
  • Often Agile leaders focus more on “delivering solutions” than “developing people”.
  • Agile leader need not specify work requirements, all that team needs is - empowerment, autonomy to work.
  • The agile team needs more support through mentoring, coaching from agile leaders to exhibit the culture “Being Agile” than “Doing Agile”.
  • Agile leaders need not be an Expert to coach agile teams.
  • Agile teams needs to be taught on Identifying Problem, Problem solving skills and corrective actions and demonstrate steady, small and continuous improvement.


My inspiration to write here, is derived from the book “ Managing Excellence” by David Bradford and Allan Cohen, and reading blogs, articles along with my own experience.


The entire presentation will be done in “Pecha Kucha Style” with less words and more background pictures, in each slide. The most of the message is conveyed through pictures. The presenter will talk maximum 30 secs on each slide. The slides keep changing automatically after 30 secs, so that presenter continues the discussion in the next slide automatically


Outline/Structure of the Experience Report

0-5 min:
Discussion on challenges faced by agile teams (mentioned above) from the various types of leadership styles, based on my experience in coaching and training.

5-12 min:
Presenting my thoughts on different leadership style
• Leader as Expert
• Leader as Conductor
• Good Leader Myths
• Leader as a Developer (of people)

12-18 Min:
Recommendations for Agile leadership style as “ Leader as developer of people”
• Creating environment of mutual influence( Increased Engagement, Ownership and Responsibility)
• Teach lean principles of software product development eg Managing Queues, Variability, Small batches, Push and Pull, Delays, bottlenecks.
• Coaching agile teams for “Small and Steady improvements” through continuous reflection
• Mentoring agile teams on “Being Agile” than “Doing Agile”.
• Agile Product Management Approach- Minimum Viable Solution, MVP etc

18-20 Min:
Q& A

Learning Outcome

• Awareness on the required personal leadership style of agile leaders to create effective agile team.
• Understanding what it takes to be “Developer of People” for agile leaders.
• Agile Leaders Focus on “Developing People than Delivering Solutions”

Target Audience

Anyone is interested to know Agile Leadership Style, ScrumMasters, Seniors Management, Agile Team members

schedule Submitted 5 years ago

Public Feedback

comment Suggest improvements to the Speaker
  • Steve Ropa
    By Steve Ropa  ~  5 years ago
    reply Reply

    Hi Naranjan,

    I am curious how often you have done Pecha Kucha before.  I find it very entertaining, but often worry that it seems to be more about the performance than the substance.  I alsom note that your techniques that you describe in the comments as to how to achieve the leadership goals are really very well known.  What is there that is different, or special, about how you implement them?





    • Niranjan N V
      By Niranjan N V  ~  5 years ago
      reply Reply

      Hi Steve,

      Thanks for your comments. I have done two - three times pecha kucha before. Yes, as you have mentioned it is more entertaining, than getting into depth. Also it is more focussed on the content with limted time

      That is how it has been deisgned to more less talking and convey with more visual preesntations. It is very effetive for short talks, defintely not so effective for detailed discussions. Normally Pecha Kucha slides are 20 secs. But I plan to do 30 secs very slide wherever necessary.

      Coming to your next question, about the techniques suggested are more on how they are implemented and how an agile leader can add value to the teams " being devloper of people"/ He should teach oftem Lean Agile  behaviour to the teams, tah focussing too much on solutions.

      If Agile Leders Develop people, the people will deliver solutions. Agile Leaders need not worry too much on delivering solutions.

      I hope I have tried to clarify.


      Best Regards







  • Niranjan N V
    By Niranjan N V  ~  5 years ago
    reply Reply

    Hi Naresh,

    I have converted this into Experience Report.



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

    Niranjan - we would like to understand whether these key points are from your specific learnings from your real-world experiences? Can you elaborate on it?


    • Niranjan N V
      By Niranjan N V  ~  5 years ago
      reply Reply

      Hi TV,

      Thanks for the comments.

      Yes the above key recommnedation are from my coaching and training experience.

      Many times

      1) Agile teams still struggle to take ownership and responsibilities. They still look for answers from some one external like Scrum Master, Senior management etc. QA and Developers still would like to operate separately even when they are part of cross functional team.

      2) In my experience there is a lack of awareness in agile teams on how to apply lean principles such as managing queues(managing product backlog items, identifying spikes when things are not clear(control variability), managing with WIP limits (such that bottlenecks can be reduced etc.)

      3) Agile teams dont take retrospectives seriously once the sprint reviews are over. They need to recognize the small and steady improvements are key for demonstrating continous value to the business people.

      4) Agile teams, when they work in agile projects, it would make lot of difference if they think their sprint deliverables (product increments) with Agile Product Management approach, such as working with product owners to deliver minimum  features which are part of  first release or viable solutions. (Minimum Viable Product). It might make good sense for a ScrumMaster to even coach the product owners on agile product management approach.

      Leadership such as ScrumMasters, Product Owners, Product Management, Senior Management should teach this lean agile behaviour to agile teams than too much focussing on delivering solutions, micro management. If teams are developed  on these lines,   Teams will deliver solutions. Managment need not focus too much on deleviring solutions.

      I hope this would help you to clarify.



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

        Thanks for the clarification Niranjan. Can you please explain what specific techniques or practices did you use to address the problems highlighted above? I'm sure many organisations would be interested in those techniques.

        Also since this is based on real experience would you consider converting the talk into an experience report?

        • Niranjan N V
          By Niranjan N V  ~  5 years ago
          reply Reply

          Hi Naresh,

          Some of the specific techniques used were.

          1) Introducing " Planning cadence" once in 30 days, to reduce the Queue in the Backlog. Once in 30 days, Managers used to idenitfy what should go in the Backlog and prioritize them. Earlier the backlog was having too many items waiting.

          2) Introuced WIP limits for Testing and Development in the task board, so that developers don't increase the bottleneck by taking more from analysis stage.

          3) Introduced " Work agreements" for  Daily standups. Earlier late coming was becoming an habit with few team members. So that effectiveness was increased.

          4) Introduced the " Verification of User stories by Product Owner" during the Sprint than postponing the things at the end of the sprint review in order to reduce undone work identified at the end of the sprint. That is, at the time of Sprint Review, more undone work getting identified during the sprint review and it was increasing the spill over. The spill over effect was becoming unmanageable in the later sprints.

          5) Agile retrospectives were made mandatory in the initial sprints for New teams. So that they learn fast and  improve. Rather than idenifying too many improvement areas, Teams were asked to identify 2 important areas to be used in the next sprint.

          6) Agreeing on Measurable Sprint Goal as much as possible so that work done at the end was increment of the Product.

          7) Allocating the reserved Capacity for Spikes and any refactoring. Let us say 70 % for development and 30 % for spike and refactoring activities.

          Hope this clarifies. I can change this to experience report. But would love to do talk as much as possible in Pecha Kucha style. Hope this is fine.





  • Liked Vinod Kumaar R

    Vinod Kumaar R - Build it like sports teams

    Vinod Kumaar R
    Vinod Kumaar R
    VP Engineering
    schedule 5 years ago
    Sold Out!
    20 Mins

    Is it easy to get a crash course in football by Pele or Maradona for a week and produce a world cup winning football team?

    Answer is NO. Then why do lots of people in the corporate world think of hiring scrum trainers & expert developers to train their team for a week and then expect their team to undergo a transformation at a magical scale?

    German football team made it a point to transform their team and it took them a lots of years before they were able to reach the pinnacle. A quick side by side comparison of what is causing agile transformation to fail.


    Football: Someone was there owning this entire transformation, the German football association spent a lot of time identifying talent in their teens and groomed them.

    Office: In the corporate world switching jobs every few years have become common, but there is no passing on of the context, resulting in the new person taking charge, starting from all over again, as well as frustrating existing good performers who have to rebuild the perception.


    Football: Players expecting state of the art training facilities, fitness programs and new shoes are not a luxury, it is a necessity.

    Office: Computers have become so cheap compared to the salaries, yet the policy of providing the best tools and good work environment are archaic.

    Coach vs Management

    Football: Coaches are given their due powers to help the team achieve the goal. It is very easy for anyone to comment on how professionals should play their game, there would be no use adhering to the metrics if the team cannot win. Winning is the only measure for management.

    Office: Often coaches are seen as part of the management or management tries to heavily influence coaching which results in a team which will work either for metrics or to please higher ups without the actual result that it had aimed for.


    Football: Just the ability to kick the ball does not make a footballer. Training will be introduced to increase physical strength & stamina, better mental wellness, injury prevention, tactics and strategy.  A heavy investment is made in the training facilities.

    Office: In the software industry a generation is about 2-3 years. Computer science degrees are nowhere near what is state of the art in the industry. At many places the on boarding process is either very shallow or not up to date with the recent developments, leaving people to learn most of the things hard way. Given too many things to learn and the information overload, this results in inefficient learning and application of knowledge on the job. We need to prepare people to find answers that are not available on Google.

    Team composition

    Football: Rookies don’t learn by watching greats from the bench, instead they play along with the veterans. Every sports team makes sure to have the right composition with a mix of rookies, emerging players and veterans. That is how they sustain a winning team.

    Office: Architects and Leads often do not code or are not part of the team every day, this means that most of the time the team just looks up to for advice or waits for reviews. There should be a good mix of people at all experience level so that there are enough people to try new things, enough people who have mastered few things and enough people who challenge change.

    Above all – Persistence

  • Liked sailee

    sailee / Radhakrishnan - UI Automation : Safety Net to Trap Net!!

    45 Mins

    At the BEGINNING Of the project: Yay!! Lets automate and cover all test scenarios!! Lets work towards increasing the test coverage !!smile

    After 1 year: Regression suite is too bulky!! I can't maintain it anymore!! Its too flaky!! frown

    Does this conversation ring a bell? Well, this is a common scenario in projects. The UI test automation starts as a saftey net and then becomes a trap net! 

    Heavy Functional tests layer → Long execution time → Low confidence → Problem of Maintainence


    This talk will address these problems in an Agile project. Some solutions that worked in our team. How working as a Team would help prevent these problem?