Agile Discovery & Delivery: Survival Tips

Today, I’d like to share a couple of excerpts from my upcoming book, Agile Discovery & Delivery: A Survival Guide for New Engineers & Entrepreneurs. Each chapter of the book has three parts: Key Concepts, Reality, and Survival Tips. The survival tips are bite-sized suggestions that new engineers can easily use to make their lives and products better or easier. They cover specific practices related to the content as well as some tips that likely fall more in the “life lessons” category. Below are a few of the tips from the product-market fit and scrum chapters.

Discovery Survival Tips

This is a subset of the survival tips I include in Chapter 3: Finding Product-Market Fit.

1. Listen to Customers – If your company doesn’t have robust discovery practices, you can take the first step. Talk to your customers. Ask to join your UX and Product team members at customer interviews. You don’t have to say anything. In fact, if the interview is online, you can sit in the room without them even knowing you’re there. Or, you can ask a few questions yourself.
2. Understand Problems, Not Feature Requests – Customers will come to you with feature requests and they may even tell you exactly how they’d like them to work. Dig deeper. Try to understand the problems they’re trying to solve with their feature request. There may be a far easier way to solve that problem with another solution.
3. Ask Open-Ended Questions – “What problems are you having with our notification reporting capabilities?” This is a better question than, “Do you wish the notification reports page listed other devices?” You will get a much better sense for what your customers want if you don’t ask leading questions. If the question can be answered with ‘yes’ or ‘no’, don’t expect to get a lot of great information. Another thing teams often do is ask customers if they want a particular feature. That’s useless! Customers will always say they want new features. But they may not be willing to actually pay for those features.
4. Put Designs or Prototypes In Front of Customers – Show customers a prototype or mock-up and ask them to tell you what they’re thinking as they try to interact with it. Sit there silently and listen. You’ll hear where they find things confusing. You’ll see when they pick-up what they’re supposed to do right away. You’ll watch them struggle to interact with a confusing page. This technique, by far, will elicit far better feedback than simply asking questions.

Scrum Survival Tips

There are so many good tips in the Scrum chapter. This is a small taste. It’s a good mix between scrum-related ideas and life-enhancing ideas.

1. Events (Meetings) – If scrum seems a little meeting-heavy, you can combine some of them. My teams treat the last day of one sprint as the first day of the next sprint. They’ll hold a team review (demo) followed by a retrospective. Then, take a short break and roll right into sprint planning. You can also combine backlog refinement and sprint planning. As long as it doesn’t take your team an excessive amount of time to plan. If any of these meetings end up going longer than 1-2 hours, you may want to decouple them again for your own sanity.
2. Stand-ups – Holding these every-other-day or over slack can work. It’s worth experimenting once your team is high-performing.
3. Automation – If you’re doing the same thing more than twice, take the time to automate it. Your future self will thank you.
4. Meeting-Free Days – I’m a fan of them. Your managers and leadership team may not be because they want to talk to you, but they also want you to get your work done. They can’t have it both ways. So if you can get your whole team to agree to an entire day per week where you can focus on code. Do it!
5. Nights & Weekends – Create boundaries with your time. Find companies to work for that don’t have a 24/7 culture. If you hear people bragging about how many hours they worked last night, run. Burnout is real. What many of us Americans don’t realize is that your productivity actually goes up when you have time to rest. In my early career, I didn’t get the performance rating that I wanted one year at IBM. Even though I worked insane hours on our projects. So I got angry and decided to stop working more than 40 hours a week. What happened to me next was amazing. The next year, I did get the top performance rating. Not only that, but I was well-rested and had learned the important art of prioritization. I’ve rarely worked overtime since. Yet I’ve enjoyed a fulfilling career filled with promotions and raises.
6. Scrumban – Many teams combine Scrum and Kanban (the subject of our next chapter). This combo-framework can be pretty effective and lighter-weight than Scrum. Check out the Scrumban section in Chapter 6 to learn more.
   

Feedback Welcome!

Again, we’re still editing, so feedback is helpful and appreciated. If you have a suggestion for another survival tip, reach out to me via my contact page here.