SlideShare a Scribd company logo

Scaling Agile and Scrum (cPrime/Angela Johnson)

•
•
Cprime
Cprime

This webinar will introduce attendees to Agile and Scrum tools to “scale”across products, the enterprise and locations. Unlike other scaling approaches that are a one size fits all model, this interactive session shows how to apply Scrum and Agile without contradicting values, principles or frameworks.

1 of 38
Scaling Agile & Scrum Angela Johnson, PMP, PMI-ACP, CST Certified Scrum Trainer & Agile Transformation Coach http://collaborativeleadershipteam.com @AgileAngela
Angela Johnson PMP, PMI-ACP, CST • 20+ years Information Technology with traditional SDLC and Scrum/Agile • Scrum Alliance Volunteer: Trainer Approval Committee and Core Scrum Team • Volunteer Facilitator PMI-MN Agile Practitioner Community • Based in Minneapolis, MN 2Copyright 2014 Collaborative Leadership Team
This Webinar… • Is not a prescriptive answer on any one definition or approach to Scaling Agile or Scrum • Is not a prescriptive answer for every position in every company • Is one coach and trainer’s experience with what has worked in the field predominantly where scaling Scrum and Agile approaches are concerned • Is a set of shared tips, observations and experiences that have worked for a number of organizations ranging in size and industry 3Copyright 2014 Collaborative Leadership Team
When you say Scaling… • Scaling multiple products across a team • Scaling multiple teams across a product • Scaling Agile or Scrum across an enterprise or organization • Scaling Agile or Scrum across geographic regions • All of the above? 4Copyright 2014 Collaborative Leadership Team
Scaling Agile & Scrum • Scaling Agile and Scrum is not new • “Agile” has been around since 2001 – Scrum since the mid 1990s • Scaling success stories started being shared as early as 2003 following the values, principles and empiricism • A way to compare Agile Scaling approaches is available here: http://www.agilescaling.org/home.html 5Copyright 2014 Collaborative Leadership Team
Case Study: One Team, Multiple Products 6Copyright 2014 Collaborative Leadership Team
Case Study: One Team, Multiple Products • One department in a large, privately held financial institution that was open minded about Agile and Scrum • Leadership support and commitment to Scrum • 100% dedicated, co-located Team and ScrumMaster • Empowered Product Owners for respective products • Product Owners maintained their own Product Backlogs • Team maintained their Sprint Backlog 7Copyright 2014 Collaborative Leadership Team
Case Study: One Team, Multiple Products • ScrumMaster as servant leader to P.O.s worked with them at the Roadmap and Release Plan level prioritizing work • Team worked in 2 week Sprints focusing on 1 P.O.’s product at any given time • Sticky notes on wall used in addition to an Agile tool • If issues came up from a P.O. while another’s was in focus, they would agree from a value perspective and work would be committed to on the Sprint Backlog accordingly 8Copyright 2014 Collaborative Leadership Team
Case Study: Multiple Teams, One Product 9Copyright 2014 Collaborative Leadership Team
Chief Product Owner • It is not uncommon for there to be a P.O. with a couple of Scrum teams • When there are many teams, it may requiring scaling the P.O. role • A Chief Product Owner is “the” P.O. for the whole product • There may be team P.O.s or feature P.O.s in the hierarchy • If you choose this approach, ensure that the team P.O.s are empowered to make vast majority decisions at their level 10Copyright 2014 Collaborative Leadership Team Essential Scrum by Kenneth S. Rubin
Chief Product Owner 11Copyright 2014 Collaborative Leadership Team Essential Scrum by Kenneth S. Rubin
Case Study: Multiple Teams, One Product • One product at a large, publicly traded information provider that was open minded about Agile and Scrum • Leadership support and commitment to Agile and Scrum • 100% dedicated, co-located Teams and ScrumMasters • Empowered Product Owners for respective feature teams – one “C.P.O.” at the V.P. level • Product Owners maintained their own Product Backlogs • Sticky notes used on walls in addition to an Agile tool • Team maintained their own Sprint Backlogs 12Copyright 2014 Collaborative Leadership Team
Case Study: Multiple Teams, One Product • Initial feature teams with some component based teams for data, architecture and infrastructure • Initial 2 week Sprints were all on the same cadence • Good collaboration and consensus from C.P.O. and P.O.s at the Release level • Lack of transparency at the Sprint level due to cadence became evident • Bottlenecks occurred with component based teams 13Copyright 2014 Collaborative Leadership Team
Feature Teams vs. Component Teams • A feature team is a cross-functional and cross component team that can pull end-customer features from the Product Backlog and complete them • A component team focuses on development of a component or subsystem that can be used to create only part of the end-customer feature • Component teams are also referred to as asset or subsystem teams • Scrum favors feature teams – unfortunately most organizations prefer component teams 14Copyright 2014 Collaborative Leadership Team
Feature Teams vs. Component Teams • Responsibility for delivery is now distributed among two or more component teams each of which might have different priorities • The probability is increased that a feature won’t get finished due to multiple points of failure instead of one that exists with a single feature team • The solution is cross-functional feature teams that have all of the skills to work on multiple end- customer features and get them done without farming out work to component teams 15Copyright 2014 Collaborative Leadership Team Essential Scrum by Kenneth S. Rubin
Case Study: Multiple Teams, One Product • Largely Scrum based with heavy influences of XP and Feature Driven Development • Traction was gained one Sprints were “staggered” to allow for “ebb and flow” into Sprints • Additional learnings included scaling all the ceremonies – not just the Daily Scrum – across the Product Owners and Teams • This was especially valuable at the Release level 16Copyright 2014 Collaborative Leadership Team
Case Study: Scaling Across an Organization 17Copyright 2014 Collaborative Leadership Team
Case Study: Scaling Across an Organization • Approach used in a division of a not for profit, financial services company • Approach used with a small, privately held company supporting a larger franchise • Approach used in an IT Department of a Fortune 500, publicly traded company • Method scaled largely Scrum but some hybrids of “Scrumban” for infrastructure and administrative teams with XP practices widely adopted by technology teams 18Copyright 2014 Collaborative Leadership Team
Case Study: Scaling Across an Organization • In all instances real traction was gained once teams were 100% dedicated • ScrumMasters are treated as servant leaders and are dedicated • Teams largely co-located with several exceptions of 1-2 team members not in the same state and/or time zone • Sticky notes used in addition to Agile tools by all • Product Owners are not in “I.T.” in all examples but from respective lines of business 19Copyright 2014 Collaborative Leadership Team
Case Study: Scaling Across an Organization • Common success factors include dedicating teams and “brining work to the team” in an ordered manner • Sharing at the Product Ownership level at the Roadmap and Release level puts Sprints into “execution mode” • Scaling higher level ceremonies – not just the Daily Scrum – has been critical • Leadership trust of the teams and support also contributes greatly to these successes 20Copyright 2014 Collaborative Leadership Team
Large Scale Scrum • Scrum is an empirical process (inspect, adapt, transparency) • Scrum is not about a defined process or a “one size fits all” model • Each team is empowered to inspect and adapt and to evolve from Sprint to Sprint • Craig Larman & Bas Vodde approach to scaling Scrum since 2005 http://www.craiglarman.com 21Copyright 2014 Collaborative Leadership Team
Large Scale Scrum (LeSS) • Used for large, multisite, with offshore product development teams • LeSS is Scrum • There is no compromise of the Scrum framework or contradiction to Scrum values • This implies a deep change in the organization • Leadership needs to ensure this has been proven at small scale before expanding 22Copyright 2014 Collaborative Leadership Team
LeSS Scaling Scrum Teams • What is the Same as One Scrum Team? – No separate analysis group, testing group, architecture group, user experience group, platform group, etc. – No “tester” or “architect” within the team – That implies the dissolution of existing single-function groups and the management supervising roles, and the elimination of traditional career paths and job titles – The concept of “it is not ready until the end” dissolves – Scrum is not for the programming phase after the analysis and before testing – the sequential lifecycle is eliminated – There is no team lead or project manager that directs or tracks team members • What Different? – For the roles, nothing – Meetings and artifacts may change slightly 23Copyright 2014 Collaborative Leadership Team Large Scaled Agile: Larman & Vodde
LeSS Scaling Scrum Teams 24Copyright 2014 Collaborative Leadership Team Large Scaled Agile: Larman & Vodde
Large Scale Scrum 25Copyright 2014 Collaborative Leadership Team
Case Study: Scaling Across Geography 26Copyright 2014 Collaborative Leadership Team
Case Study: Scaling Across Geography • Mid-sized, privately held software company • One team based in U.S., another team in India • Product Owner based in U.S. • One Product as focus for both teams • Dedicated Teams co-located in respective countries with dedicated ScrumMasters in each location • Sticky notes in addition to Agile tool used • Scrum framework followed with some XP practices blended in 27Copyright 2014 Collaborative Leadership Team
Case Study: Scaling Across Geography • Teams initially split across geography largely by component • Sprints were 4 weeks at the beginning • Builds were not as frequent at the beginning • Traction gained when teams were re-organized at respective locations and began focusing on features • This allowed to make use of the time difference • Sprints were shortened to 2 weeks for a faster feedback loop 28Copyright 2014 Collaborative Leadership Team
Case Study: Scaling Across Geography • More frequent builds with a commitment to automation and integration increased productivity • All ceremonies were scaled with multiple communication modes used regularly – not just phone • This included using screen sharing, video recordings, etc. • Contact visits were used to send ambassadors to each location to build trust 29Copyright 2014 Collaborative Leadership Team
Group Discussion: Distributed Scrum • Use Continuous Integration to Avoid Integration Headaches • Have Each Site Send Ambassadors to the Other Sites • Use Contact Visits to build trust • Don't Underestimate the Culture Change • Use wikis to contain common information • Use Test Scripts to Help Understand the Requirements • Use Regular Builds to Get Feedback on Functionality http://martinfowler.com/articles/agileOffshore.html Copyright 2014 Collaborative Leadership Team 30
Group Discussion: Distributed Scrum • Use Regular Short Status Meetings • Use Short Iterations • Use an Iteration Planning Meeting that's Tailored for Remote Sites • When Moving a Code Base, Bug Fixing Makes a Good Start • Separate teams by functionality not activity • Expect to need more documents • Get multiple communication modes working early http://martinfowler.com/articles/agileOffshore.html Copyright 2014 Collaborative Leadership Team 31
Common Reasons Scaling Fails • Not having Agile or Scrum working at small scales first • Inability of the culture to change • Lack of leadership support • Lack of education beyond the team or “I.T.” levels • Ineffective communication and/or change management • No involvement or support from the Business 32Copyright 2014 Collaborative Leadership Team
Positioning Scaling for Success • Have a reason for adopting Agile or Scrum • Whichever Agile approach you have chosen, get it working at a small scale before you try to expand it • If you do not have things working well and you are not delivering business value any faster than before – do you really want to scale something that’s broken? • Retrospect regularly to inspect and adapt • If something is working, identify why and fix it • Educate everyone 33Copyright 2014 Collaborative Leadership Team
Positioning Scaling for Success • Having leadership support is critical for scaled success • Agile and Scrum will act as a mirror that is held up to any organization • If the organization is not ready to truly deal with the impediments a transparent process reveals, they are not ready to scale Agile approaches • In starting small, start with a pilot • Truly give that pilot effort a fair try by dedicating the team, have an empowered Product Owner, etc. 34Copyright 2014 Collaborative Leadership Team
Organizational Paradigm Shifts • People and leaders at all levels will need to be educated on Agile values and principles and buy in • One impediment is if part of the organization commits to working product over comprehensive documentation but another department insists on documents because “this is what we’ve always done” – there will be challenges • Identify internal champions so that as change is occurring, everyone is aware of where they can go for assistance 35Copyright 2014 Collaborative Leadership Team
Organizational Paradigm Shifts • Use Agile and Scrum to manage the change • Have an enterprise adoption or transformation backlog ordered by value • Work in time boxes and regularly retrospect on how the changes are going • Inspect, adapt and keep everything transparent • Use Agile and Scrum values and principles are “guidelines” when looking for answers in terms of “right” or “wrong” 36Copyright 2014 Collaborative Leadership Team
Questions 37Copyright 2014 Collaborative Leadership Team
Wrapping Up THANK YOU! Please stay in touch! Angela Johnson, PMP, PMI-ACP, CST angela@coleadteam.com http://collaborativeleadershipteam.com/ Copyright 2014 Collaborative Leadership Team 38

