Stay on the same course as everyone else. Don’t colour outside of the lines. Stay in your box, maybe make it smaller to be on the safe side. Don’t try anything new, do what everyone else is doing. After all, 1 million, billion cannot be wrong, can they? Stay the course that is safe and well worn by those in front of you (no need to create a shortcut to get their faster). Never try…
Then I guess the team is too busy to design it? Too busy to code it? Too busy to test it? Too busy to fix it? Too busy to help? If you’re not willing to take the first step towards resolving your problem, writing it down, then how do you expect to get others on board to help you? Aside: Needing help from others on figuring out your problem is a great idea to figure…
Change is great. Change is amazing. But what about when you’re not the instigator of the change or you don’t see it coming? Depending on the scenario and context you might be able to pivot extremely well, in other scenarios you may not – you may be thrown for a loop and sit there looking at your screen wondering why you? Why did this have to affect me? I didn’t ask for this happen? This…
I had an experience with a doctor a few months ago where they squeeze in an appointment at the end of the day to see me. It was a gross day, raining, muggy… one of those days you want to go home, order some pizza and catch up on Suits. But they made room in their schedule. And when the appointment took place, they welcomed us warmly. And they didn’t rush things, where mistakes were…
Said by every developer ever. “It can’t be a bug if I never had the requirements.” “It can’t be a bug if it never existed in the first place.” “It can’t be a bug because no one else is complaining about it” All valid answers. As well as opportunities to invent a new work item type that removes the stress from finding a feature at the last minute and lightens the mental state of the…