Huzzah! You got the project! Now what!? Here are some recommendations on what decisions you should make right now, before you start.
1. What’s the tech?
Let’s start with the obvious one. Assuming you’ve decided to write some software, you’ll have to decide how to write it. Which programming language? Is your team going to use the same IDE? Which code repository? And, the even better question: how rigid do we need to be about enforcing these choices?
This is where your maker team is going to live for the next 12 weeks / nine months / five years, so don’t just wing it.
2. What are the goals?
Someone on your team just spent a lot of time negotiating to get this project, so you’d think this would be obvious. But the client’s goals don’t necessarily map one-to-one with your team’s goals. They asked for a product to do X, but “Allow the client to do X!” is a terrible team goal.
Instead, decide what your team is specifically going to do to achieve the client’s goals. Are you going to focus on quality? Speed? Accuracy? Deciding early what’s going to drive your team’s work on this project will make later conversations much easier.
3. Who makes the call?
At some point, there’s going to be conflict. The client’s marketing department wants Feature X, but the designers want Feature Y. Meanwhile, Feature Z is taking twice as long to deliver than anyone could have imagined. Someone has to decide priority.
In Scrum teams, the Product Owner takes on the role of decision-maker. For some teams, this role is filled by someone at the client. Ultimately, it doesn’t matter who the person is, as long as there is a person. What matters is that the team acknowledges that it’s their call. Without this definition, teams can spiral (AKA argue incessantly) about priorities, which ends up putting everything even further behind schedule. The shot caller can solicit as much input as they want, but – when it’s time to make the decision – it’s gotta be their decision.
4. What’s the quality plan?
Every team, no matter how bleeding edge, needs to decide how they’re going to ensure they’re delivering a quality product. Is it through continuous iteration? Unit test coverage? Mob programming? Paper prototyping? Frequent user testing?
There are as many options as there are makers, but there has to be some way to discover (and prevent!) defects, solicit feedback, and validate that the right work is being done.
5. How do we change?
No team ends up exactly as they started, and yours won’t be any different. Every decision you’ve made at the start of this project will be challenged. And that’s good! Understanding that change is inevitable, you should decide how you’re going to assess yourself as you go.
Come up with a safe way for the team to make suggestions along the way, and then figure out a way to try new things. The most important thing is to make sure the process of change isn’t, “Change everything at once and hope it gets better!”
Ready, go!
Planning how to work is frequently (always?) harder than the work itself. Take a moment before the project starts to really think about the process of building your product. Doing so can clear some of the clutter early and let your team focus on delivering the best product possible.
Image: “Starting Blocks at Vacant Starting Line Before Event” by tableatny (CC BY 2.0)
