Running better software projects
A practical guide
This article is based on a talk that Jesse O'Brien (senior developer at Vehikl) and I (our design director) have given at a few different events now. The talk (and this complementary article) will provide a frame for planning, working on, and shipping a software project.
Whether you’re at a product company, consultancy, or you’re doing freelance, you may find yourself on projects that require you to work with team members across disciplines or with clients in varying domains.
We’re going to highlight some ways to make working in these differing environments more effective. We are going to go over facilitating effective client meetings, organizing phases of the project, managing sprints, and some methods to improve collaboration on your project.
First, a bit of background…
Over the last three years, Jesse and I have worked with the founders of Vehikl to more than quadruple the size of our software team (from 4 to 26 people). Throughout both of our careers we have shipped hundreds of projects, and have worked on dozens of teams, and at many different companies in various industries.
As a premium development consultancy, Vehikl believes in working as an extension of its clients’ teams in order to deliver high-quality web applications. These are the ways we have been able to deliver the high standard of quality we promise.
How this all works
Find the right clients. The way we work isn’t necessarily suitable for how every client likes to get things done, and we may not be the right fit for every project that comes through our door. An important part of making sure a project runs smoothly is making sure that you and your client are the right fit.
You are an extension of your client’s team. To deliver on the promise of a smoothly-run project, you must build trust with your client. You can only do this by sharing their vision and working toward a common goal; collaborating closely with them, and involving them as much as possible. When your relationship with your client is a partnership, you will experience more effective communication and higher productivity.
Work with the people you have at your disposal. I won’t explain the benefits of pair programming here, let’s agree that pairing aims to provide better insight, accountability, and higher quality code. Do what you can to not silo yourself so that decisions aren’t made in a vacuum to ensure that you’re gaining the benefits of differing perspectives and possibilities for solutions.
Have a safe, sustainable billing process. What we consider safe is up-front billing where clients pre-purchase on a sprint-by-sprint basis. Not only does a pre-paid billing process protect us from the possibility of unpaid invoices, it also protects our clients by ensuring that they are satisfied with our work throughout the project.
What does this look like?
The way we see it, there are four parts to every project, regardless of the project scale or the team structure.
Part 1: Kickoff
The kickoff meeting is effectively a crash course. It introduces your team to the stakeholders, their company history, and the domain you’re going to be working in. The two key goals of the kickoff meeting are to educate and to ask questions.
Education, in this case, goes both ways. Your team needs to learn about the client and their team, their company, and their domain. And your new client needs to know how your team works, your processes, and your routines. This is also where you will be defining what everyone’s expectations are. You will learn what your client expects from you, and you’ll highlight what your team guarantees and expects.
Kickoff is also when you’ll establish routines for planning and demo meetings, avenues for communication and collaboration, and processes for prioritizing tasks will be instrumental in trust between everyone involved.
Tips for a successful Kickoff
- Run it; don’t just attend. As the team who will be doing the work, this is your meeting.
- Make sure everyone is at the meeting. Identify any decision makers, domain experts, etc., and ensure they’re available to answer any questions and direct decision making.
- Have a plan for questions you’ll need to ask before the meeting so you can make the most out of everyone’s time. A checklist, notes, etc., are all good ways to stay on track.
- Remember to say no when necessary.
Part 2: Discovery
The discovery phase will include learning about the domain you’ll be working in, diving into any existing code, exploring options for implementation, and building trust between yourselves and your client.
You must deliver on the expectations defined during Kickoff.
In order to build trust, you must deliver on the processes and agreed expectations you defined during Kickoff. You will do market and user research, wireframes and/or prototypes, and you’ll look for options for technical solutions.
Domain knowledge: a broad-based understanding of a particular industry or solution.
Identify business rules by asking how the business runs; what problems are they solving in their market; who are they serving? Take note of relevant terms or concepts unique to the domain. Define industry acronyms, job titles, and the responsibilities of everyone involved.
Tips for successful Discovery
- Document what you learn by writing down definitions, answers to questions asked, technical requirements your client may have, etc.
- Wireframe your ideas as soon as you begin identifying how implementation may look and feel.
- Get feedback early and often from your client to ensure you’re using this phase of the project most effectively. This is the most important phase of the project for good communication.
Part 3: Sprint Cycle
When you begin your sprint cycle, you will have already planned on the length (1 week, 2 weeks, etc.) and the structure of your sprints.
Each sprint is broken into five parts:
1. Planning the sprint
2. Sprint (designing/coding all the things!)
3. Demo
4. Sprint Retrospective (how did the sprint go?)
5. Ship
Special note: be wary of pivots on priorities during a sprint (either from within the team or from the client) and understand what pivots could do to the project.
Sprint Planning
In order to plan for the work to do during a sprint, you will:
- Identify the highest impact work
- Estimate scale
- Prioritize/delegate tasks
- Update your client with the details
To keep yourselves and the project on track, commit verbally to specific tasks, as well as a specific interval for delivering those finished tasks (one week, two weeks, etc.).
Estimates
The first couple sprints are often the most inaccurate for estimating the time and effort it takes to complete a task or a feature. This is normal. Accurate estimates require specific domain knowledge, insight into business rules, understanding of the tech stack being used on the project, and experience with how you and your team work individually and together to complete tasks.
One way to mitigate the known slower pace in the beginning is to under-commit knowing that you will end up over-delivering once you’ve hit your stride. There is more understanding and therefor a more predictable pace.
Building all the things!
The foundation for building great products is frequent, thorough communication. Talking to your clients/stakeholders, brainstorming solutions, finding answers to questions, getting clarity on business rules, identifying user needs, etc. Communication can make or break a project.
Communication can make or break a project.
More keys for building a successful product:
- Working collaboratively with your team and your client
- Time management
- Effective version control
- Testing (code & usability)
- User-centered design
Using techniques like pair programming, coordinating priorities, and having good communication will contribute to a project’s success. Managing the team’s time with a sprint structure will keep tasks and team members on track and accountable.
Product Design
Driving your project in a user-centric way will go a long way toward guaranteeing you’re solving real problems. At the end of the day, always consider the people who will use what you’re building. How are you solving their problems?
Perfect is the enemy of Good.
Always keep in the back of your mind that chasing perfect will only lead to less shipping. While you’re planning, designing, and building; always strive to solve the user’s problem first, then worry about prioritizing perfecting how you did it. Solve the problem, then refactor.
As you see on the whiteboard above, there are a number of ways to approach the same concept. Look for a number of fast, easy ways to solve the same problem, and execute on the one that gets the best feedback. Talk to your team, your client, and (if you can) the users to validate the best way to tackle a problem.
Demo
Now that you’ve built so many great things, it’s time to demo! It’s important before you prepare your sprint demo that you review what you agreed to do during your sprint planning meeting to address what you got done and what you didn’t. Make sure you address both the wins and the challenges during demo. This will help frame the retrospective when your team reflects on how the sprint went as well as plan for the following sprint. The most important part of the demo is identifying how you’ve solved the current problem you’ve agreed to tackle for the current sprint and ensuring you gather feedback on what you’ve delivered.
Retrospective
A retrospective is a scheduled time at the end of each sprint where your team reflects on how the sprint went. What did you deliver, what did you push to the next sprint, were there priority pivots (shifting priority with new things on the roadmap), feature creep (adding new features into the sprint), or scope creep (increasing the size of a feature). This is also an opportunity to evaluate how your communication was, how delivery of agreed priorities went, how your team collaborated, and the results of any experiments.
Speaking of which…
Experiments
Experiments can be anything from trying a new package or library you haven’t tried before, a new design pattern, proper testing (but we all know you’re already doing that, right?), refactoring some code, or (gasp!) a whole new piece of software. Use experiments to test theories, trial something new, learn, or simply to challenge yourself.
Most projects will provide opportunities for running experiments. What’s important is knowing how to run them and when is the right time to do them. You’ll want to work with your team to limit the amount of time you spend on experiments so that you don’t end up down the all-too-easy rabbit hole, while also leaving yourself enough time and leeway to abort out of an experiment.
Once the experiment is complete, you’ll use your retrospective to talk about how it went. Did what you were trying to do work? Why or why not? Did you appropriately stick to your time limit? You get the idea.
Part 4: Ship
Shipping can mean the entire product, or simply features getting finished within a sprint. While preparing to ship, you’ll want to prepare for how you’ll be monitoring for errors, feedback, and bug tracking (Sentry, Bugsnag, Zendesk, etc.).
At certain points in your project, shipping will be when you’ll begin to see real users, and so usability testing, performance, etc. may also start phasing in to your project.
Regardless of what you’re shipping, you’ll want to test and gather the feedback so that you can plan for future iterations of your work.
Tips when shipping
- Track bugs
- Capture feedback
- Plan iterations based on feedback
Success!
We’ve covered a lot, including planning, structure, communication, and collaboration. You should now have more confidence on your projects to:
- Work collaboratively
- Pair program
- Manage meetings
- Design & build products
- Manage sprints
Remember, folks, this is what works for us at Vehikl. Take from here what you find useful, and if you feel inspired, work with what makes sense for you, your team, and your clients! The idea is to strive to make yourselves better, so that your projects and your relationships with your clients continue to grow and improve.
