I was recently given an Agile story that required me to set up the capability for database integration testing. I didn’t have much experience in setting up database connections and was feeling like I was in over my head. I was also still getting used to the extra effort it takes to communicate when you’re working from home. Because of this, it was too easy to struggle silently — and I did.
Now that I’m well into the story, I’m eager to not repeat the same mistakes when handling any other tasks. Here’s what I wish I’d done early on.
1. Acknowledge the need for more information.
It took me several days of looking into the story before I finally admitted that I needed clarification and help to move forward. In an Agile process, this should have taken place the moment I got the story. I should have clarified the requirements to better understand the problem and the acceptance criteria for a done story.
2. Break the problem into smaller, “bite-sized” pieces.
At this point, I remembered two great pieces of advice I’ve received as a programmer:
- Break problems into smaller pieces.
- Ask specific questions.
Once I had specific questions that others could help with, it was much easier to move on. Instead of remaining stuck in an “I’m not sure what to do” cycle, I was able to give details and receive the answers I needed.
3. Ask questions; seek help.
It’s much easier to seek out a teammate for questions in person. Even though we’re connected and communicate every day while working remotely, there are still a lot of mental pressures and uncertainties. I hesitated about bothering a teammate too much when I couldn’t tell if they were in the zone. The computer can only let you know whether they’re online, not whether it’s a good time to reach out.
But even with all of this, my teammates did a terrific job of reminding me of Atomic’s “ask culture.” It doesn’t hurt to put a question out there and let others decide when to answer. Even though it sounds simple, this trust takes out the guessing and allows individuals to create healthy boundaries when necessary. If my teammates wanted to do some heads-down work without interruptions, they simply declared “focus hours.”
I’ve always loved pair programming; almost every session of paired programming proves its power. This time was no exception. A one-hour session with another teammate filled my knowledge gaps and got me unstuck.
Want more? Richard Reis wrote a great article on how to problem-solve like a programmer. It gives excellent strategies that would be valuable for more than just development problems.