Agile Methodology for business intelligence
Hello everyone,
In the business intelligence project, we are currently examining our life cycle. I just started the team as a kanban master and I'm currently in the monitoring phase. A methodology called extended kanban is applied, but as a result of observations, it cannot be said that it is applied correctly. Frankly, I would like to exchange ideas here rather than criticizing the current process. If there is a possible change in methodology in the future, I am researching what should be the correct methodology.
I'm transferring the existing structure;
- Multiple teams are available under a business intelligence production line. Each team mainly works on different products, although they are slightly dependent on each other. However, there was no integration management process.
- There are not many external dependencies. Current dependencies are handled with sync meetings between all production lines
- The works of the 4 teams are included in a single product backlog. This product backlog is managed by a single product owner.
- Each team sets separate iteration goals and commits to them.
- Each team has its own sprint backlog, kanban board.
- We are holding separate events (Planning, Daily, Review, Retro meetings) for each team.
- The number of maintenance and error request records in iteration is quite high
I shared the existing framework items that are basic in terms of ideas. I know these will not be enough for a methodology research, but I just want to learn from you which methodologies I should turn to.
I came across some business intelligence specific methodologies (like Data Driven Scrum). However, there are also methodologies under scaled agile, such as Nexus, SoS, and LeSS.
We take out our deficiencies and problems, item by item. However, I would like to go into the details of these methodologies in parallel. Which methodologies should we examine extensively?
Best Regards,
I would like to go into the details of these methodologies in parallel. Which methodologies should we examine extensively?
Don't. None will help you, because no-one else's methodology can possibly address the exact situation you are in.
A framework like Scrum, however, may be of use. Scrum is minimally prescriptive and allows teams to craft and continually improve their own process in their own operating context.
Right now you have an obfuscated situation with multiple products per Product Backlog, and a consequent lack of transparency over the quality required for work to be integrated and Done. My advice is to focus on elementary framework elements such as the Definition of Done and so resolve the maintenance issues and errors you are currently experiencing.
The first rule of scaling: Don't do it if you don't have to. Why? Because scaling adds overhead, such as extra events and meetings.
If your four teams were working on one Product, then a framework such as Nexus might help (if you have done everything possible to de-scale). For example, the four teams might need a Nexus Backlog Refinement event to decide which work will address which PBIs in upcoming Sprints and tackle dependencies. When working on the same Product they might also face integration issues that need to be addressed with a Nexus Daily Scrum. Again extra meetings and overhead.
If you decide you need a scaling framework, my suggestions are to research Nexus and LeSS. Nexus is lightweight, and Scrum is still Scrum at the team level.
Scrum on!
Thank you individually for your answers. Nexus is obviously much more suitable for our structure, but here I would like to say that there are different products as well as products that teams work together. Can Nexus be preferred here again?
The Nexus is organized around one product. Whether or not you use Nexus, Scrum is still Scrum, which looks like:
- One Product...
- One Product Owner...
- One Product Backlog...
- One Definition of Done...
- One Product Increment...
- One to Many Scrum Teams, each with their own Sprint Backlog and associated Sprint Goal
A Scrum Team would not have multiple products in their Product Backlog.