When I used to build Contact Centre Software, I marveled at the impressiveness of the MUTE button – it worked 100% of the time without fail – and thank you so so much. Now it’s a joke when it comes to video conferencing – “you’re on mute”, “you’re still on mute”. We took this great, rock-solid implementation and we made it into a meme and a joke. But for years it was the most rock-solid…
I’ve done 1 week to 6 week sprints (yes at 6 weeks we called it a sprint) – if you’re not sure what fits best for you, here’s some guidance. 1 Week – It’s all bugs, it’s all known quantities, you have minimal code and your deployment model is code, commit, deploy. QA happens when you ship to Production, teams of 1 – 2 developers. The Theme is “MVP”. 2 Weeks – User Stories are…
Can we put everything into this fix to get it right and get it out there? Have you tried putting everything into one fix? I remember when 100 MB was considered too big for a patch and now I’m downloading 20 GB updates. Focus your fixes on the problems they are meant to solve – no one ever complained about a fix that addressed the one issue it was meant to.
Do you ship by date? By state of quality? By bugs left on the table? By customer adoption rates? By pre-order? Do you grind late into the night on the last few weeks to get it all done? Do you lay out your sprints so you have time to work on the unknown as it arises? Do you pushback on new requirements? Everything has to be cut in stone? Often times our delivery profile is…
If you can’t code 8 hours a day. Can you jump in, on small tasks, and hammer out 1 hour a day? If you can’t do 5 hours a week can you find time to do 3? Bit by bit is the origin story of many overnight successes.