Overcoming Organisational Defensiveness

From CitconWiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
  • To introduce change you need to prove the value of it, and to prove value you need something that you can measure and a baseline to compare against
  • Metrics are good, but there are people and "feelings" involved
  • But feelings are data. You experiment by introducing change and reactions are still metrics based on which you can reach a conclusion
  • Some things are really hard to measure
  • But some managers do want figures
  • Yet you should be careful to be driven by sole metrics
  • Book Succeeding with agile by Mike Cohn
  • Book Crossing the Chasm was mentioned. Important thing to remember when trying to introduce change/sell something: you have innovators, early adopters, early majority, late majority and laggards and you can not sell to one as you sell to the other. This should be kept in mind when you try to introduce a new idea and are pitching it to someone.
  • Risk tolerant and risk adverse. First group will tolerate risk in the face of gains from change, while the latter will refuse to change and only do so when the large majority will be on board and they don't want to be left behind.
  • Best chance to get through is to start by finding a current pain and then fixing it
  • But what if you don't see the pain? That's just marketing. Showing the pain is part of the deal and sometimes you can try the hard way, ie resign or refuse to work/do some task
  • When we try to convince something we might be losing objectivity, convincing is possibly dangerous
  • "Software will always have bugs and that's just the way it is" by Some Manager - hard to create compelling metrics
  • Standup meetings in the fire escape because manager does not approve. Careful to make changes that can poison future ones.
  • Pilot agile teams can backfire, they become assholes and pretend to completely subvert rules the rest of the organization relies on. handle with care.
  • When creating metrics avoid embarrassing/offensive ones or they will be ignored or even worse
  • Leaders want to change their teams based on emotions, "don't want my team to go through this again"
  • If your company is happy and everything is smooth no point in becoming agile, except maybe fear of becoming complacent and eventually failing when new customer comes up that messes up your routines
  • Also bear in mind that some companies are profitable and do well even tho their processes completely suck, dev as a commodity works for some
  • Introducing agile: listen this american life - numi plant (toyota, gm). Failed to take it from numi to other plants because they've never been through plants being shut down, hence they were more interested in union rights etc
  • Some managers wanted "pictures" of the numi plant to replicate the experiment failing to understand the concepts
  • Propose agile under a different name
  • Proposal to solve a practical problem
    • Jenn has been hired to sort out the mess in this company that is using the same techs and methods they were in 1995
    • Problems: always late with deadlines, lots of bugs, lots of duplication - 30 versions of the code
    • Instead of the 5 whys, do the 5 "so what" ie I'm gonna introduce bugs. so what? so I'm gonna lose customers. so what? so I'm gonna lose money. so what? I'm gonna fail... etc
    • Sometimes people will hire others to fix a problem expecting no demands on themselves
    • If people aren't accountable they won't change
    • Identify key people and introduce things to them over lunch/beer. they'll then do dissemination with the rest of the group
    • Key person can be too busy, need buy-in from management to allocate some time to this process
    • Do retrospectives to understand where the problems are