ImagineImagine you work on an imaginary software development team with imaginary problems...
Imagine you’re working on a software development team. Imagine you’re a software developer. Or maybe a Scrum master. Or a tester. Or a product manager. Or any other role you might imagine belongs on your imaginary software development team.
I know this scenario is hard to imagine, but bear with me for a moment, and try.
Now imagine that things on this imaginary team are a bit slow. Pick any imaginary slowdown that might be going on. Use your imagination. It doesn’t have to be based on reality. It’s imaginary, remember?
But in case you need some help, here are some options. You don’t need to pick one of these. They’re just to get your imagination going:
- Testing takes a long time
- Deploying the software takes a long time
- Getting customer feedback takes a long time
- You spend a lot of time waiting on external dependencies
- The weekend is just too long, and you can’t wait for Monday to get here
That last one might be a stretch. But it is imaginary. So use that one if you want.
Now that you have imagined your imaginary slowdown on your imaginary team, I want you to imagine how you might go about looking for a solution to this imaginary problem.
I’m not asking what is actually causing the problem. Imagine you don’t know that. I’m asking how you would go about finding the cause and/or potential solutions. Where would you look first?
Let me know.
(To be continued…)
Why do devs want more devs?
Almost always, more team mates means slower output, not faster. So what's the proper solution?
Improve your software delivery