More Related Content

Scaling Agile and Scrum (cPrime/Angela Johnson)

  • 1. Scaling Agile & Scrum Angela Johnson, PMP, PMI-ACP, CST Certified Scrum Trainer & Agile Transformation Coach http://collaborativeleadershipteam.com @AgileAngela
  • 2. Angela Johnson PMP, PMI-ACP, CST • 20+ years Information Technology with traditional SDLC and Scrum/Agile • Scrum Alliance Volunteer: Trainer Approval Committee and Core Scrum Team • Volunteer Facilitator PMI-MN Agile Practitioner Community • Based in Minneapolis, MN 2Copyright 2014 Collaborative Leadership Team
  • 3. This Webinar… • Is not a prescriptive answer on any one definition or approach to Scaling Agile or Scrum • Is not a prescriptive answer for every position in every company • Is one coach and trainer’s experience with what has worked in the field predominantly where scaling Scrum and Agile approaches are concerned • Is a set of shared tips, observations and experiences that have worked for a number of organizations ranging in size and industry 3Copyright 2014 Collaborative Leadership Team
  • 4. When you say Scaling… • Scaling multiple products across a team • Scaling multiple teams across a product • Scaling Agile or Scrum across an enterprise or organization • Scaling Agile or Scrum across geographic regions • All of the above? 4Copyright 2014 Collaborative Leadership Team
  • 5. Scaling Agile & Scrum • Scaling Agile and Scrum is not new • “Agile” has been around since 2001 – Scrum since the mid 1990s • Scaling success stories started being shared as early as 2003 following the values, principles and empiricism • A way to compare Agile Scaling approaches is available here: http://www.agilescaling.org/home.html 5Copyright 2014 Collaborative Leadership Team
  • 6. Case Study: One Team, Multiple Products 6Copyright 2014 Collaborative Leadership Team
  • 7. Case Study: One Team, Multiple Products • One department in a large, privately held financial institution that was open minded about Agile and Scrum • Leadership support and commitment to Scrum • 100% dedicated, co-located Team and ScrumMaster • Empowered Product Owners for respective products • Product Owners maintained their own Product Backlogs • Team maintained their Sprint Backlog 7Copyright 2014 Collaborative Leadership Team
  • 8. Case Study: One Team, Multiple Products • ScrumMaster as servant leader to P.O.s worked with them at the Roadmap and Release Plan level prioritizing work • Team worked in 2 week Sprints focusing on 1 P.O.’s product at any given time • Sticky notes on wall used in addition to an Agile tool • If issues came up from a P.O. while another’s was in focus, they would agree from a value perspective and work would be committed to on the Sprint Backlog accordingly 8Copyright 2014 Collaborative Leadership Team
  • 9. Case Study: Multiple Teams, One Product 9Copyright 2014 Collaborative Leadership Team
  • 10. Chief Product Owner • It is not uncommon for there to be a P.O. with a couple of Scrum teams • When there are many teams, it may requiring scaling the P.O. role • A Chief Product Owner is “the” P.O. for the whole product • There may be team P.O.s or feature P.O.s in the hierarchy • If you choose this approach, ensure that the team P.O.s are empowered to make vast majority decisions at their level 10Copyright 2014 Collaborative Leadership Team Essential Scrum by Kenneth S. Rubin
  • 11. Chief Product Owner 11Copyright 2014 Collaborative Leadership Team Essential Scrum by Kenneth S. Rubin
  • 12. Case Study: Multiple Teams, One Product • One product at a large, publicly traded information provider that was open minded about Agile and Scrum • Leadership support and commitment to Agile and Scrum • 100% dedicated, co-located Teams and ScrumMasters • Empowered Product Owners for respective feature teams – one “C.P.O.” at the V.P. level • Product Owners maintained their own Product Backlogs • Sticky notes used on walls in addition to an Agile tool • Team maintained their own Sprint Backlogs 12Copyright 2014 Collaborative Leadership Team
  • 13. Case Study: Multiple Teams, One Product • Initial feature teams with some component based teams for data, architecture and infrastructure • Initial 2 week Sprints were all on the same cadence • Good collaboration and consensus from C.P.O. and P.O.s at the Release level • Lack of transparency at the Sprint level due to cadence became evident • Bottlenecks occurred with component based teams 13Copyright 2014 Collaborative Leadership Team
  • 14. Feature Teams vs. Component Teams • A feature team is a cross-functional and cross component team that can pull end-customer features from the Product Backlog and complete them • A component team focuses on development of a component or subsystem that can be used to create only part of the end-customer feature • Component teams are also referred to as asset or subsystem teams • Scrum favors feature teams – unfortunately most organizations prefer component teams 14Copyright 2014 Collaborative Leadership Team
  • 15. Feature Teams vs. Component Teams • Responsibility for delivery is now distributed among two or more component teams each of which might have different priorities • The probability is increased that a feature won’t get finished due to multiple points of failure instead of one that exists with a single feature team • The solution is cross-functional feature teams that have all of the skills to work on multiple end- customer features and get them done without farming out work to component teams 15Copyright 2014 Collaborative Leadership Team Essential Scrum by Kenneth S. Rubin
  • 16. Case Study: Multiple Teams, One Product • Largely Scrum based with heavy influences of XP and Feature Driven Development • Traction was gained one Sprints were “staggered” to allow for “ebb and flow” into Sprints • Additional learnings included scaling all the ceremonies – not just the Daily Scrum – across the Product Owners and Teams • This was especially valuable at the Release level 16Copyright 2014 Collaborative Leadership Team
  • 17. Case Study: Scaling Across an Organization 17Copyright 2014 Collaborative Leadership Team
  • 18. Case Study: Scaling Across an Organization • Approach used in a division of a not for profit, financial services company • Approach used with a small, privately held company supporting a larger franchise • Approach used in an IT Department of a Fortune 500, publicly traded company • Method scaled largely Scrum but some hybrids of “Scrumban” for infrastructure and administrative teams with XP practices widely adopted by technology teams 18Copyright 2014 Collaborative Leadership Team
  • 19. Case Study: Scaling Across an Organization • In all instances real traction was gained once teams were 100% dedicated • ScrumMasters are treated as servant leaders and are dedicated • Teams largely co-located with several exceptions of 1-2 team members not in the same state and/or time zone • Sticky notes used in addition to Agile tools by all • Product Owners are not in “I.T.” in all examples but from respective lines of business 19Copyright 2014 Collaborative Leadership Team
  • 20. Case Study: Scaling Across an Organization • Common success factors include dedicating teams and “brining work to the team” in an ordered manner • Sharing at the Product Ownership level at the Roadmap and Release level puts Sprints into “execution mode” • Scaling higher level ceremonies – not just the Daily Scrum – has been critical • Leadership trust of the teams and support also contributes greatly to these successes 20Copyright 2014 Collaborative Leadership Team
  • 21. Large Scale Scrum • Scrum is an empirical process (inspect, adapt, transparency) • Scrum is not about a defined process or a “one size fits all” model • Each team is empowered to inspect and adapt and to evolve from Sprint to Sprint • Craig Larman & Bas Vodde approach to scaling Scrum since 2005 http://www.craiglarman.com 21Copyright 2014 Collaborative Leadership Team
  • 22. Large Scale Scrum (LeSS) • Used for large, multisite, with offshore product development teams • LeSS is Scrum • There is no compromise of the Scrum framework or contradiction to Scrum values • This implies a deep change in the organization • Leadership needs to ensure this has been proven at small scale before expanding 22Copyright 2014 Collaborative Leadership Team
  • 23. LeSS Scaling Scrum Teams • What is the Same as One Scrum Team? – No separate analysis group, testing group, architecture group, user experience group, platform group, etc. – No “tester” or “architect” within the team – That implies the dissolution of existing single-function groups and the management supervising roles, and the elimination of traditional career paths and job titles – The concept of “it is not ready until the end” dissolves – Scrum is not for the programming phase after the analysis and before testing – the sequential lifecycle is eliminated – There is no team lead or project manager that directs or tracks team members • What Different? – For the roles, nothing – Meetings and artifacts may change slightly 23Copyright 2014 Collaborative Leadership Team Large Scaled Agile: Larman & Vodde
  • 24. LeSS Scaling Scrum Teams 24Copyright 2014 Collaborative Leadership Team Large Scaled Agile: Larman & Vodde
  • 25. Large Scale Scrum 25Copyright 2014 Collaborative Leadership Team
  • 26. Case Study: Scaling Across Geography 26Copyright 2014 Collaborative Leadership Team
  • 27. Case Study: Scaling Across Geography • Mid-sized, privately held software company • One team based in U.S., another team in India • Product Owner based in U.S. • One Product as focus for both teams • Dedicated Teams co-located in respective countries with dedicated ScrumMasters in each location • Sticky notes in addition to Agile tool used • Scrum framework followed with some XP practices blended in 27Copyright 2014 Collaborative Leadership Team
  • 28. Case Study: Scaling Across Geography • Teams initially split across geography largely by component • Sprints were 4 weeks at the beginning • Builds were not as frequent at the beginning • Traction gained when teams were re-organized at respective locations and began focusing on features • This allowed to make use of the time difference • Sprints were shortened to 2 weeks for a faster feedback loop 28Copyright 2014 Collaborative Leadership Team
  • 29. Case Study: Scaling Across Geography • More frequent builds with a commitment to automation and integration increased productivity • All ceremonies were scaled with multiple communication modes used regularly – not just phone • This included using screen sharing, video recordings, etc. • Contact visits were used to send ambassadors to each location to build trust 29Copyright 2014 Collaborative Leadership Team
  • 30. Group Discussion: Distributed Scrum • Use Continuous Integration to Avoid Integration Headaches • Have Each Site Send Ambassadors to the Other Sites • Use Contact Visits to build trust • Don't Underestimate the Culture Change • Use wikis to contain common information • Use Test Scripts to Help Understand the Requirements • Use Regular Builds to Get Feedback on Functionality http://martinfowler.com/articles/agileOffshore.html Copyright 2014 Collaborative Leadership Team 30
  • 31. Group Discussion: Distributed Scrum • Use Regular Short Status Meetings • Use Short Iterations • Use an Iteration Planning Meeting that's Tailored for Remote Sites • When Moving a Code Base, Bug Fixing Makes a Good Start • Separate teams by functionality not activity • Expect to need more documents • Get multiple communication modes working early http://martinfowler.com/articles/agileOffshore.html Copyright 2014 Collaborative Leadership Team 31
  • 32. Common Reasons Scaling Fails • Not having Agile or Scrum working at small scales first • Inability of the culture to change • Lack of leadership support • Lack of education beyond the team or “I.T.” levels • Ineffective communication and/or change management • No involvement or support from the Business 32Copyright 2014 Collaborative Leadership Team
  • 33. Positioning Scaling for Success • Have a reason for adopting Agile or Scrum • Whichever Agile approach you have chosen, get it working at a small scale before you try to expand it • If you do not have things working well and you are not delivering business value any faster than before – do you really want to scale something that’s broken? • Retrospect regularly to inspect and adapt • If something is working, identify why and fix it • Educate everyone 33Copyright 2014 Collaborative Leadership Team
  • 34. Positioning Scaling for Success • Having leadership support is critical for scaled success • Agile and Scrum will act as a mirror that is held up to any organization • If the organization is not ready to truly deal with the impediments a transparent process reveals, they are not ready to scale Agile approaches • In starting small, start with a pilot • Truly give that pilot effort a fair try by dedicating the team, have an empowered Product Owner, etc. 34Copyright 2014 Collaborative Leadership Team
  • 35. Organizational Paradigm Shifts • People and leaders at all levels will need to be educated on Agile values and principles and buy in • One impediment is if part of the organization commits to working product over comprehensive documentation but another department insists on documents because “this is what we’ve always done” – there will be challenges • Identify internal champions so that as change is occurring, everyone is aware of where they can go for assistance 35Copyright 2014 Collaborative Leadership Team
  • 36. Organizational Paradigm Shifts • Use Agile and Scrum to manage the change • Have an enterprise adoption or transformation backlog ordered by value • Work in time boxes and regularly retrospect on how the changes are going • Inspect, adapt and keep everything transparent • Use Agile and Scrum values and principles are “guidelines” when looking for answers in terms of “right” or “wrong” 36Copyright 2014 Collaborative Leadership Team
  • 38. Wrapping Up THANK YOU! Please stay in touch! Angela Johnson, PMP, PMI-ACP, CST angela@coleadteam.com http://collaborativeleadershipteam.com/ Copyright 2014 Collaborative Leadership Team 38

