What’s your dream project?
An interesting question that I get asked at times by others is what things do you prefer to have on a project to be successful? Everyone have their own preferences and experiences, these are the things I have found important to be successful in delivering value to the business and software of high quality.
The team needs to trust each other to be honest and dependable. If the team doesn’t trust each other, it’s going to be a long and frustrating project with low chance of success. We also need to trust the product owner and the product owner needs to trust the team. Trust doesn’t happen overnight, we need to continuously work on gaining trust.
We need to be able to switch gears and change functionality if the business needs are changing. When was the last time your team quickly changed focus and the functionality in a waterfall project? Exactly. It doesn’t matter what agile methodology you use as much as that the team continuously introspect and retrospect what you and the team is doing well and where we can improve and take steps to improve. Agile is not a prescription, as the team matures we need to work on using the practices that works for us.
Test Driven Development (TDD) is important if you want to have a good chance of delivering software with low defects and good quality. TDD by itself doesn’t lead to good design unless you are an experienced software craftsman but it helps us at the very least not to implement a poor design that isn’t easily testable. TDD isn’t about the tests, it’s about the thinking process, refining the design and being able to refactor without being afraid of breaking the system.
Pair-programming is a practice that I have found to be useful in so many ways. If you have a difficult time to convince management to use pair-programming, the single most important reason should be to reduce the bus factor. If you only have one developer that understands the most complex pieces of your system and he/she leaves, you will be suffering for a long time. If you’re lucky and they give you two weeks notice, it’s still not enough to understand a part of the application that they may have worked for months or even longer. I think other good reasons is to get constant feedback by your pair and you spread knowledge regarding the business domain, software engineering practices and other important topics that helps the team to improve.
It’s crucial to have a tester on the team. If QA is a function outside of the team, it’s a silo that will slow down how fast we can get feedback whether the functionality works as expected.
I think 3 Amigo’s is essential to make sure everyone’s expectation of the acceptance criteria of a user story are in synch. In a 3 Amigo’s you should have at least one developer, one product owner (or BA proxy) and one tester. The conversation regarding the user story and what you expect can be as short as five minutes. This helps making sure that everyone understands what is required before the user story should be considered complete.
CI / deployment contracts
I think it’s essential that you have Continous Integration (CI) to ensure that all the tests passes every time someone checks in code to your source control repository. I think it’s also important to have a deployment contract which is just in agreement of what steps needs to have passed before we can deploy a release to an environment. Measuring quality metrics with tools like SonarQube is helpful in making sure you don’t deploy code that have critical issues or security problems.
There are other important aspects in delivering high quality software. If you have all of these aspects in your project, you’re very likely to be successful. Yes, this is not a pipe dream, I was fortunate enough to have all principles in a project and some others I have excluded. The only escaped software defects that made it to production was environment related issues.
What’s your dream project?