Which product development methodology is best?
We’ve created something we term “benefit-based sprints,” which we pair with choice 1.
As usual, we are under pressure from the company to provide timetables, but we require time to iterate.
Because of this, I only make “benefit” commitments to the company rather than “feature” commitments. The quickest time delivery is 3 sprints, and a benefit is what a consumer will experience. A feature is created through two-week sprints and is how we will make that benefit (dev process centric) available.
In this way, as long as we enable the anticipated advantages, I have the freedom to iterate features and builds.
The best thing is that the advantages can have a direct or indirect link to revenue, which makes it simpler to develop business cases. So anytime the business asks for a new benefit, i can link it to a business case and budget requirement to make sure that it’s worthwhile.
How can you demonstrate that a benefit was realized so quickly? Even when using lead indicators, our a/b tests typically take weeks to complete, which makes it difficult for us to demonstrate impact.
That’s a very good question.
I split that into 3 phases, each of which has a different objective:
Sounds long and complex, but when you look at things holistically it saves money, especially when considering wasted time and effort on building useless things (which we can now quantify).
There is no one-size-fits-all answer to which product development methodology is the best as it largely depends on the specific needs and constraints of the project, team, and organization. Each methodology has its own strengths and weaknesses, and the right approach may vary depending on the context.
That being said, each of the methodologies you listed has its own benefits and drawbacks:
a) 2-week sprints with Planning, Refinement, and Retro Rituals (Scrum): This approach is popular among Agile teams and is focused on delivering a potentially shippable product increment at the end of each sprint. The regular rituals help the team to continuously improve their processes and deliver value in a consistent manner. This methodology works well for projects with a clear vision and a defined set of requirements.
b) Kanban - weekly (pick top tickets in the column): Kanban is a Lean approach that emphasizes visualization, limiting work in progress, and continuous delivery. This approach is useful when the project has a lot of variability in its requirements, or when the team is dealing with a lot of unplanned work.
c) 3-4 week sprints with some form of Scrum: This approach is similar to the first option but with longer sprints. It can be useful for projects with more complex requirements that require more time to plan and deliver.
d) 6+ week cycles with 2-week cooldown for scoping and prio: This approach is better suited for larger projects with longer development cycles. It allows for more time to plan and prioritize work, and can be useful when dealing with a larger team or multiple teams.
Ultimately, the best approach will depend on the specific needs and constraints of your project. It may be helpful to try out different methodologies or hybrid approaches to find what works best for your team.
I’ve been a big fan of Kanban. Kanban is a methodology for managing work that emphasizes visualizing work, limiting work in progress, and managing flow. One of the key features of Kanban is the use of a Kanban board, which is a visual representation of the work that needs to be done, organized into columns that represent different stages of the workflow.
When using Kanban on a weekly basis, one common approach is to pick the top tickets in each column at the beginning of the week. This means that each column would have a limit on the number of tickets that can be in progress at any given time, and at the start of the week, the team would review each column and select the top tickets to work on.
The number of tickets selected would depend on the capacity of the team and the complexity of the work. It’s important to balance the workload across the team and avoid overcommitting to work that cannot be completed in the given timeframe.
Throughout the week, the team would focus on completing the selected tickets, with a goal of moving them across the Kanban board and eventually completing them. If new work comes in during the week, it can be added to the backlog column and prioritized for the following week.
At the end of the week, the team can review their progress and assess the effectiveness of their approach. They can also adjust their approach for the following week based on their experience and feedback. This iterative approach allows the team to continuously improve their process and deliver work more efficiently.
We avoid sprints. We focus on having something “demo-able” every week while continually deploying to production and working behind feature flags. We have quarterly and half-quarterly-ish cycles. Releases are independent of this timetable. The process of scoping and prioritization is reviewed almost regularly. For some bigger things, discovery usually comes first, although it’s always taken up occasionally.
Using a (very close) variation of Shapeup, the 4th option, and am one of (currently) 3 votes on it. Very comforted to see how unpopular it is.
It’s a hot mess and I hope I can help steer other orgs clear of that. It was adopted prior to my arrival at current org, but with the CPO and VP being shown the door, I have an opportunity to change this. It’s being used to further enable an already unhealthy engineering-driven mindset where I work (I think it’s fair to say this is true of Basecamp too, and so I don’t consider this a coincidence).
Fortunately, I communicated the issues I saw prior to the stereotypical failure of engineering-driven direction - the creation of a 10x over engineered, hypercomplex Platform before one user ever paid for access. It has opened eyes to the need to be more pragmatic about when “building right” is… right. Otherwise I suspect either my leadership would be still in place (and nothing changes), or I’d have been shown the door with them.
Being religious about any one methodology is wrong, but holy cow Shapeup is the first one to make me swear never to use it again.
We have settled for a “scrumban” version that seems to work for us this far. We plan the major “themes” based on the outcome we have set for the quarter (we do OKR’s). The “themes” include discovery and delivery activities and are also prioritized. Then we have a quick sprint planning where the team themselves create or pick user stories and tasks in order to progress within the theme. Once we have reached a proposed solution/s to the problem they will work toward “definition of done” for the different solutions that arise from the discovery and delivery done within the “theme”.
We do retro every two weeks as well to identify problems in our flow etc.
Loved working under Kanban in one of my previous orgs. Organization I’m at now is a bit more rigid. I tried to implement it this time around but leadership wants very defined/agreed upon timelines. Work began to slip and we had to move back to scrum. The sprints are good for establishing clear milestones and keeping devs in check.
Me too. But, trying to force feed an entire business under one methodology is… Suboptimal. It’s a shame this is so often the case.
In a previous life I was a Director for a series of B2C e-commerce microsites and a shopping cart engine and B2B2C backoffice that underpinned the whole thing. I used 3 different approaches, wherever each worked best. It was also a small bootstrapped company with less than 30 devs, making it easier to be nimble that way
Scrum worked best for iterative incremental growth of a new or actively evolving product, kanban was great for simple or mature products/feature areas in a maintenance cycle, and waterfall was very useful for a backend system that needed to be very clear ahead of time in development of systems that everyone relied upon.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.