Editor's Notes

  1. Steve Denning is the author of the award winning books “The Leader’s Guide to Radical Management: Re-inventing the Workplace for the 21st Century”, “The Secret Language of Leadership” and “The Leader’s Guide to Storytelling”. Denning maintains that traditional management is broken. The life expectancy of Fortune 500 firms is down to 15 year trending downward towards 5 years. Denning says that organizations need to delight their customers and that Leaders in organizations need to change from controllers of people to enablers of self-organization to bring about creative problem solving. The leadership shift needs to move from single-minded profit focus to continuous transparency and radical transparency.
  2. Steve Denning is the author of the award winning books “The Leader’s Guide to Radical Management: Re-inventing the Workplace for the 21st Century”, “The Secret Language of Leadership” and “The Leader’s Guide to Storytelling”. Denning maintains that traditional management is broken. The life expectancy of Fortune 500 firms is down to 15 year trending downward towards 5 years. Denning says that organizations need to delight their customers and that Leaders in organizations need to change from controllers of people to enablers of self-organization to bring about creative problem solving. The leadership shift needs to move from single-minded profit focus to continuous transparency and radical transparency.
  3. Steve Denning is the author of the award winning books “The Leader’s Guide to Radical Management: Re-inventing the Workplace for the 21st Century”, “The Secret Language of Leadership” and “The Leader’s Guide to Storytelling”. Denning maintains that traditional management is broken. The life expectancy of Fortune 500 firms is down to 15 year trending downward towards 5 years. Denning says that organizations need to delight their customers and that Leaders in organizations need to change from controllers of people to enablers of self-organization to bring about creative problem solving. The leadership shift needs to move from single-minded profit focus to continuous transparency and radical transparency.
  4. Steve Denning is the author of the award winning books “The Leader’s Guide to Radical Management: Re-inventing the Workplace for the 21st Century”, “The Secret Language of Leadership” and “The Leader’s Guide to Storytelling”. Denning maintains that traditional management is broken. The life expectancy of Fortune 500 firms is down to 15 year trending downward towards 5 years. Denning says that organizations need to delight their customers and that Leaders in organizations need to change from controllers of people to enablers of self-organization to bring about creative problem solving. The leadership shift needs to move from single-minded profit focus to continuous transparency and radical transparency.