\r\n\r\nSo if you believe agility is not for you, then just ignore such challenges and happily keep doing what you always did.\r\n\r\nAlas! Everywhere around you people are taking measures to increase agility, including your team mates! Can’t have that, can we? That will lead to inevitable change. Unwanted change!\r\n\r\nNoooooo! (Imagine cries of despair, strong feelings of insecurity and a sense of utter hatred).\r\n\r\nFear not! You can sabotage your team’s agility from the inside. It’s as easy as eating a muffin. Here are three common ways to help you get started:\r\n\r\n1. Stand your ground: you are a specialist!\r\n\r\nNot just a specialist, you are a professional specialist! You know that the only way to remain a valuable specialist is to put many hours into doing what you do best. At least 10.000 fine hours of dedicated specialist work will make you recognized as an expert. No other work can be in the way of that mission. You need to focus! And by the way dear agile coaches and Scrum Masters, isn’t focus a core value in Scrum? So leave me alone, will ya?\r\n\r\nNow these agile guys will tell you that you need to be responsible for the team’s results. Yeah right! Isn’t that exactly what you’re doing by being an expert? Without you there wouln’t be any results! How’s that for responsibility? You team mates should take their responsibilities too by doing their parts properly! You may have to remind them of that often. Especially the junior people in the team who will surely listen to what you, the expert, say. And that darn agile coach…she doesn’t understand what you’re doing anyway.\r\n\r\nStand your ground as a true professional! A dedicated expert! Be proud, not a prick like that uneducated agile coach buffoon!\r\n\r\n2. Stay busy! Ask for more work!\r\n\r\nWork needs to be done! We need to be productive! It’s already bad enough to waste so much time on those darned planning sessions and retrospectives. You are happy that the sprint review takes just 15 minutes (you insisted on that of course, didn’t you?) and that you don’t have to show up at those awfully boring refinement sessions. Being busy is what keeps you satisfied. You’re an expensive specialist, remember? Better churn out good quality work as much as possible.\r\n\r\nSo make sure that each user story contains enough specialist work for you. And if it feels like there isn’t enough to do for you, then demand that more user stories are drawn into the sprint. You could at least do some work on those stories for the next sprint. That will save time. The Product Owner should understand that she should use her valuable resources to the max, shouldn’t she?\r\n\r\nDemand work. Always. If you can’t get it within your own team, perhaps you could start being part of another team also. This is especially handy if you are much in demand as an expert. You wouldn’t even need to be part of any team! You should work wherever there’s the most work and the most fulfilling work! Yeah! People will understand that, wouldn’t they? That’s true agility: being flexible. Eat that, coach!\r\n\r\n3. Demand enough detailed information to do a proper job!\r\n\r\nNow during those dreadful planning sessions there will be a lot of user stories passing by. Make sure that you know exactly what is expected of you for each of those stories. Demand enough detail so you can do a proper job.\r\n\r\nNow when that darn Scrum Master or agile coach starts using the painfully ignorant argument of “but we should discover information during the sprint”, just tell her that she isn’t realistic. Such a thing would take way too much time. You, as a specialist, would have to wait endlessly for your other team members to figure stuff out. Leaving you sit idle for an unknown period of time. Screw that! No way! Too risky!\r\n\r\nMake sure that you get the info you need. Perhaps you could suggest that we split the team up in people that prepare the work and people that do the work. Oh, and people that test the work, of course. You could be in any of those three sub teams, depending on your specialism! How great would that be?\r\n\r\nBonus 4. Get your product owner to write more efficient user stories!\r\n\r\nIt would be best if a full user story can be done by you alone of course. Or with just the help of a peer who is also a specialist in the same field. So you can be twice as productive and spend a lot of time on reviewing together! Quality first, especially in agile, remember? Tell that to that bloody Scrum Master on the first occasion! She knows nothing about agile!\r\n\r\nGood stories are written for getting them finished quickly. So there would be stories to prepare the architecture, separate stories to get the data right, other stories to get that front-end up and running, API stories, mock-up stories, back-end-connectivity stories and bug-fixing stories. Of course.\r\n\r\nOf course! Why didn’t we think of that earlier? Why don’t they teach this awesome stuff in those agile trainings?\r\n\r\nAren’t we sick and tired anyway of using that time-wasting “as a user I want…” format anyway? It doesn’t work! We’ve been ploughing through endless refinement sessions and we don’t seem to learn it, no matter how much of our prescious time we invest in it. Aren’t we supposed to throw out stuff that doesn’t work according to that agile mindset thingy?\r\n\r\nAgile is just so easy! Just try these things. Success guaranteed, especially in teams that didn’t yet receive much manipulative agile training.\r\n\r\nIf everything fails and everybody still insists on “being agile” and make your life miserable, then just go to a manager and explain what’s wrong. That’s your number five bonus tip on sabotaging agility for the team.\r\n\r\nGo get ‘em! Get heard! You deserve it!\r\n\r\nDisclaimer: This article has a strongly provocative tone to make a point and help people improve. Everything in this article is based on recurring real-life experiences. Don’t confuse it with cynism, sarcasm or even irony. Okay, maybe a bit of irony. Or a lot. Keep laughing 😉\r\n\r\n