Join the DZone community and get the full member experience.
\nI’ve just been appointed the CTO of a small company with less than 10 \u2026<\/b>
\nJoin the DZone community and get the full member experience. I’ve just been appointed the CTO of a small company with less than 10 employees. Companies of this size typically don’t have the luxury of hiring a professional Project Manager, hence the role almost automatically goes to the CEO of the company, since he is the product owner – Which creates a problem for me, summarised in the ingress of this article. But as the CTO, I’m also responsible for all IT choices, including infrastructure choices, so let me go through all of my choices below – Since these have consequences for the process we must follow. Cloud systems such as Azure or AWS are amazing products, with a feature list covering everything you can imagine. However, they’re also ridiculously expensive, typically at least 10x as expensive as a simple VPS providing the same value from an application deployment point of view. At my last company we paid \u20ac5,000 per month for Azure, and probably something similar for our AWS account (Sigh, yes, we used both! Not my decision though!) – Let’s say \u20ac8,000 per month to make sure we’re within the boundaries and that I am not exaggerating. I told my developers back at that company that I could have ran the whole company on a handful of VPS servers from DigitalOcean paying no more than \u20ac200 per month in total. Nobody believed me until our CTO confirmed my numbers more or less by saying; „At my former company we ran a 300,000 EUROs daily profit FinTech company for some 200 EUROs worth of droplets from DigitalOcean.“ Notice, I am not affiliated with DigitalOcean in anyways, and there are thousands of similar VPS companies, delivering servers with a starting price of \u20ac5 per month. Which one you chose is probably irrelevant, the point is that a VPS is orders of magnitudes less expensive than „the same value proposition“ you get from Azure and AWS. In addition, you can always upgrade from a VPS to a WebApp in for instance Azure, but if you’ve swallowed the Dynamo\/CosmosDB\/Lambda-Functions\/Azure-Functions\/Logical-Apps\/Event-Hub Kool Aid, you can never to the opposite. In a small company just starting out creating its own IT infrastructure, making sure you have as much room to manoeuvre in the future is key! Hence, no clouds, only simple VPS droplets, combined with Magic of course – Resulting in that there is literally nothing from Azure or AWS we’d miss.5,000 EUROs saved per month, check! Anyways, this article is about Scrum, so let me take yet some more detours before I circle back to the actual topic, since I need to create a holistic IT and project infrastructure, agreed upon by all parties, serving our needs from every possible angle. Remember, this is a company whom in these days are literally creating their very first server, to use as infrastructure IT for their company, and hence arguably their very first „enterprise application.“ – Hence, being pragmatic is a prerequisite for success – Implying we’re all a little bit of everything, and everything is a little bit of everything…;) Since we can’t afford, or rather don’t want to use clouds, we don’t have boards or other project management tools from Azure or AWS, in addition to that we’ll need GIT repositories to store and version our code – Hence, we’ll need an alternative. Installing Jira or something similar is also overkill at this stage, and setting up our own private Git server is also overkill – Hence we’ll have to do things as simple as we possibly can – Which implies using GitHub’s „Private repositories“ to store and version our code, and its „Issues“ feature to track features and bug requests. GitHub allows us to setup as many private repositories as we wish for free, and each repository gets its own project administration database, to track features and bugs. Below is how tracking issues at GitHub typically looks like. This is not perfect for an Agile process admittedly, but it’s „good enough“. The type of request and what priority the request has, can easily be accomplished by adding „Labels“ to the request, delivering most of the things required to track progress over time, giving the project manager (CEO) visibility in regards to what’s happening, and which things he should test once a deployment is done. FYI, obviously the CEO is also doing Quality Assurance here, in addition to that I am also doing my best to do QA before and after we deploy. Remember, we’re in a company with less than 10 employees, implying also the CEO needs to wear multiple hats. The „Milestones“ feature also allows us to push things not related to the MVP to future versions. CI implies Continuous Integration and CD implies Continuous Deployment. I’ll probably be slaughtered in the comments here for saying this out loud, but the project is simply too small in size (currently), and the deadline too soon to consider implementing this at the moment. However, since Magic allows me to easily install new backend modules by simply uploading a ZIP file to the backend, and the frontend I’m creating contains scaffolded docker-compose images, the manual work required to create a new release is no more than a simple scp job and an „upload zip file“. Hence currently at least, having me spend time on automating this seems to be a waste of my time. I might reconsider this, and create some sort of Bash script I can execute with the integrated Magic Terminal later, that automatically pulls the code, rebuilds, tests, and docks the Docker images later – But at least for now, spending a couple of days trying to automate something I am doing manually 3 times per week, requiring no more than 5 minutes every time I do it, seems wasteful at the moment. The project’s deadline is 1st of December for the record. Had it been twice as large, I’d probably reconsider this. Notice, I don’t even have multiple environments in this project. DEV is my local machine and PROD is our single server. As long as we don’t have more than 1-3 developers, I don’t see any reasons why we should either. Using something just „because it’s a part of the common dogma“ is the recipe for disaster. Below is a screenshot of how I deploy new backend modules. Finally, we can get to the point now, after having basically committed „Agile suicide“, explaining why I wouldn’t want to use more than 10% of the actual process. So let’s take one additional detour before we get to the point…;) To understand the above question, imagine the following triangle. The above triangle describes the „force of nature“ when it comes to projects. Ignoring issues described in „The Mythical Man Month“, you can control two of the above sides in the triangle. For instance, you can add more resources to the project, and extend the deadline of the project, and as an automatic result of this expect more features to be delivered. This is true since the length of the 3rd line is always defined as a function of the first 2 lines – Regardless of which lines you choose to take control over. The idea is that you can never change the angles of the triangle, only the length of all sides simultaneously. Since two of the lines are already strictly defined, implying for this project the deadline (1st of December) and the resources ( me!) – The third triangle is naturally given as a consequence of the two other lines. Implying features, or the amount of features to be specific, are controlled by „the natural laws of our universe.“ What the above triangle basically says, is that you can only control two of these axioms. The third is automatically calculated as a function of the two others. This is a „force of nature“ and impossible to tamper with and change, the same way the speed of light is a constant in the universe. The reason why this is relevant with Scrum, is because from a Project Manager’s point of view, or a Product Owner’s point of view, his most important task is to prioritise his feature requests such that the agreed upon deadline is reached, implying having a „backlog“ of requests passed to the developers, orderly specified, such that the most important stuff is at the top. This might result in that as we reach the deadline of the project, some features needs to be either scrapped, or implemented later down the road. MVP is typically used here implying „Minimum Viable Product“, defining what is the minimum feature set the product must have in order to provide (useful) functionality, solving the problem at hand. The way we’ll use GitHub to accomplish this, is by simply creating and using a bunch of labels such as the following. Keeping things as simple as we possibly can, but not simpler Typically my workday then implies going to GitHub, prioritising bugs and issues that are „Very-Important“ and „Important“, possibly adding some „Not-Important“ issues at the same time, if they are related to important and very important issues, fixing these issues, QA the system locally on my own development machine for a couple of days worth of development, and deploy – At which point I let the PM know I’ve created a new deployment, allowing him to go through the issues marked as „Done“ on GitHub to verify I’ve done what he requested. In addition to me associating commits with issues at GitHub, allowing him to easily see all issues I’ve finished, due to me tagging the repository every time I create a release, allowing him to diff changes between releases, linked to issues in the GitHub board. Basically, SLAUGHTERING Scrum and Agile 100% – ONLY implementing the bare minimum of what the process requires. Then in later projects, maybe we can start adding more features from Scrum and Agile software development, as the need arises. However, at the moment, practically the only thing we actually need is the ability to track and prioritise bugs and feature requests, implying I could arguably have taught you the entire process in 5 minutes, if I hadn’t gone through all the detours to explain my rationale in regards to all the other parts above… Hence, the things we’re using from Scrum are as follows… Basically almost nothing is what we’re left with, implying I can „teach my CEO (the relevant parts of) Scrum“ in 5 minutes ^_^ Why keep it simple when you can keep it even simpler? Opinions expressed by DZone contributors are their own.<\/p>\n