As a product leader, you don’t need to program the solution. But you need to understand a little bit about technical practices to be able to do your job well. I will cover the most important practices and concepts here.
- Continuous delivery
- Infrastructure as code
- Automated testing
- Pair programming
- Collective code ownership
- Simple design
- Technical debt
Continuous delivery
This goes under many names for slightly different variations (for example Continuous Integration, Continuous Deployment, DevOps). The main idea is that we want to have feedback loops from real usage as short as possible as well as time-to-market.
You need to work closely together with you development team so you can correctly prioritize improvements in this area. In order to have a fully automated way to test and deploy code to production heavy investments (at least in time) might be needed. The return of those investments are usually very good though, but it of course depends on the situation. In an ideal world a change would go to production after a developer has checked the change in. This state might be too expensive too reach, but you need to have a good understanding of where you are and where you should be going in this area. Your more technical team members should be able to guide you in this.
This topic is closely related to infrastructure as code and automated testing. Without infrastructure as code and a mature level of automated testing it might be hard to come far with continuous delivery.
Infrastructure as code
This means that the production environment (and probably other environments as well) is programmatically set up. This means that every server (of a certain class, you usually have different classes) is set-up in exactly the same way. This is extremely helpful both when troubleshooting, when solving issues, when releasing and when quickly scaling the system. If your infrastructure is in the cloud this is taken care of automatically, but if you run on physical servers you might need to invest in practices to improve this handling.
Automated testing
It is impossible to be agile without an extreme focus on automated testing. Without automated tests you will have to run the same manual tests over and over and over on small releases and that is just not sustainable.
No automated test = No agility
Pair programming
Pair programming is a way to help the team spread knowledge and better utilize each others knowledge in the very complex undertaking that software development is. Some people enjoy pair programming and some hate it. I usually encourage it – and definitely trying it out, because some people are surprised by liking it – but I don’t try to push to hard. If people don’t like it, it is probably not a good idea to do it. Although for people who like it, my experience is that is helpful and brings value. At least for code that is not trivial and for ramping up newcomers to the team.
Collective code ownership
In an agile team the team owns the code together. This means that anyone is allowed to change code anywhere. It is really hard to be agile without following this principle.
Simple design
In an agile team we start with a simple design that will solve the most immediate needs rather than anything that we can think about for the future. At the same time the solution can’t be too shortsighted so that we have to completely rework the whole solution a short time from now. This is a challenging practice to find the right balance for.
Technical debt
Technical debt means that the quick and dirty solutions that we use will incur a debt and that we will have to pay that back with interest later on. Technical debt is solutions that we know are not the best way to solve a problem. They might make code hard to read and change and cause bugs now or later and since we will have forgotten the details later on – and have added more code that is dependent on the poor code it will take longer to fix later on.
It is rarely a good practice to willfully incur technical debt, but under some circumstances it might be worth the penalty. For example to get something working for that major trade show, or to release that urgent feature to the customer who might be leaving for the competition soon otherwise.
Frequently we make the mistake of taking the shortcut that ends up taking longer than the proper solution since it causes problem already during implementation. Be careful with this and have a healthy dialogue with your team if this discussion arises.
Some people say “The only way to go fast is to go well” and most of the time this is true in my experience.