You want to reduce your lost sprints when it comes to building a release. Lost sprints happen – customer bugs come in and they derail everything you’re doing. Or a seemingly well-estimated bug blows up in your face and ends up becoming a feature that still needs to be done this sprint, but everything else will be pushed out. The sprint becomes lost when more and more of your team starts to work on these…
Problems are the bread and butter of your success. How many can you solve? How fast can you solve them? How do they scale? How much effort do they take? What is needed to fix them? When hiring, you always want problem solvers because no matter what they know, have on them or know through their network – they’ll be the ones to figure it out and that’s what you need.
I saw this picture the other day and it speaks volumes, not only for sports but for work as well. Your basics are what set you apart from everyone else. Knowing what they are is what makes you indispensable because then you can start focusing in on them, refining them, and making them stronger. But if you don’t know what your basics are, what your fundamentals are – then you’re just practicing everything, everywhere and…
Imagine your team builds houses akin to how they write code. Some questions to ask; How long would it stand the test of time? What issues would appear immediately? What would work well? Would it align with what your users wanted? Would it ship completed? Would it be finished early or late? You can come up with more/less questions, the point of the exercise isn’t to take your team down a notch – the goal…
There is a narrow space between an end user and the person building the requirements where sheer Nirvana for what is being created exists. Where what the user needs is properly laid out and what the requirement writer is able to fashion into a meaningful delivery that looks to all of their additional/base requirements they have. It’s like the pot at the end of the rainbow. Or if you met Snuffleupagus. Or when two incongruent…