We are a product based company. Which is a best suitable agile methodology for ongoing products? Its like we have to keep improving our products to stay competitive. Looks like its never-ending thing.
closed as primarily opinion-based by Sergey Kudryavtsev, Sarov, Roberto Anzaldua, Todd A. Jacobs♦ Aug 30 '18 at 21:10
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
We are producing a never-ending SaaS product that actually started life in 2006. We use Scrum and have done for around 5 years. It has increased our productivity immeasurably and in my opinion is ideal for this type of development.
One other advantage is that if a product carries on year after year, your staff will change, however a well disciplined Scrum team makes it easier for new members to slot in fairly quickly.
Microsoft Solutions Framework is a set of principles, models, disciplines, concepts, and guidelines for delivering information technology services from Microsoft. MSF is not limited to developing applications only; it is also applicable to other IT projects like deployment, networking or infrastructure projects.
A good starting point is Scrum and then adapt from there onwards. As long as you hold good retrospectives and follow through on issues raised you will find your feet. Don't be afraid to adapt change and research. Make sure you become or have an Agile champion. Things will go wrong, just learn from them, keep people informed that this is the plan, improve, improvise and get better. (focus on keeping the stakeholder (everyone) informed and engaged)
As others have said, Scrum is a good starting point. Scrum gives a good structure if teams are new to Agile. Having a designated Scrum Master is pretty essential to getting going. In time, teams can become more self-sufficient, running their own ceremonies, and keeping the backlog in good shape during the sprint (so, outside of a planning session).
As a team matures, it may be worth looking at Kanban too. I've found this works best for teams who are proactive at writing tickets (via just in time planning) and keeping them to roughly the same size.
One approach I've used is to have Scrum for projects, and Kanban for ongoing BAU-type work. There are pros and cons to these and other methodologies. Whatever you do, make sure you have retrospectives so the team has the opportunity to inspect and adapt.