When You Ask Your Company to Be Agile

An excellent article written recently about how we must stop thinking of Agile as software delivery and understand it as the new way of thinking that it is, was referencing the fact that one of the major complaints practitioners of Agile have is that nothing is "ever DONE" and that developers and managers alike yearn for their post waterfall project completion downtime. This is true and very interesting.It's interesting because in just one symptom it exposes a systemic issue we have in our work places today: an ingrained expectation of things working a certain kind of way. That way sadly revolves around organisational ills and ailments as much as it does around structures and processes we no longer need.Concepts such as 9-5 work days, hierarchies and the resulting monkey throwing games as well as the detailed and extreme planning before any execution, are deeply seated into the mentality of just about any professional in the work force today. We are now asking them to do things differently. If we want them (and ourselves) to succeed, we have to be honest and explore how extremely different this is from their habits and expectations.In a corporate environment most people are stripped of individuality. This is true across the board. Even at executive level, personal responsibility, ownership and courage are far from given. Once you step inside the organisation you feel like you are a clog in a big mechanical organism and therefore you find ways to be human in between mandated processes and directives.When a long, often times harrowing, incomprehensible and frustratingly slow project is done in a big organisation, that is the time for employees to breath in a huge sigh of relief and wait for the next un-relatable task to be bestowed upon them. Usually, they failed to understand why they were doing this in the first place, why they were doing it in what seemed to be the most painful way imaginable, and certainly, why it had to take twice as long and have everyone fear for their lives. The end of a classic waterfall project is like the end of an initial scene of horror movie sprint away from the imminent threat when the movie-makers still want us to believe they stand a chance, with characters on the ground, panting, filled with loathing and dread but pleased they survived. For now. It's done. It's trauma over they can begin to heal.In Agile practices that moment never comes. But neither did the trauma. This isn't the ordeal a waterfall project is. This is another way of seeing what all needs doing the fastest, to keep making cool things for the end consumer. Developers and managers alike can't rely on the downtime coming from the delivery sign-off anymore, they need to instead learn to be adults and get their own ways to decompress when they know they need them, to keep going and be sustainable in lieu of waiting for the flaws of the system and process to offer them.In corporations, we not only fall down flat at the end of a project race but take any process or tool flaw or misgiving, as an opportunity to take a breather. The missing license, the machine that broke, the colleague who "has the ball", the impediment that hasn't cleared, the approval not having come through, the other guys not answering, etc. All of them breathers. Times to dissociate and wait while someone else has the monkey. Of course humans have to rest. In the old way of work, this rest comes when the system lets them down.Sometimes the system fallacies even give way to another intensely human behaviour . Moaning about things not working. It has become the only humanity moment in a work life where we repeat acronyms and platitudes ad nausea. We need the stuff that goes wrong because then we can do the complaining that unites us.This is the most vicious of circles we will have to break to truly become Agile in big organisations: in the waterfall old ways of work, the system relentlessly reinforces processes and ideas that are fundamentally broken and to survive it, employees reinforce the usage of the broken bits themselves. That's why we need to hit the big "reset" button. That's why we can't "introduce Agile in parallel" as a hobby or a side project.Related: Agile and Lean Is Not Only for IT With that said, one fallacy I see a lot of these days, is the presumption that the tension between waterfall versus agile is perfectly resolved in start-ups (and implicitly in our industry, in challenger banks). Much as they would like to have you believe they are intensely nimble, new outfits sometimes struggle too.Let's be honest: Agile doesn't come easily and naturally - in particular to consummate professions who have spent many years in corporate environments before starting on their own and have to show investors they have all the answers.I say this often but Agile is not for IT. It's for the whole organisation. Every department everywhere will work this way. It's not for "the new kids" - it's too beneficial to wait for a change of guard so anyone with as much as 5 years left before retirement had better learn how to become a practitioner or prepare to fail.Truth be told, we like Agile on paper but in practice, it's hard and seemingly counter-intuitive for anyone who has worked in the old style of work across the board not only in corporations but in start-ups too.

