In my last post, I’ve somewhat criticized the agile frameworks. In short, agile frameworks bring complexity with minimal effectiveness. They even can hinder engineers effectiveness. So, what’s the alternative? In my opinion, most of the engineers don’t really have any problems with short release life cycle and continuous feedback from the customers. If we can apply agile principles with less ceremony; then, we might be able to be more effective. This brings us to the concept of minimum viable agile.
Definition
I define minimum viable agile as applying agile principles without ceremonies, roles, and convoluted processes. The concept is obviously borrowed from Minimum Viable Product. I really like MVP as it shows how a certain product would look like pretty quickly. In the same respect, the MVA helps us to apply agile principles with minimal effort.
Principles of MVA
- Enough practices to get things right
- Small teams
- Focus on delivering value
One of the important parts of software development is making sure what we have developed works. In order to do so, we should have validation processes in place and preferably automated. That’s why DevOps practices have been widely adopted. And, I think MVA should almost require DevOps practices.
Small teams rock. I define a small team as up to 3 people and one man teams. Small teams are better since they can focus on exactly one problem and attack it. If the product itself is big then you can create more small teams and distribute the responsibilities among the teams. Small team approach doesn’t imply anything about the management of these teams. You can still have multiple teams reporting to the same manager.
The objective of software development is delivering value to end users by reaching production. Engineers can often get sidetracked by various different aspects of software development like languages, frameworks, and other technologies. Nevertheless, nobody cares about how good the tech is. All it matters is to solve a problem and offer a solution to the end user. Until then, every effort is fruitless.
How to apply
With a small team focusing on delivering value, we should always have a goal of producing a piece of software that helps the customer in each iteration. Hence, we should focus on one or more features. We should try to get these features done at the end of our target release date. Note that the release date should depend on the features. If you have a couple of small features then maybe you can release it in a week. On the other hand, if you have a large infrastructure undertaking, then the next release date can be in a month. Release periods don’t need to be fixed. Moreover, they are just targets not a written contract.
We also need to organize what needs to be done. Therefore, we probably need a list of tasks and choose what to accomplish for the release. A physical board or software would be useful here. If there is a chance to meet with the customer regularly, we can organize the board according to their needs. Perhaps, we can even plan a roadmap together. The key is the interaction and feedback loop. Once we can establish it, the rest is just setting up the correct routines.
In consequence, I think we need slimmer approaches when it comes to applying agile practices. I believe MVA is the right fit for the job. Applying MVA isn’t rocket science as it requires some communication between peers and customers; nothing more. It also doesn’t dictate anything. You can always have your own way of applying MVA.