Colin Grossman "Coaching Outside the Agile Team"
•Download as PPTX, PDF•
1 like•105 views
"Coaching Outside the Agile Team" by Colin Grossman. Agile Tour Vilnius 2018
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Colin Grossman "Coaching Outside the Agile Team"
Similar to Colin Grossman "Coaching Outside the Agile Team" (20)
More from Agile Lietuva
More from Agile Lietuva (20)
Recently uploaded
Recently uploaded (15)
Colin Grossman "Coaching Outside the Agile Team"
- 1. Coaching Outside The Agile Team (or how to defeat your Agile enemies!) Colin Grossman - Agile Tour Vilnius 2018 @TechAtTreatwell
- 2. About Me ➔ Lead Agile Coach, Treatwell Building the world’s leading Hair and Beauty Marketplace! ➔ From Scotland! But living and working in London ➔ Fascinated by Culture ...and what organisational culture means for Agile
- 4. About Me ➔ Lead Agile Coach, Treatwell Building the world’s leading Hair and Beauty Marketplace! ➔ From Scotland! But living and working in London ➔ Fascinated by Culture ...and what organisational culture means for Agile
- 7. About Me ➔ Lead Agile Coach, Treatwell Building the world’s leading Hair and Beauty Marketplace! ➔ From Scotland! But living and working in London ➔ Fascinated by Culture ...and what organisational culture means for Agile
- 8. Build useful, valuable products. Sooner. Be happier at work.
- 9. 12th Principle Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. “Regardless of methodology or surrounding organizational structure, a delivery context of motivation, trust & empowerment is vital for success. However, such a context is not an effect of adopting an Agile process but a prerequisite.” Source: 12thprinciple.org
- 10. The bad news... This is really, really hard!
- 11. The bad news... This is really, really hard! (And... I don’t have all the answers!)
- 12. Demanding Executive Often found in start-ups or growing companies. They want it all, and they want it now!
- 13. Avoidance Strategy “Shield” the team.
- 14. Suggestions Tackle head on. Make the impact visible and use their language. Be honest. Talk about trade-offs. What do they have to give up?
- 16. Suggestions Show how good culture leads to business success. Use data. Tackle head on. Make impact visible and use their language. Be honest. Talk about trade-offs. What do they have to give up?
- 17. Zealous Sales Team Services organisations and B2B product teams. Targets and commission.
- 18. Avoidance Strategy Leave spare capacity or ring fence team members. Cut corners.
- 19. Suggestions Be more cross functional. Bring the teams closer. Share experiences. Walk a mile in our shoes. Find shared, mutually beneficial goals and KPIs. Prove it works.
- 20. Centralised Technical Authority Big enterprise problem but seen everywhere. Love consistency, lack trust.
- 21. Avoidance Strategy Tinker where we can. Innovation time. Get your pitches right.
- 22. Suggestions And then...focus on principles not specifics. The pyramid of consistency! Start small. Talk about experiments, not changes. Use parachuting and secondment.
- 23. IntelliJ / Eclipse Jenkins Elastic Search Redis React Spring Boot Hibernate Java 8 Maven Build Rabbit MQ Gitlab Maven Repo Node JVM Postgres Docker GIT AWS Linux Gitlab CI Python Java 11 Consistency less important Consistency more important Alternatives we like
- 24. Controlling PMO Love plans, metrics, reporting and budgets. Worry about dependencies. Data gives them a feeling of control.
- 25. Avoidance Strategy PO (or even Scrum Master!) has to “deal with it”. Pitch guesses as plans. Scaling frameworks?
- 26. Suggestions This is uncomfortable. People’s jobs will no longer exist. Challenge assumptions. Ask “why” a lot. Organise teams for independence.
- 29. Final Tips ➔ Be Bold Tackle issues head on but respectful and empathetic. ➔ Be a Good Story Teller Use successes from elsewhere. Paint pictures. ➔ Be Patient Changing behaviours is hard and takes time. Don’t give up.
Editor's Notes
- My name is Colin. I called this talk “Coaching Outside the Agile Team” which doesn’t sound very exciting so I’ve also given it the subtitle - “How To Defeat Your Agile Enemies” to make it sound a bit more dramatic. Like a superhero movie! If you plan on Tweeting about this talk at all, please mention @TechAtTreatwell - oh and only say nice things!
- First up I’d like to tell you a little bit about me! I work for a company called Treatwell
- At Treatwell we’re building the world’s leading hair and beauty marketplace. Like Deliveroo or AirBnb, but instead of booking holiday apartments or ordering takeaways, on Treatwell you can book hair and beauty treatments. We connect millions of consumers with tens of thousands of salons, we operate in 11 countries, including Lithuania, so straight after this talk you can download our app and book your next haircut or manicure or massage on Treatwell! Our tech team is based in London and here in Vilnius - some of the team are here today - and I get to come here to Vilnius quite a lot and I love it!
- I’m originally from Scotland which is why I have a strange accent - I hope you can understand me - I’ll try to speak slowly.
- Scotland looks a lot like this. But now I’m based in London….
- Which looks more like this, but I’m not bitter about it!
- I’ve been working in and with Agile teams for a long time and what really fascinates me is why certain company and teams are so successful with agile whilst others find it more difficult. I believe a lot of it is do with organisational culture so I spend a lot of my time thinking about culture and what we as Agile Coaches and practitioners can do to influence organisational culture. But what do I actually mean by being successful with Agile? To answer that, we should remind ourselves why we do Agile, or why we want to be Agile? What are we trying to achieve?
- My take is this. We want to build good stuff that we feel proud of, and we want to ship it to our users sooner. And crucially, we want to be happy at work. Those of us old to remember the days before Agile was such a big deal will know that not only did we completely fail to achieve these things, we often didn’t even try. These simply were not our priorities. And of course today we succeed to varying degrees, but, I believe, these are the core motivations for being Agile, doing Agile, getting better at Agile Understandably as Agile teams and Agile Coaches we spend a lot of time working within our immediate sphere of influence. And in most teams we can make a lot of progress doing this. We can follow an Agile framework like Scrum, we can adopt Agile practices like TDD and Continuous Delivery, and we can change our own behaviours to become more collaborative, deliver more iteratively and just generally be more awesome. But sometimes stuff gets in our way. And by stuff, I really mean people. This talk will hopefully give you a few tips on how to deal with these troublesome individuals
- Most of the 12 principles behind the Agile manifesto talk about the Agile team. Welcoming change, simplicity, self organisation, reflect and improve etc - all about the team doing the work With one exception - “Build projects…” This one is all about the wider organisation. Some Agilists who felt this principle was uniquely important call themselves the “12th principlists”. This is kind of annoying because, of course, this is the 5th principle in the list, not the 12th. But they called themselves the 12th principlists for some reason! If you can get over that trauma, you can sign up to be a 12th principlist at 12thprinciple.org. Have a look - it’s good stuff. And they point out that “Regardless….” In other words, you don’t get a good environment from doing Agile, you need a good a positive environment first, to then be successful with Agile. This is really powerful. Because if the right kind of environment is a prerequisite for success, shouldn’t we spend serious time and effort trying to make this happen?
- OK, now for the bad news. This is not easy! To help build the right kind of organisational environment, you might need to influence your company’s culture. You certainly need to change how people behave. And people outside your team, so people you don’t get to spend time with every day. And people who are often experienced, senior, influential and sometimes difficult to get hold of. And people whose motivations may not always be aligned with yours - or at least it can appear that way. So, yeah, easy, right?
- And, this is where I have to make my big confession. I don’t have all the answers. But you’re here now so you might as well listen to the end! To prepare for this talk, I interviewed several other Agile coaches and have combined their wisdom with my own thoughts. There were several common themes that came up, I’m going to introduce you to four characters. Four types of people who, left to their own devices, can do or say things that make our lives in Agile teams difficult. Hopefully you’ll recognise some of these characters! For each, I’ll introduce the character, then I’ll talk about some of the obvious things we try, and then move on to some tips to try to tackle them a bit more effectively. Ready for the first character?
- This is the overly demanding executive. The guy who wants everything *now*. They want you to go faster, and increase quality, and be more predictable and do it all with no risk and absolute certainty and “can’t you just work a bit harder” and “come on team, there must be a way to deliver a year’s worth of work in three months” and….you get the idea. Sound familiar? You see a lot of these guys in start-ups and fast growing companies. I remember one start-up co-founder I worked with who when asked to prioritise between several major initiatives would literally fold his arms, pout and say “I want them all”. Another CEO I worked with would come and bang on people’s desks, telling them everything they were doing wrong, pause to go for a cigarette then come back and pick up where he left off. The impact on the Agile team of this behaviour can be serious. We want to work at a sustainable pace and these guys think the answer is for us to work crazy hours. We want to build quality products and this kind of pressure can tempt us into cutting corners.
- So what do we do? We talk a lot about shielding the team. Let’s shield the team from the crap. Let’s keep these guys away from the developers. Maybe the Product Owner or an Agile Coach or a team manager can protect people from these guys. Maybe they can be the crap-shield. You might even get to the stage where they don’t talk directly to developers at all. But if that’s the best we can do - stopping people from talking to each other. If that’s a good result, that’s kind of depressing, isn’t it? And it doesn’t really work. Even from a distance, the exec’s behaviour and decisions will impact the team. If you have a Product Owner who pushes a bit too hard to get stuff into the sprint, or a manager who suggests you can cut writing some important tests, the chances are you have leaky shield. And nobody wants a leaky crap shield! Somebody is demanding something unreasonable and your PO or manager are passing on a little bit of the pain. So what can we do? Once again, I don’t have all the answers, but here are a few tips:
- You need to tackle this situation head on! Shielding, dodging or avoiding won’t work. You need be brave and have difficult conversations. You need to be patient and you need to be persistent. This doesn’t get fixed with one meeting or one slide deck. Make the impact of their decisions clearly visible. If developers are burnt out and struggling, show the impact on the team. If the fact that you cut corners in your code in the past, is slowing you down now, show how cutting more corners will make things worse. But you need to use the exec’s language. There’s probably no point talking about test coverage or minute details of your stand-up format. Talk about the impact on shipping valuable product for the business. If you have a morale problem, talk about the impact of losing people and the cost of bringing new people on board. And all of this needs to be done within the context of showing that your goals are aligned - the demanding exec wants you to deliver value for the business and you want to deliver value for the business. Don’t let them forget that! Be honest. Talk about trade offs. Be very open about what they need to give up and why. I had a real breakthrough with that shouty CEO I mentioned, when…
- I literally showed him a slide that looked like this! I explained that why he shouldn’t retain control over every little decision, how in our environment where teams were constantly changing and growing and where we were doing really complex, innovative stuff, the level of predictability he was expecting wasn’t immediately possible, and how it wasn’t healthy for him to have visibility of what each individual developer was up to every minute of every day! I thought he would fire me on the spot but he loved it. Nobody had ever explained things to him that!
- And show how good, positive culture - trust, empowerment and autonomy - leads to business success. Use data, use case studies from other companies who do this stuff really well and who have been hugely successful. Show them that this is way to build a successful company! OK, shall we move onto the second character…..
- Meet….the zealous sales team. So, when I was putting these slides together I was told that nobody under 30 would get the movie reference here. Do you know who this is? This is Tom Cruise as Jerry Maguire - a movie about a slick sports agent.. Anyway... This is all about the sales team that promises the world, but then you have to deliver. Maybe you are building a B2B product and these guys promise a whole bunch of features will be added to the product, but without checking with you first. Or maybe you work for a software house and they promise delivery to a client by a crazy impossible date. The problem here, is that these teams have targets and they get paid commission. So they do what they have to do to make a sale. Which is completely understandable. But they’re not the team that has to deliver. We are! We have to drop everything, we have to cut quality, we have to work weekends, we have to deliver features that provide less value to the rest of our users because they promised them to this one customer and we just need to get the sale over the line and then everything will be different next time, I promise, honest….. Again, sound familiar? So, once again, I’ll talk about what teams often try and then some tips for getting to the root of the problem.
- I’ve worked with teams where we just accepted this would happen. That’s just sales. We can’t change them. So we set ourselves up to deal with it. We embrace the inevitable. We might plan to have “spare capacity” to work on whatever craziness they come up with. “Spare capacity” is just a euphemism for working on less valuable stuff than we could be working on. Or we might even ring fence certain people on the team to drop everything when a last minute request comes in. Or, again we cut quality, work crazy hours do whatever it takes to get the job done But whatever we do, this stops us from doing our best and building great stuff. So what should we do with this lot?
- The key here is all about being closer. We need to work very hard to eliminate us vs them thinking and language. You might hear sales teams say things like “if only the development team were more commercial”! Which is maddening because we’re motivated by building, useful, valuable stuff as soon as possible - which sounds pretty commercial to me. So, first up, help the sales team to really, truly see the impact of what they do. Show them all the things you have to drop to make way for their “just one feature”. Again, like the exec from earlier, show them how cutting corners to hit a deadline now will slow you down in the future. Explain what it feels like for you to work this way. Try to find shared goals and objectives that you can work towards together. For example, ongoing satisfaction of the customers they are selling to. This is something that you can influence and they can influence. Whatever measures you land on, test them and prove they work. Then, if you can get these baked into the sales team’s target and commission models, even better! And lastly, you can try, and this is always hard, to make changes to your organisational structure. Try to bring sales people, and people who work closely with sales teams, into your cross functional fold. This is easier in some companies than others, but if you have teams that specialise in selling certain capabilities and development teams who build those capabilities, bring those teams together into one cross functional group.
- OK, ready for the next one….? Meet, the centralised technical authority. The wise Jedi council who must approve all technical decisions. We see this most obviously in big enterprises, but it can happen in smaller companies too. Where certain people retain a bit too much control over the important decisions. Often, this is all done in the name of consistency. We need to be consistent. But consistency for the sake of consistency isn’t always the right thing to do. And sometimes the need to get decisions approved by a higher body demonstrates a lack of trust in the teams actually building stuff. And of course, all this approval red tape will slow us down and stop us innovating. And this is not a very motivating way to work. We all want autonomy. We all want to be in control of how we work and what we build, and we don’t like being told what to do. So what do we usually do about it?
- Well, we make some technical changes round the edges. We tweak what we can; what we are allowed to. We make do with the scraps of autonomy we are given. Or we might get permission to spend some of our time “doing innovation” to try out new technology. Which is nice, but if there isn’t a way for us to then turn our successful experiments into production software, it can be really frustrating. Or, we just put in a load of work. We spend our time making our case, building a presentation, writing a bunch of documents, getting approval for the new framework we already know will make our technology better. Which usually feels like a massive waste of time, right? So, some tips…..
- Depending on how entrenched this sort of thing is in your company, you might well need to start slowly. Find a decision you would like to make yourselves that would normally need approval, but in the grand scheme of things isn’t perceived as being *too* risky. And say you want to do an experiment where you won’t take the change to the authority for approval. You’re not changing the process, it’s just an experiment. It’s harder to say no to an experiment than a change. And, hopefully, everything will go brilliantly (because you’ll make sure it does!) And then you can do another experiment, and another. And before you know it, you’ve proven your team of highly skilled engineers can actually make good technical decisions! Another option is build trust by bringing someone of the design authority group into your team. Ask them to come and work with you for a few weeks or a couple of months. Sometimes, these people can have big egos, so they’ll like being asked for help! And, hopefully they’ll see that you guys are smart and can be trusted, and also feel like they have imparted some their great wisdom to you. And, of course, you probably will learn some stuff from them along the way. And once you’ve had some small successes, that’s when you can think about going in for the big win. Once a few of your experiments have gone well, or you’ve worked well with the design authority on your team, you can move away from talking about specific cases and start to talk about general principles. Instead of getting agreement about which specific decisions the team can take on their own, try to establish types or categories of changes. At Treatwell, we’ve thought about this and come up with….
- ...the pyramid of consistency. Which is actually a triangle, of course. But we called it a pyramid and we’re sticking with it. At the bottom are things that we believe there are very strong business reasons for keeping consistent across our teams. (The pyramid isn’t complete - this is just an example to illustrate the idea). And at the top are things where we don’t really care what individual teams or people do. So, you’d need a very, very good reason to deploy something somewhere other than AWS, but we don’t care at all what IDE you use. With most choices somewhere in the middle. And over here in the cloud are some alternatives technologies we’re planning to bring in to the fold at some stage. We can use this as a framework to guide teams on which decisions they can make themselves, which decisions need to be discussed with other teams and which need some kind approval. But however you do it….establishing principles to give you a framework for making more decentralised technical decision making is really powerful. OK...one more to go!
- OK, last up….we have the controlling PMO. This could also be portfolio management, or finance or whoever looks after your budget. These people love plans, metrics and reporting. They want to know what’s going to be delivered, how much it will cost, when, how much it will be worth, whether everything it on track etc, and because budgeting is often an annual process, they want to know everything that’s going to happen for a whole year. Sometimes, they also worry about dependencies between teams. If you don’t deliver *everything* on time, someone else can’t do their bit and the whole spreadsheet comes crashing down! These teams love data and they love to know everything that you are up to in minute detail. Because that gives them the sense that everything is under control. Oh, and because these folk like to plan and track everything, they are not big fans of change. This causes all kinds of problems. Apart from the obvious - that if we can’t deviate from a plan - this is not Agile…. Teams can become obsessed with living up to their estimates rather than just building great stuff. And because when these people ask us questions we’re not allowed to say “we don’t know” even if we don’t know, our businesses make decisions based on wild guesses as if they are facts. This is not healthy!
- So what do we do? I’ve seen teams where the Product Owner (or even the Scrum Master) just has to deal with this situation. They have to write reports, update plans, provide detailed estimates and costs, report on actuals vs plans and so on. Sometimes, as I say, we guess! We guess what we’ll do when and we tell the PMO this is a plan. We’re not allowed to say “sorry, I don’t know what we’re going to build in six months time and, by the way, that’s a good thing” so we make it up. And then we have Agile scaling frameworks. This is not my area of expertise - I believe Dmitry is talking about this right now in the other room - but it feels like some of these frameworks try to mediate between the planning and control needs of enterprise style portfolio management, and on the other hand, Agile delivery teams. How successful this can be, I have some doubts!
- I’ve had some success challenging assumptions. Ask “why” a lot. Why do we need to know this now? What would happen if we didn’t? Would you rather I guessed the answer, or would you rather I was honest when I don’t know? Try as hard as you can to design teams in such a way that you minimise dependencies between teams. The less coordination between teams you need, the less there is a case for overly controlling, centralised management and monitoring. Try to align your development teams to business capabilities, or business units with specific goals, KPIs or even P&Ls. And make sure your teams have all the people and skills needed to deliver everything for that business unit. If you can keep your teams focused and independent, hopefully you won’t need as much bureaucracy. And we need to be understand that changes in this area are a big deal. In progressive, Agile organisations some traditional jobs no longer exist. We need to handle this sensitively and respectfully. And we need to figure out other ways for people to add value to our business.
- So, there you go…. The zealous sales team The controlling PMO The demanding exec And the centralised technical design authority. Four types of people who can hinder our progress with being Agile and who we, as Agile Coaches and practitioners, need to influence to help our teams become more successful.
- Before I finish up, time for a quick shameless plug! We’re hiring in Vilnius and in London! We don’t have any of these problems at Treatwell, obviously - everything is perfect! But seriously it’s a fantastic place to work. There aren’t many industries lwft that haven’t been fully digitised. We might be building one of the last great online marketplaces! We’re doing really great, challenging work, we have a lovely team and an incredible company culture. We’re hiring for several roles in London and here in Vilnius we’re looking for developers, and hot off the press, as of yesterday, I’m looking to hire an Agile Coach here in Vilnius. If you’d like to find out more, please talk to me, or one of the TW team in one of the breaks or go to treatwell.com/tech (the Agile Coach role isn’t up there yet, but will be soon) or email me colin@treatwell.com and either way, whether you are interested or not, please follow @TechAtTreatwell on twitter..
- OK, so my final tips for influencing and coaching outside the agile team…. Be brave. Don’t shy away from difficult issues but be respectful and empathetic. Everyone we coach and influence has their own perspective and is trying to do their best. Tell stories. Paint pictures of how things could be or can be. Lean on successes from elsewhere, either from within your company or from outside. We have a fantastic community of helpful people in the Agile world - use them! And be patient. Changing behaviours and mindset and culture takes time. Don’t give up because when we get this stuff the right, the rewards are huge.
- Thank You!