Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
What to Upload to SlideShare
What to Upload to SlideShare
Loading in …3
×
1 of 28

7 Myths of Organisational Agility

0

Share

Download to read offline

Talk delivered by Antoinette Coetzee at Agile Days Istanbul 2019.

Abstract:
Agile at the team level has been around for almost 25 years. Over the last few years it has grown from product development framework to IT department approach, from the software development arena to the larger organisation. We have seen the advent of scaled frameworks like SAFe, we have seen an explosion of tools, we are now onto Business Agility and the application of Agile in non-software companies.

Yet most organisations are still not happy with the improvements brought about by an Agile way of working. Why?

In this talk we explore the issue of agility from multiple angles. We look at the impact of Leadership, Organisational Structure, Culture, Products and Technical Practices, to name but a few.
Please join us to dismantle some of your own hidden assumptions and find a path into great agility!
* Agility does not impact leaders
* We need a framework
* We need tools
* Technical mastery is not important
* We can continue to measure success in the same old way
* We don’t need to change our organisation structure
* We can scale without having it right at the team level
* There is an end state
* Decisions can be made in the same way
* It has to start from the top, or it had to start from the bottom
* It is an IT problem

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

7 Myths of Organisational Agility

  1. 1. @AntoinetteCoet 7 Myths of #OrganisationalAgility
  2. 2. @AntoinetteCoet 7 Myths of #OrganisationalAgility How did we get here? Why are we interested in Organisation Agility at all?
  3. 3. @AntoinetteCoet 7 Myths of #OrganisationalAgility
  4. 4. @AntoinetteCoet 7 Myths of #OrganisationalAgility SUBJECTIVE OBJECTIVE Inspired by Michael K. Spayd’s work applying Integral Theory to Agile
  5. 5. @AntoinetteCoet 7 Myths of #OrganisationalAgility PERSONAL COLLECTIVE SUBJECTIVE OBJECTIVE Inspired by Michael K. Spayd’s work applying Integral Theory to Agile
  6. 6. @AntoinetteCoet 7 Myths of #OrganisationalAgility "WE" "ITS" "IT""I" MINDSET& ENGAGEMENT CULTURE & RELATIONSHIP COMPETENCIES, PRACTICES, PRODUCTS ORGANISATIONAL ARCHITECTURE & ENVIRONMENT INTEGRAL AGILE Inspired by Michael K. Spayd’s work applying Integral Theory to Agile
  7. 7. @AntoinetteCoet 7 Myths of #OrganisationalAgility "WE" "ITS" "IT""I" Leadership Personal responsibility Rank Change resilience Careerambition Purpose Engagement Values Organisational culture and norms Psychological safety Collaboration Systems Thinking Organisational altitude Value Streams Organisational structure Governance Skills and Techniques Roles Technical practices Agile/Lean practices in all areas, e.g. Finance, HR, etc Products Design Thinking INTEGRAL AGILE MINDSET& ENGAGEMENT CULTURE & RELATIONSHIP COMPETENCIES, PRACTICES, PRODUCTS ORGANISATIONAL ARCHITECTURE & ENVIRONMENT Inspired by Michael K. Spayd’s work applying Integral Theory to Agile
  8. 8. @AntoinetteCoet 7 Myths of #OrganisationalAgility "WE" "ITS" "IT""I" INTEGRAL AGILE Skills and Techniques Roles Technical practices Agile/Lean practices in all areas, e.g. Finance, HR, etc Products Design Thinking Leadership Personal responsibility Rank Change resilience Careerambition Purpose Engagement Values Organisational culture and norms Psychological safety Collaboration Systems Thinking Organisational altitude Value Streams Organisational structure Governance MINDSET& ENGAGEMENT CULTURE & RELATIONSHIP COMPETENCIES, PRACTICES, PRODUCTS ORGANISATIONAL ARCHITECTURE & ENVIRONMENT Inspired by Michael K. Spayd’s work applying Integral Theory to Agile
  9. 9. @AntoinetteCoet 7 Myths of #OrganisationalAgility "WE" "ITS" "IT""I" INTEGRAL AGILE Skills and Techniques Roles Technical practices Agile/Lean practices in all areas, e.g. Finance, HR, etc Products Design Thinking Leadership Personal responsibility Rank Change resilience Careerambition Purpose Engagement Values Organisational culture and norms Psychological safety Collaboration Systems Thinking Organisational altitude Value Streams Organisational structure Governance MINDSET& ENGAGEMENT CULTURE & RELATIONSHIP COMPETENCIES, PRACTICES, PRODUCTS ORGANISATIONAL ARCHITECTURE & ENVIRONMENT Inspired by Michael K. Spayd’s work applying Integral Theory to Agile
  10. 10. @AntoinetteCoet 7 Myths of #OrganisationalAgility "WE" "IT""I" "ITS" INTEGRAL AGILE Leadership Personal responsibility Rank Change resilience Careerambition Purpose Engagement Values Organisational culture and norms Psychological safety Collaboration Systems Thinking Skills and Techniques Roles Technical practices Agile/Lean practices in all areas, e.g. Finance, HR, etc Products Design Thinking Organisational altitude Value Streams Organisational structure Governance Physical environment MINDSET& ENGAGEMENT CULTURE & RELATIONSHIP COMPETENCIES, PRACTICES, PRODUCTS ORGANISATIONAL ARCHITECTURE & ENVIRONMENT Inspired by Michael K. Spayd’s work applying Integral Theory to Agile
  11. 11. @AntoinetteCoet 7 Myths of #OrganisationalAgility "WE" "ITS" "IT""I" INTEGRAL AGILE Leadership Personal responsibility Rank Change resilience Careerambition Purpose Engagement Values Organisational culture and norms Psychological safety Collaboration Systems Thinking Skills and Techniques Roles Technical practices Agile/Lean practices in all areas, e.g. Finance, HR, etc Products Design Thinking Organisational altitude Value Streams Organisational structure Governance Physical environment MINDSET& ENGAGEMENT CULTURE & RELATIONSHIP COMPETENCIES, PRACTICES, PRODUCTS ORGANISATIONAL ARCHITECTURE & ENVIRONMENT Inspired by Michael K. Spayd’s work applying Integral Theory to Agile
  12. 12. @AntoinetteCoet 7 Myths of #OrganisationalAgility Organisational agility involves only the technical functions of the organisation
  13. 13. @AntoinetteCoet 7 Myths of #OrganisationalAgility Increasing their agility should be the aim for every organisation
  14. 14. @AntoinetteCoet 7 Myths of #OrganisationalAgility A scaling framework is needed to have organisational agility
  15. 15. @AntoinetteCoet 7 Myths of #OrganisationalAgility
  16. 16. @AntoinetteCoet 7 Myths of #OrganisationalAgility Management sees it as a new Way of Working We start doing things differently without understanding why BUT WHY NOT?
  17. 17. @AntoinetteCoet 7 Myths of #OrganisationalAgility Organisational agility is about the people and the work, not so much the leaders.
  18. 18. @AntoinetteCoet 7 Myths of #OrganisationalAgility Adapted from Simon Powers – Enterprise Agility Masterclass
  19. 19. @AntoinetteCoet 7 Myths of #OrganisationalAgility • Leaders had to let go of the belief that they were the most knowledgeable about their business. • Leaders had to trim down their priorities to attain a Clear Focus. • Leaders became part of their teams. • Started celebrating successes on a team level, not individual. • Leaders had to learn to apologise. • All meetings were cancelled and conversations were moved into the “engine room. “ • Leaders own impediments : instead of waiting for people to tell them they seek it out, look for it and offer help without being asked. What leaders at ING were willing to give up Source : Leonoor Koomen – Global Scrum Gathering London, 2018
  20. 20. @AntoinetteCoet 7 Myths of #OrganisationalAgility You don’t need to change structures to have organisational agility
  21. 21. @AntoinetteCoet 7 Myths of #OrganisationalAgility Traditional hierarchy Start doing Scrum Need to scale so start Scrum of Scrums Recognise the lines of communication Holocracy – flat structure Often get stuck here. Reference: Simon Powers – Enterprise Agility Masterclass
  22. 22. @AntoinetteCoet 7 Myths of #OrganisationalAgility 1. Organisations are implicitly optimised to avoid changing the status quo middle- and first-level manager and single-specialist positions & powers structures. 2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo. 3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, “religion”, and ”needing pragmatic customisation for local concerns” – which deflects from addressing weaknesses and manager / specialist status quo. 4. As a corollary to (1), if after changing the change some managers and single-specialists are still displaced, they become “coaches/trainers” for the change, frequently reinforcing (2) and (3). 5. Culture follows structure. Larman’s Laws of Organisational Behaviour
  23. 23. @AntoinetteCoet 7 Myths of #OrganisationalAgility Organisations should define a To-Be state and a plan to get there
  24. 24. @AntoinetteCoet 7 Myths of #OrganisationalAgility
  25. 25. @AntoinetteCoet 7 Myths of #OrganisationalAgility Growing organisational agility is the responsibility of agile coaches
  26. 26. @AntoinetteCoet 7 Myths of #OrganisationalAgility FIND HELPERS IN THE FOLLOWING DOMAINS
  27. 27. @AntoinetteCoet 7 Myths of #OrganisationalAgility STEP 2 – Develop yourself as leader DEVELOP YOURSELF AS LEADER
  28. 28. @AntoinetteCoet 7 Myths of #OrganisationalAgility @AntoinetteCoet|7Mythsof#OrganisationalAgility

