Tag: agile

Agile for Start-Ups – part 2

November 4, 2021 /

In the last article, I shared the usual disadvantages when teams use agile methods in early Start-Ups. In this part, I shall give you my list of modifications and changes over the standard agile workflows. All of them are based on my experience and errors accumulated during the years working in underfunded Start-Ups. Additionally, I shall give you additional information regarding how it can affect team morale and motivation for every modification. But let me list the different changes I used during the years:

  • Do not do peer reviews: Peer reviews work pretty well for improving code quality and knowledge sharing. However, they are one of the biggest bottlenecks in your team workflow. Additionally, to have productive peer reviews, the peers must usually be at the same level of expertise. The best case is for the reviewers to be with more considerable expertise than the reviewed. For early-stage Start-Ups, I would suggest senior management appoint two or three people to do all the code reviews in the company. With this approach, team morale and motivation will increase because you would avoid much friction and drama.
  • Avoid unit tests: Unit tests are one of the best ways to increase your code quality. However, during the early stages of your product, where you do a lot of research and expect significant refactoring of the code base, unit tests, constant maintenance can kill your velocity and hurt your team morale. Usually, after the initial effort to create the tests, the team stops maintaining them after a couple of tight deadlines, and finally, they are entirely disabled. Better spend your time doing integration, smoke, or component tests because they work on established APIs, and these APIs do not change dramatically.
On the diagram, you can see the traditional technical team structure of four layers. In early-stage Start-Ups the positions CTO, Head of Development, and Team Lead are usually held by the same person
  • Don’t be sloppy with your architecture: Make sure your technical architecture is solid and can be upgraded or refactored easily. Quality of code is not so important because you can improve your code quality quickly, but not your architecture. Many teams decide to start with less complex architecture, and after that, they have to reimplement the solution. Better, plan how you are going to implement your architecture in phases with change in mind. Start with only the essential components and upgrade them later. Doing something twice is the most significant morale and motivation killer in one team.
  • Do not estimate R&D: Early-stage Start-Ups usually must not plan research and development. It would be best to entirely avoid research and development and work on already established business or technical models with minor modifications. Innovation is expensive in terms of time and money. It should be avoided or minimized as much as possible.
  • Threat every task as a different sub-project: Many company owners love to categorize their products using the famous triangle of quality, speed, and time. However, the major mistake is that a software product is a collection of submodules. And every submodule comes with its complexity and implementation. It is much better to treat every submodule as a separate project and decide what we expect using the quality, speed, and time triangle.

In conclusion, these are my leading suggestions for every early-stage Start-Up team. To extend your Start-Up life, you should cut time and resources from every non-essential part. My proposed list gives some hints in that direction, and I am sure you could create your lists by filtering what the essential and not the essential activities in your team are.

Agile for Start-Ups – part 1

October 28, 2021 /

I want to start these two articles by observing that I don’t believe agile methods are appropriate in their proper form for Start-Ups. In the first article, I will list most of the disadvantages of the agile methodologies and how they could hurt the Start-Up’s performance. In the second one, I shall present what worked for me in the past and what did not. 

But let’s start with little history of the product management frameworks and how they evolved. Historically the initial management framework was the so-named waterfall or phased approach. With that approach, the companies copied how most engineering products are created by multiple phases and initial requirements gathering. This way of working does an excellent job when you want your solution to be installed on-premise and must work for a long time without interruption. 

In the 80s of the last century, Watts Humphrey, during his work at Carnegie Mellon University, founded the Software Process Program, and with that, he started the so-named PSP (Personal Software Process). This process heavily relies on not comparing the performance between different developers but rather trying to improve every developer as a single unit. Additionally, in PSP, we have the notation of knowledge re-usage – aka if the developer has implemented something similar as a block in the past, we could expect him to implement such block with the same speed.

In 1986 Hirotaka Takeuchi and Ikujiro Nonaka started Scrum and the foundation of different agile methodologies. At its core, the agile development process defines that the “customer/client/company owner” will work together with the team and provide business knowledge and requirements weekly. A fundamental principle of Scrum is the dual recognition that customers will change the scope of what is wanted (often called requirements volatility) and that there will be unpredictable challenges — for which a predictive or planned approach is not suited. These changes come from various sources, but understanding why is irrelevant: change should be accepted, embraced, and analyzed for benefits.

On the diagram, you can see the standard agile workflow. Its typical duration is between 1 and 4 weeks. In Start-Ups, the main problem is during the planning meeting because it is impossible to plan R&D

And now here are some reasons they do not work well for complex Start-Ups:

  • R&D: All of the listed methods work on the assumption that the team will not do any research and development. Aka, the business owners know their business niche and that someone else already did the R&D part. In reality, this rarely happens, except when we start a business without any innovation. When you want to make an innovation, all traditional product management frameworks stop working. Usually, in the Start-Up World, the team must do R&D and code writing simultaneously (investors and clients want to see progress).
  • Burnouts: Constant changes in business requirements and business situations usually involve many changes in the technology stack and your programming code. Sometimes you must rewrite the whole product from zero. And this typically takes its toll on the engineering team. For sure, if you do not manage to make business traction (aka finding clients) for the first three years of your Start-Up, it is virtually certain that this lack of progress will demotivate your technical team, and most probably some of the members will feel the effects of burnout.
  • The process will not mitigate your people’s weaknesses: According to most agile methodologies fans, these methods are the panacea for every technological problem. However, we have to ask ourselves why only 5% of the Start-Up technical companies pass the second year of work? All of them use these methodologies. For sure, we could blame the business development and marketing, and we will be right that 70-80% of one successful business is the way you sell. However, at the same time, I saw many technical teams struggling in their performance because of leaning too much on the agile principles.

In conclusion, I would want to emphasize that no product management workflow in the World will mitigate the weaknesses your team has in the first three years of your Start-Up. The only way to increase your team productivity is by training them, and by training, I mean the business and the psychological part of being into a Start-Up. Technical knowledge is much easier to adopt and realize than handling that your odds of winning a VC are 1:300.