Mr.Agile Leader - “ Develop People or Solutions”
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 Session
Discussion on challenges faced by agile teams (mentioned above) from the various types of leadership styles, based on my experience in coaching and training.
Presenting my thoughts on different leadership style
• Leader as Expert
• Leader as Conductor
• Good Leader Myths
• Leader as a Developer (of people)
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
• 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”
Anyone is interested to know Agile Leadership Style, ScrumMasters, Seniors Management, Agile Team members
schedule Submitted 2 years ago
People who liked this proposal, also liked:
Build it like sports teamsVinod Kumaar R
schedule 2 years agoSold Out!
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.
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
UI Automation : Safety Net to Trap Net!!
At the BEGINNING Of the project: Yay!! Lets automate and cover all test scenarios!! Lets work towards increasing the test coverage !!
After 1 year: Regression suite is too bulky!! I can't maintain it anymore!! Its too flaky!!
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?