We started 2 years ago. we had a technical co-founder/full-stack developer with us. we used the waterfall approach and released our product 1 year ago and since then we moved very slow on development.
our developer/co-founder left us 3 months ago. we recruited another developer and also add two other experienced advisors (managerial and technical) to our team.
we're going to implement a software development/team management methodology to improve our productivity and increase our development speed and quality.
I've studied a lot about it and came to the conclusion that it's better for us to use a combination of scrum and kanban.
what do you think about it? keep that in mind that in this team we haven't used any methodology before.
For the teams I've been working with in the past, a "lightweight Scrum" was working the best. "Lightweight" means that we won't have a formal planning poker or face-to-face daily stand-ups, or sometimes even points estimation.
What we'd have is bi-weekly planning, tracking, and asynchronous reports (What was done yesterday? What you plan on doing today? Is there anything that's blocking you?)
We would also iterate fast, and make sure we adapt if something unplanned comes up.
Having been working with dozens of teams - both local and remote - I can give you some more specific tips on how to improve the velocity of your current team, but I'd need to know more details :)
If your team is releasing updates constantly & there are edits to the list of features to do, Kanban would be the way to go.
AGILE is best when everything is defined and would not change.
I work in a company that worked on AGILE. But the nature of our team's work would constantly have numerous changes by the client mid-sprint. So, we shifted to Kanban
I have built a number of high-performing teams and defined the respective processes.
Honestly, I don’t think you are asking the right question. Asking for the simple red or the blue pill may be tempting, but it will not get you the results you need. For Scrum or Kanban to work out of the textbook, certain assumptions need to be met (which is rarely the case).
So in order to really improve your situation, you need to
- start with your customers, and understand how you serve them. What is important? What makes their day, and how do you make an impact?
- where is your risk? Is it with developing the wrong product? Or with being too slow/too late?
- do you have stable requirements, or would you need to adjust rather quickly?
And there is more depending on how you operate, or want to operate in order to succeed.
The right process for you needs to be derived from this, and then iteratively refined.
Sorry, this is more work than you looked for, but it will save you a lot of headache trying to make a blueprint work that never fitted in the first place.
Don’t bet your company on a method - shape your processes according to your situation. Get help to get it right.
Process evolution at startup is always a challenge.
Your current team (one developer and 2 advisors) is in actual one member team ( I am assuming that advisors are not doing any technical software development)
Formal SDLC approach will be a challenge and it will always be for this software developer to juggle
a) New feature / functionality development
b) Defect resolution from past year release
c) Any incident , defect or change in the past year release
My suggestion would be to build an ServiceDesk like item log ( divided into three categories above) and prioritize for the developer in consultation with manager and technical advisor.
The best project management style changes at every stage of a company and depends on what you are making, so nobody can really advise you without knowing your product and team.
Most developers tend to hate Scrum and its variants anyway. Check out this HackerNews thread to get some insight:
And, check out this guy's videos. He talks a lot about different Agile options and why he loves Scrumban. Convinced me to give it a try.
Hope that helps,