After being members of dozens of development teams, designing hundreds of UIViewControllers, and participating in enough scrums to be a rugby team, there’s a few things we’ve learned along the way about efficiency. We’ve learned what’s practical, we’ve learned how to be lean. We work with startups and large organizations everyday, and we’ve built some really awesome apps.
When I advise my friends on how to run their teams, this is the advice I give them.
Clear, Frequent Communication
…With everyone involved.
I like to think we’re really good at this, because it’s the most important part of keeping the machine running. Think of a car without a dashboard… that’s useful. Days can be filled with back-to-back-to-back meetings and you’re scribbling down notes, talking about different exciting ideas with many passionate people… and your iPhone notification just pinged. There’s no way you remember action item three from your second meeting today.
We have a couple processes — they’re simple. Bring a physical notebook to every meeting. Take notes and stop whenever you don’t understand something. Recap at the end of the meeting. Then review your notes on your own, fill in the gaps, identify any holes, and email or post a debrief to everyone involved.
Talk to your developers frequently, don’t just rely on watching the feature checklist get checked off. At least once a week we’ll review the sprint plan point-by-point. It’s so common for someone to pipe up and say, “hmmm, I did have a quick question about that…”. And you know what, I love when that happens. It lets us all fill in the potholes, until we’re sailing smoothly.
Once a week all-hands meeting with the whole project team, and at least two more daily scrum meetings. Monday-Wednesday-Friday has worked very well, and put the all-hands on Monday or Wednesday, never Friday. Basecamp will send daily activity reports.
Create Feedback Loops
…And do it quickly.
Get feedback from the people working on your project. Ask the developers what they think of your requirements. Ask the designers what they think of your interface and user experience. These people see these functions day in and day out. If you’ve ever been in the lunch room of any company, or stood by the water cooler of any office, the typical conversations are people complaining about their work. “The way we’re doing it doesn’t make sense” or “this is the worst idea”. It’s true, overly complex systems are painful to implement and support. If you’re a startup you shouldn’t be implementing an overly complex system. MVP, right?
Ask your developers, “what do you think about our data model?”. If you get “um, it works”, then ask, “oh, how would you do it?”. Every developer is dreaming up their perfect side project. On their pet project, the first thing they think about is not the marketing plan. We’re tech nerds, of course we’ve thought through the data model and architecture during our daydream. I’ve done it. My colleagues have done it.
And good architectural practices are quite repetitive. Even from their college studies, your developers have seen many use cases similar to yours. Listen to them. If you don’t have the budget to bring in a 10-year experienced J2EE-certified architect, your developers are the best thing you got. And none of the phrases “10-years”, “experienced-J2EE”, or “certified architect” rhyme with “lean” anyway.
Don’t worry, we’ll go to lengths to point out suggestions, or tell you when we think you’re making the wrong decision. Because we hate implementing weak designs too. It looks bad on our work, and we’ll likely have to put in extra effort to remedy a poor decision. If we see something that can be optimized, or UX that can be more intuitive, we won’t hesitate to point it out. We still know it’s your baby, and at the end of the day you’re the momma-bear, we’re just nannying.
We’ve built plenty of apps, and as power users we’ve played with thousands more. Just as a soccer player watches, and understands, a soccer match in a totally different way than the average person, we analyze the hell out of our technology. The soccer player sees a play unfold, appreciates skilled maneuvers, and laughs at the bloopers. We reverse-engineer every top 10 app.
Basecamp allows private posts. Encourage your developers to post internal discussions whenever they have an idea. That way they can feel safe sharing their thoughts.
Then Get Out of the Way
Let them build. Once you’ve made the requirements and specifications crystal clear, and they understand them, then all you have to do is get out of the way. You’ve told them how you want it to function and how you want it to feel. You’ve asked for their thoughts, and they’ve given their opinions.
Again, weekly all-hands and a couple more scrums are great. If you’re not in direct contact other days, just have them post a status update. To be agile, you still have to give them room to work. Coders get in the zone too, and they do it best without distractions. Programming is such a logical task, don’t disrupt that mindset.
You’ve reviewed wireframes, development plans, and mockups. Wait for your next build, be amazed, and enjoy. Learn. Build. Measure. Repeat.