Editor's Notes

  • 1996: I discovered XP along with my team. I am an OO designer / business / systems analyst, working on a LARGE medical aid application rewrite for ???
    2001: I move to the US and as part of a vendor team I teach my team members and the client about incremental / iterative development.
    2005: I stop working on projects and only mentor teams in Agile ways of working (it now has a name). Still only projects
    2009: I find out about this job called Agile coach (newly minted by ACI) and start learning about coaching. I start combining coaching and mentoring AND for the first time my work expands to BAU teams. It’s no longer a way to approach a project, it’s a way to approach WORK (And life – I adopt a KANBAN board for my weekend TO DO’s!)
    2010: I transition 2 long-standing teams in a very large financial institution to an Agile way of thinking and doing.
    2011: I visit the 2 teams – half of the people have left for more flexible organisations, the other half are so frustrated they can rip their hair out.

    MAJOR realisation : Eco system or bigger environment impact
    Start working in business units and include middle management. Until I hit the edge of the sphere of influence and control there too!

    2014: Iam invited to attend an experimental enterprise agile bootcamp. And this really felt like coming home…. So I would like to share the model with you….
  • The bootcamp I attended was held by ACI – Lyssa Adkins’s company – and this work grew out of the fascination of Lyssa’s 2 colleagues with Integral Theory, which was developed by Ken Wilber. It is a great way to look at Organisational Agility as we know it today.

    It starts with a distinction between what we feel and experience, vs what can be observed. Subjective vs Objective
  • It divides both of those into singular, or personal, vs plural, or collective.
  • So Subjective, singular, describes a single person’s subjective experience, whilst the collective would refer to a group’s subjective experience, for instance. What is of particular interest for us here is the right hand side of the model. I often get this question : “I think we are Agile because we have a board full of stickies and we do a standup”. Heard that before? Any guesses to which quadrant that would refer to?

    In the past, when you asked people to tell you what Agile is, a lot of them would be describing ONLY the IT quadrant. It is changing as more and more people realise that the left hand side of the model is as important as the right, in fact the whole model is. And see that right bottom quadrant? That was what was standing in my way…

    So what would organisational agility look like through each of the 4 lenses?
  • Turn to the person next to you and have a brief discussion about where you think your organisation is the most challenged….
  • Yes it started there, maybe we thought that was the biggest problem to solve, but paying attention to only your IT groups is like having a Ferrari in the middle of a flock of sheep – it can maybe reverse really fast and go forward again really fast, but it really is trapped.
    Business Agility conference tells story after story of OTHER parts of the organisation. The biggest challenges at this point seem to be HR and Finance. So if that is where you are challenged, look at the Agile people movement, or the budgetless society

    This kinda leads us into myth 2….
  • Who thinks this is a truth, rather than a myth? Sooooo it’s a bit of a trick question
    Late adopters stage – they HAVE to become Agile, they think
    But there is always an underlying reason. What do organisations think Agile will give them? Hear from the audience….
    Yes! Faster to market, products customers love, absorb change better, higher quality
    Problem is Agile becomes a silver bullet and we start measuring progress of agile adoption, not how much better the problem has become
    Yes, Agile is a great tool for solving complex problems, but saying that our problem is that we are not agile enough, instead of looking at how we are doing solving the REAL problem is like the tail wagging the dog.
  • So let’s next move to HOW organisations are growing their agility…. Hands up who is implementing SAFE?
    Safe has become really popular for large organisations suffering from the Myth 2. Now, don’t get me wrong, I am SAFE trained myself and I in fact think the ideas that Leffingwell publicised in his 2 books were waaaay ahead of their time.
    But let me share a little model with you….
  • If we look at any of the Agile frameworks out there, say XP or Scrum, they are a bunch of practices, that supports the Agile manifesto and Values, that ultimately grew out of a specific Mindset. I am a pragmatist and believe that if you have the essence of something right it could many forms and still be true to the essence. So the practices in Scrum vs the practices in XP vs the practices in DaD don’t matter so much, as long as it does not pollute the essence of Agile.

    And BTW on top of the practices we have tools and techniques, the space where JIRA and facilitation techniques and TDD and a bunch of other things live.
  • So to get back to large frameworks like SAFe, the problem does not lie with the framework. I will say it again. It does not lie with the framework. It generally lies with the underlying PURPOSE of using a framework. The Agile mindset is reduced to a set of roles, artifacts and events and we actually just keep on doing what we have always done. In its worse incarnation it is agile paint by number. It gets rolled out by a set of consultants, leaders don’t have to get that involved and we have our new ways of working, right? That’s just putting lipstick on the pig – it still stinks!

    An additional problem is that because we are doing it paint by numbers – following the form without fulling understanding the Essence – we don’t have a basis to evolve the practices and techniques. We don’t understand enough of the Why.

    Has anybody hear ever heard of the canon story? The canon and the 5 men looking after a canon? Somebody told me this beautiful story about infanterie: although there are only “work” for 4 men, canons are always manned by 5 men. That’s just the way it is. Until one day somebody decided to research why there are 5 men. The answer? Canons used to be pulled by horses. Horses get spooked when a canon fires. The fifth guy was there to calm the horse and stop it from bolting. But because nobody understood the Why properly, when canons were now longer pulled by horses the 5th guy just stayed!

    What is the alternative? A change as profound as Agile, which is a new organisation philosophy, needs time. Changing one person’s mind takes along time, so changing the culture of a company takes a looooooong time. Which bring us to the next myth…
  • So, turn to the person next to you and have a quick discussion about the role of your leaders in your organisational agility effort. If you are a leader yourself, please share.

    I want to take you back to the Integral Agile framework for a moment. Which of the aspects that you see are can be done by the people doing the work that does not require involvement, serious involvement, from leaders? Some of them are even the exclusive realm of leaders. In fact Simon Powers, a colleague and fellow enterprise coach has reduced the road to Organisational Agility to this…..
  • We have a slight difference of opinion on the arrows – I believe they should be double-ended – Simon says they run clockwise, but we have both seen and worked with this so many times that these days I tend to focus on leadership teams exclusively. Here’s the thing – the higher we go up in the hierarchy the more difficult it is to change the way you operate – your thinking, the way you have always done things, things that brought you to the top. And here’s the problem – experience across the world has taught us that it is the attitude, involvement, championing, modelling and individual change leaders are willing to go though that is the single biggest reason for the success or failure of agile transformations. Agility is truly a new way of doing things, of approaching work, of engaging with people in the workplace. It is a culture change. And managers are the keepers of culture, especially in a hierarchical organisation where traditionally thinking happened at the top and execution at the bottom

    To give you a really great example – who has heard of the ongoing, very successful transformation at ING Bank, the Dutch bank? So I would like to share with you, from a talk by Leonoor Koomen, who was the lead of the transformation, some points about what leaders had to give up
  • What I see there is hard…. These are not easy changes. And some people did not make it through this – they went elsewhere.

    Which brings us to the next point….
  • BTW, apparently the day after I grabbed the structure from the internet it changed! So by now it is probably reaaaaallllly old!

    Structures are so much more than organisational structure, it really is the right hand side of the Integral Agile model, but since organisational structure is really the one that creates fear for us – restructure = job losses and change in general – we really don’t like change, hey? – let’s talk about org structure. In the case of ING they created a new structure and EVERYBODY had to apply for jobs in the new structure. Some people opted out at that point.

    We start fiddling with org structure the minute we create a Scrum team at the grassroots level. A SM is a servant leader, PO muddles up the clear separation between business and IT. So if we look at the way a lot of organisations grow in terms of structure when they decide to do things with more agility, it goes something like this:
  • In the most progressive organisations we tend to have a dynamic, natural hierarchy – there are no formally titled leaders, but the teams are leaderful iso leaderless – whoever is willing and able to lead the team right now based on what the situation requires steps forward and leads. I don’t think I have to spell out the level of maturity, personal responsibility etc that is necessary. The reason that I decided to use FBs structure is as a result of a Kent Beck talk I attended a few years ago, when he was still at FB. Personal responsibility is so high at FB that whether it is your problem or not, it’s your problem. He tells the story of a woman that heard he was from FB when he was attending some craft conference with his wife. She immediately told him that FB had lost all her data! And he made it his problem, because that’s the way it worked at FB. In the end it was her hard drive that had crashed, but the last thing she was conscious of was a FB update…

    So having said that – it does not have to happen overnight. It’s one of the bigger and scarier steps on the journey, but it doesn’t have to happen all at once. And it will probably happen more than once. The change will happen incremental and it will take time.

    Because organisational structure changes are not easy. I might lose my job, or at the very least my current status. So I would like to share Craig Larman’s laws with you. Larman and Vodde are the fathers or Large Scale Scrum, or LeSS, BTW…
  • So what do we do about this? Wel.. I can tell you what we DON’T do about it – we don’t pretend it does not exist. We need to find solutions together -> find out where we can reignite people’s passions when they stop being coordinators of work.

    Before we move on to the last 2 myths I would like you to have a brief discussion with the person next to you – what have you seen change in your culture, structure or leadership on your agile journey so far?
  • Of all the myths this is probably the one that has caused me personally the most sleepless nights. It is tied up with needing a scaling framework to some extent and it is probably the hardest one to explain to organisational leaders because understanding it already requires a change in the traditional Predict and Plan leadership mindset. The rate of change in the world continues to grow and where traditionally we could assess a situation, analyse it, come up with a solution and implement the solution Agile at it’s heart says
    Do what you think is the right thing for a short time
    Assess what the impact was
    Base your decision for next action on your assessment

    Some of you will know this as Inspect and Adapt, or PDCA, or Sense and Respond. Because here is the thing: if we thought bringing agility into IT was difficult, it is a 1000 times more difficult. Human systems are complex adaptive systems. In complex adaptive systems it is impossible to predict cause and effect – we can only see it when we look back. So the time we spend on analysing the organisation in order to come up with a plan to get there is much better spent by figuring out where we can start experimenting, so we can see what we the impact is. People, we know from software that upfront analysis creates waste - let’s stop doing exactly the same thing for an ever more challenging initiative!

    And something else : At the recent BAC in NYC I was listenening to the story of a massive investment company – the company that invests the social security funds in the US. You know what their best guess it for how long their agile transformation will take? 20+ years. !!!!!!!!!!!!!!!

    So start where you are. Solve the most important problem, using Agile where it is useful and not because you have it and you need to be agile. Stop as soon as you can, see whether it got any better, use your learning to determine what to do next. Develop that experimental and measurement muscle. And forget the To Be and the plan – in fact, BURN IT!
  • So I want to end where I started – with my own story. And not because it is so special, but because it is the story of many who have been around the block.

    My own changes was mirrored by what was happening in the industry. There is a natural progression here – an organic growth that is necessitated by deepening and deepening and deepening the mindset. I always say just when I think I REALLY know what Individuals and Interactions means, I get another insight. And a lot of it I got from other disciplines. Since embarking on my Agile training I have read many, many books – I have about 350 books in my Kindle collection. And I have spent thousands of rands on training and development in order to solve the problems that I encountered. And this is what brings me to the last myth For this talk anyway! 
  • What in this statement makes it a myth? Anynone? What if I tell you it is a half-truth?

    When you have a hammer everything starts looking like a nail. As agile coaches we try and solve everything with Agile, increasing the agility. And it is not enough. The myth is actually NOT ONLY the responsibility of agile coaches.

    So here is where you should be looking for help, WHO you should be looking to for help
  • If you really want to get into stuff, by all means go and study all of it. But then, don’t we as agile coaches know how well cross-functional teams work? So how about bringing that principle into the organisational agility space? You learn from them, they learn from you, we have a much better chance at success and we come up with ideas together that never would have existed.

    One word of warning: if you do decide to train yourself up in any of these fields, be careful of unconscious incompetence. One can get a degree, masters, doctorate, in any one of the fields above. Please do not assume, the way I see some agile coaches in the community presume, that you are at the same level after a training course than somebody who has spent years studying it.

    Which brings me to the final part about being that coach that truly helps your organisation grow in agility…
  • I’d like to see a show of hands of people who currently work with senior leaders or execs. For the rest of you, what is holding you back? What are the stories you tell yourself?

    Here’s the thing – If you aspire to be an important part of your organisation’s transition you need to become comfortable interacting with organisational leaders. And that will not happen unless you grow your OWN leadership abilities. We have seen that Organisational Agility demands leaders to be better leaders – to let go of control, empower people and so forth. If you grow yourself as a leader, not only can you you support them in their growth, but going though the pain of developing yourself as leader will give you a lot of empathy for them. Because lets face it, it is painful.

    You don’t have to have a gazillion people reporting into you in order to do this – you need to develop you own action logic – the thinking that leads to your responses.

    Yes, I know it is a tall order, but your development really is the ONLY thing that is truly under your control.

  • ×