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.

  • 1
    There are a lot of factors that influence to the choice of a suitable framework. "Ongoing products" is just one of many. So, there is no canonical answer to your question. All answers will reflect personal tastes. – Sergey Kudryavtsev Aug 29 '18 at 12:24

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.

  • Why do you think that MSF is the best solution for ongoing products? – Sergey Kudryavtsev Aug 29 '18 at 12:14

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.