.NET Custom Software Development

Agile Product Delivery: Deciding The Right Formation Before The Game Begins (Scrum, Kanban, XP Or Lean)

This image has an empty alt attribute; its file name is Agile-1024x597.jpg

Getting the product delivered to the customer is the most vastly, intensely and widely played game in every corner of the world at different levels in IT services/product company. To win in the game you need to have right kind of strategy/formation which covers the right mixture of attack, defence and hold techniques to cross over the line. Similarly, for successful delivery of agile projects you need to have right ‘Agile Product Management Methodology’ ready and we share our experiences below in choosing the right methodology based on different scenarios encountered with different businesses.

Deciding the right product management method: Scrum or Kanban or other frameworks

For the agile product delivery game, it is important to decide first the right product management method of agile which will work for you. Every customer is different, every team is different and every product is different. You need to decide collaboratively with your team and customer which works for you the best. Few scenarios which we encountered are highlighted below: –

Scenario 1: At the start of the project, customer is clear on the 60-70% of the requirement. Which is ideally should be the case when you are starting any project, for this kind of a project Scrum model of delivery worked really good for us, having defined 3-4 iterations of 2 weeks in advance with the help of product backlog which was defined before laying out the final iteration plan and release plan. And with the help of retrospective the other 30% percent were covered with an additional 2 iterations of scrum to final launch.

Scenario 2: Start of the project, customer is not clear with the requirement and is highly dependent on marketing team or other teams for the inputs. First of all, we would highly encourage to have a good set of backlog to take up any requirement into any type of product management. In this case, our team adopted Kanban approach, where we got the requirement and analysed it thoroughly and then had the right workflows defined for product owner to analyse and take decisions after which it was taken into custom iteration which could be daily or weekly. In Kanban, project doesn’t have end dates defined, team members keep on working as the tasks arrived.

  • After a period of 3 weeks to 1 month, the requirements started to get more clear, we then slowly switched on to the Scrum method for delivering more items and picked up a better velocity till the launch of the product.

Scenario 3: Towards the end of development stage and start of UAT/Internal launch but still work needs to be completed to launch the product. Once the product reaches a delivery stage there are lot of last moment changes or feedback you get during the internal launch and panic start to creep in for the successful launch. We decided to shift from Scrum to Kanban model of delivery, where product owner was receiving feedbacks in forms of tickets and was tasked with prioritising the tickets and getting the right/high priority tickets forward to the team on a daily, weekly time frame for the next 15 days to the hard stop before launch.

  • Shifting model worked really well for us in various projects where we mainly encountered the above 3 scenarios.

From the above scenarios you can observe how it is similar to a football, soccer or a cricket game where you are continuously manipulating the pace and strategy to be ahead in the game to take the game over the line. Similarly, while delivering the product it is important to understand which agile methodology actually fits your team for a successful launch of the product or the project and how to shift between those if required.


To Summarise, we would recommend to understand the following before deciding the agile product methodology for your product launch: –

  1. Requirement Clarity
  2. Requirement Frequency
  3. Customer/Product owner availability during the process
  4. Timelines of the project

Also, you can view one of the similar article already written by Josh Aberant from the here, which forms the part of my hypothesis above.

Leave a Comment

Your email address will not be published.