Although self-organizing teams are crucial to carrying out a successful Agile transformation, organizations that implement Agile at scale invariably realize that the introduction of such teams forces the organization to re-engineer numerous aspects of its operating philosophy. In particular, various management layers are often removed. The individuals in these layers are routinely re-purposed or laid off.

This talk highlights the approaches I used as an Agilist in various organizations to help people in different roles on their journey of transitioning into the world of Agile. Specifically, the talk will focus on 5 key roles: Project Managers, Product Managers, BA Managers, Development Managers, and QA Managers. It will provide insight into how managers can effectively transition to some of the new Agile roles, or redefine their existing role to effectively fit in an Agile world.

The emphasis in this talk is on pragmatic strategies for managers that are struggling to find their place in this new Agile world. Armed with these strategies, participants will be able to effectively adapt to the Agile transformation, as well as discover potential new career paths for themselves and for the individuals reporting to them.

5 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

This talk will provide a view from 5 perspectives on how implementing Agile forces change in people’s roles in an organization. The perspectives will come from 5 different roles that I have worked with over the years as I was deploying Agile in different organizations. The roles are Project Managers, Product Managers, BA Managers, Development Managers, and QA Managers. The perspectives will come from multiple people in the same role and how they chose to evolve their role in an organization as Agile was being deployed.

Time-wise, I expect a 40-minute talk with audience participation followed by 5 minutes of Q&A.

  • The view of the Radical Agilist vs SAFe. (5 min)
  • Examples of self-organizing teams in various software organizations, which ones worked and which ones didn’t. (5 min)
  • The Shopify Guild concept, can it work? (5 min)
  • The importance of a clear Job Description (5 min)
  • The transition of the 5 roles into an Agile world. (10 min)
  • What does a more modern management style look like? Is it like Management 3.0? (5 min)
  • Managing a distributed workforce in an Agile world. (5 min)
  • Q&A (5 min)

Learning Outcome

  • How to adapt your management style to be successful in an Agile world?
  • How to transition from the role of manager to the role of manager/Agile mentor.
  • How to make the transition between roles in an Agile world.
  • How to evaluate if a self-organizing team is working beyond the definition of done?
  • How to implement the Shopify Guild concept in an organization.
  • Why you should implement the Shopify Guild concept.
  • How to minimize the challenges of a distributed work force.

Target Audience

All types (Project, Product, Development, BA, QA) of Team Leads, Managers and Directors dealing with an Agile Transformation.


Some experience in rolling out multiple Agile teams either as a practitioner or as an agent of change.

schedule Submitted 1 month ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Maurizio Mancini

    Maurizio Mancini - Scaling Quality by Building it in

    45 mins

    According to the 11th annual State of Agile report by VersionOne, one of the top five reasons for adopting Agile is to “enhance software quality”. In spite of this aspiration, a common pattern in Agile rollouts is the failure to set quality goal improvements from the outset. It is often assumed that if you implement Agile/Scrum then quality will just take care of itself. As many organizations quickly discover, you cannot just “deploy Agile” and expect it to be the silver bullet for a software organizations’ quality issues. Why is this happening so frequently? Is it due to methodical deficiencies, unrealistic expectations, fundamental misunderstanding of Agile, lack of executive support, too much existing technical debt or all of the above?

    If you are questioning whether your Agile rollout is really helping you deliver higher quality software, faster, then this talk is a must to attend. I will discuss the approach I have successfully used in a number of organizations which involves; identifying the necessary building blocks to establish a quality mindset in an organization, moving the organization to a test first mindset, helping the Product Management organization become more Agile, and finally setting the right level of test automation so that you can deliver quality software faster.

    If you are serious about doing Agility at scale, you cannot realistically achieve that goal without ensuring that each team individually delivers quality, and in-turn whole projects/programs that incorporate outputs from the individual teams are delivering quality software. To successfully scale quality, you will need to follow the ‘blueprint’ provided in this presentation.

  • Liked Daniel Doiron

    Daniel Doiron - OKALOA FLOW LAB

    Daniel Doiron
    Daniel Doiron
    Agile Agonist
    schedule 2 months ago
    Sold Out!
    75 mins

    This workshop can be given in either French or English ....

    Enterprise agility come in numerous flavors. Participants will be confronted with the false choices presented to them (Flow vs Iteration, feature teams or competence based) by different approaches and be better able to build bridges between islands of agility (Scrum, LeSS, SAFe, Kanban)

    The OKALOA FLOW LAB is a new simulation created by Patrick Steyaert, conceptor of Upstream Kanban, Discovery Kanban, Portfolio Kanban, Customer Kanban. He is a world leader in all matters related to agility.

    The simulation is fantastic.

  • Liked Howard Deiner

    Howard Deiner - How We Get Agile Transformations Wrong By Trying to Do It All So Right

    60 mins

    Sorry to say it guys, but Agile has gone limp over the last few years.  As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce.  Not great stand-ups.

    Technical practices matter.  In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that.  From a Lean perspective, process adds no customer facing value.  But getting rid of all process is crazy talk.  Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process.  In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company.  He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.

    But perhaps we don’t have the absolute best talent out there.  Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?)  Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”?  With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?

    I’d like to convince you that what’s going to work for your organization and your employees is something in the middle.  I, of course, lean into the “better technical practices will yield better outcomes” frame of mind.  You may as well.  But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that's the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire!  And the same is true of your organization.  It can logically be true that all organizations’ developers are all above average.  But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code. 

    This session will speak to the specifics of the whats and whys.