It’s tempting at some point during a project, epic, feature, or any piece unit of work to go back to the way you used to do it because it was “easier”. But the question that has to be asked in that equation is – “Easier for who?” For your team? For your stakeholders? For your QA team? For who, this is the question. It might be easier for you to go back to how you…
How can we deliver faster. And my gutshot initial reaction? “Let’s talk with your team.” There is generally shock on everyone’s face when I answer the question in that way particularly because they initially think – “but they are the team that is currently delivering slowly?”. Yes, but do know why they are delivering slowly, what is holding them back, what is blocking them, what ideas they have to make it better? These are the…
It never works. It never works because people have questions and you’re not answering them. Ramming change through your team without hearing their concerns or input is about as valuable as ramming a car into a tree to take it down. Sure you might “get the job done” but in the process, you’ll destroy the car, hurt the driver and leave the downed tree a mess so it can’t be reused for anything else. Ask…
It doesn’t happen on a dime. It doesn’t happen in two months. It doesn’t happen in a year. It can, but if everyone is not on board, it can’t.
Then here are your options; Find a new platform.Code a workaround. You can code anything, there is a myriad of languages and frameworks out there to do it. You can code anything. But going back to your user and saying “change what you are doing because we can’t do it” should be the last, final, dead stop resort only after you have exhausted all these other choices, not the first.