How to Ship Software Products: Part 2

Photo by Markus Spiske

This is the second part in my series on how to ship software. To read the first part and learn how we decide what to build and how to design it, check it out here.

In the first part of this series on How to Ship Software Products, we covered how to choose what to build using a host of different techniques including Jobs To Be Done (JTBD), Outcome Driven Innovation (ODI) and ensuring that you build software that can Win the Moment and Be There, Be Quick and Be Useful for users. We also touched on our design process for new features and products once we have figured out what we want to build.

Today, we are going to discuss what is often viewed as the most difficult part of the software development process,; actually building and shipping new software products. There is a lot of noise around this subject and a lot of different techniques and approaches that come in and out of fashion and promise to revolutionise how software is developed and shipped. People who are new to the software development industry are often bamboozled with a litany of terms, depending on what is in fashion at any time.

Unfortunately for all of us, there is no single methodology or programme that you can follow that will make shipping software easy. By definition, the process of building anything, especially something that usually relies on complex data structures and algorithms, is inherently difficult. If it was easy, everyone could build and ship great software and we all know that just doesn’t happen.

The good news is that if you go in with your eyes open to the challenges and are willing to adapt and put some key rules in place, building and shipping software is not only extremely accessible for anyone from any background but also incredibly rewarding. The purpose of this post is not to compare and contrast different development methodologies and to pit Agile against Waterfall or even Kanban versus Scrum. Every development methodology has strengths and weaknesses and smart teams beg, steal and borrow a bit from each of them and are continuously iterating their process to make marginal gains.

Instead, the purpose of this post is to talk about some of the fundamentals that the team at Pulsate have learned over the years. Without these fundamentals, it doesn’t really matter what methodology you use as you will be sunk from the start.

Communication, Communication, Communication

It is hard to overstate how important clear and concise communication is in any team environment and this is especially true in software development teams that often contain people from different disciplines including developers, product designers, visual designers, QA testers and product owners/ managers. From my experience, the number one cause of tension in a software delivery team is bad communication. And the thing is, although everybody thinks they are a great communicator, most of us are not.

You can have the greatest idea ever for a new product but if you cannot effectively communicate that idea to your team, you won’t get very far. Likewise, there is no point being the most knowledgeable developer around if you cannot communicate effectively with non coders. Great communication has to be worked on and the first part of that is ensuring that everyone on the team understands what the team is trying to achieve and understands their role in the team and what is expected of them. Before any development work is started in Pulsate, we transfer the idea for the new feature or product that we are going to be working on from the minds of the product design team onto paper and circulate it to everyone in the team.

This acts as the blueprint of what we are trying to build. Every part of the new feature or product is catalogued and numbered and if something is not on that spec doc, it is not getting built. The document also briefly outlines the business case that underpins why we are going to work on this update. Everyone on the team contributes to the document and signs off on it before any development work is started. Throughout the building process, this is the single most important document and it is constantly referred back to.

An example of one of our recent spec docs.

Bring Everybody on the Team Together

Communication throughout the building process is equally important as outlining the vision for the product. Like most development teams, we hold daily standup meetings that include everyone on the development and design team and the product owner. These meetings serve two purposes; they ensure that everyone is aware of what everyone else is working on and the progress that they are making and they also allow anyone on the team to let the rest of the team know about any issues that might have arisen so that we can provide help and tackle those issues as quickly as possible.

This allows us all to keep on top of the project and to offer help to anyone who has run into a problem. We also ensure that our designers and developers are in constant contact and we all have a call at the start of every project to go through every part of the design and ensure that everyone understands why we have designed the product the way we have and how it will be implemented in development.

Create a Custom Workflow

Every team and every project is different so it is really important that you use a workflow that works for your specific team. Of course, you should take inspiration from how other people work and you should also be willing to adapt and improve what you are currently doing. We have used lots of popular project tracking tools like Pivotal Tracker, Jira, A-ha and Sprint.ly and they all have pros and cons. However, we have ended up using Trello as our main tool for creating tickets and tracking progress. One of the main reasons that we like Trello is that it is infinitely customisable and has allowed us to design a custom workflow that works for us. And, even better, Trello makes it extremely easy to tweak that workflow.

Our custom workflow

When we made the switch to Trello we gathered together everyone in the product team and we brainstormed ideas about what our workflow should look like. This has changed a lot since it was first defined but getting everyone together to figure it out resulted in us all buying into it and taking ownership of the process.

Don’t Manage by Slack

Like most product teams, we use Slack for day to day communication. However, we found out the hard way that while there are many advantages to using a great tool like Slack, it can take over and quickly turn into a hindrance. Slack is so nice and easy to use that it is easy to develop bad habits and fall into the trap of project management by Slack. This usually involves discussing project changes and updates in one on one channels and being lazy and chatting about tasks that need to be done on Slack instead of adding and commenting on tickets.

This is bad as it results in fragmented product conversations and ends up with everyone on the team being on a different page. For that reason, we have banned discussion of any product work in individual channels and insist that all communication about a product either happens outside of Slack or at the very least in channels where everyone on the product team is able to take part.

Trust the Team

One of the facts you quickly learn when you try to build anything in a team based environment is that much like Jon Snow, you know nothing. Well maybe not nothing, but everyone is so specialised these days that it is impossible to know everything. Product designers know how to design something that is easy and fun to use but don’t know how to build it. Developers know how to build something fast and scalable but don’t (and shouldn’t) have to worry about the design of that product. And Product Managers, CTOs and Product Owners, well we know a little bit about everything and are in constant awe of the specialists as we watch the product or feature take shape.

Everyone on the team has to trust that the other people in the team know what they are doing. Sure, feedback is always welcome and often times developers have great design ideas and good designers have been working with developers for a long enough to understand what is and is not feasible. However, the fact remains that each member of the team was hired to do a specific task and they should be given the autonomy that they need to make the decisions that are required to get the job done.

Everyone is a Tester

I don’t care if you are a developer, a designer, an intern or even the CEO, if you are on a product team, you are a tester. And it is your responsibility to make sure the product that is shipped is as well tested and bug free as possible. Of course, QA testing is a valuable skill in itself and if your team is lucky enough to have a great QA tester, they should be cherished. However, the QA is not the only person on the team and therefore they are not the only person responsible for producing a great product that works as well as possible and does not break anything else.

That is everyone’s responsibility and I don’t mean for just the area that each person built or designed. The product or feature update is going to be shipped as a whole so it is everyone’s responsibility to make sure the entire product is as bug free as possible. To repeat, if you are on a product team, you are a tester. No excuses.

That’s it for this post, I hope it was informative and that other product teams can learn from what we do at Pulsate. It would be great if this series of posts on How to Ship Software sparked a conversation so please add a comment if you have any thoughts of your own on this subject.

If you are interested in finding more about Pulsate, our website at www.pulsatehq.com has all the info you need.