Agile is asking people to:

Be ballsy - this can go wrong in so many ways, there's so much unknown and scary "what-ifs" we have little to no experience in dealing with. Be "always on" - no backlog item can be left un-debated, nothing can be done on automatic pilot with no thought invested. Be creative - things they've known and tried may well not work again. Everything is changing and that's disconcerting and scary but once they see the value of spotting the new way, having a crazy thought or trying out a new path, everything is easier. Be "owner" - once they move that ticket on the board (or get their name against it in Jira or Trello) they must feel like that were the most crucial task of an imaginary start-up they are the CEO of. Be open minded - don't take it personally, be prepared to be challenged, questioned and second-guessed whether you're a product owner or one of the team. By others and yourself.None of those asks have ever been asked of our workers before, and none of them come naturally. No one can blend in as a clog in a big organisation and wait for the blessed relief of the end of the horror movie chase. It's not easy. It's not comfortable. Things to try in order to manage the uncomfortable: Celebrate small victories. From doing an internal happy dance when something is moved to the "Done" column to having team beers after a velocity win, every time we achieve something we should take stock and take pride. It's a hard lesson to learn as compared to the annual stakeholder meeting or the yearly performance review but Agile gives us reason for often, incremental joy and we should use it. Take breaks, work at your own pace. Teaching people to respect themselves enough to learn and stand up for their own rhythm is paramount. Don't let people yearn for the waterfall delivery point. Is it a sprint? Yes but sometimes picking up just the one ticket is judicious and wise and the team needs to see it that way and support it. There's no risk of that opening the door for anyone taking advantage because the size of the team would quickly expose that. Can we afford to let people have their own pace when the very reason we do Agile is to be fast to market? Absolutely - you can only win the collective race if every player is irreplaceable so they each took their own marathon seriously. Keep the heart. Always go back to "religion". Why are we doing this? What are we making here? How will the end user feel when they get their hands on this? True customer centricity is building something you intensely believe will make your end users happy and then reminding your team and more importantly, reminding yourself of that on a sprint basis. Remember the alternative. Keep comparing. If you were to ADDIE this when would you be done and when would your competitors be out? Praise as a practice. Teams who learn the value of praise end up turning the criticism in retrospects and evaluations into positives - because identifying what went South and talking about it is a major win that deserves smiles. Don't punish but shoot straight. Organisations that change the culture of sanction and create psychological safety win. When something goes wrong it just ticks off a bad-turn off the list. This is a tricky one though because in this day and age of Political Correctness craze, many outfits confuse psychological safety with non-straight-forward communication. Agile is nothing if not honest, open hearted dialogue. Hiding behind being PC language is fear, speaking from the heart but knowing it lands well and it's well received and constructive to the team is the courage we need in Agile.The last one is not an immediate fix but one that I believe we need either way. It won't help replace old ways of work with the WoW du jour but it's the only succession planningwe should spend time thinking of - mentality and how our next generations, unblemished by corporatitis and competing with automation can make themselves indispensable. Pre-load Agile into our kids. We need to catch ourselves before our understanding of hierarchy and the value of extreme and complete planning sip into the new generations. They are the tabula rasa that will succeed if we instil the right way of thinking."No Timmy, you can't start on this science project before you've written down the plan for building it in detail, laid out all your utensils and ensured you have the time and tools to build your helicopter."versus"A helicopter sounds cool. Which bits of it do you already have or can you make right now as we're discussing it? Here, I'll draw a helipad on this piece of paper and if you can tie those pencils together you have the propeller. If you list all the bits in this Backlog column you can already move "helipad" and "propeller" to the "Done" column and pick another part."Fast forward 3-40 years and hopefully the educational system would have caught up too and the few humans still employed would have had their formal thinking processes structured around these new values but for now, we should all roll our sleeves, interact openly and teach each other.This is not an exhaustive and immutable list of invaluable advice. Just some idea-cards from the " Change antiquated way of work" board moved from the " Stuff that may make transition easier"column, into the " Currently trying out" column that you can click " Duplicate" on.