Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
According to the Scrum guidelines, the development team has to do all the tasks required to fulfil the definition of "Done".
There are projects like mine, however, which are organized on teams focused only on parts of the development(a team build frontend, an other build the database, other does the QA and so on). So, should these projects restructure themselves into a feature oriented approach in order to adopt Scrum or Scrum shouldn't be applicable for such projects?
I use scrum for a combination or bug fixes and features.
When you have a large backlog of issues it is easy to get stuck churning through the backlog of issues and never feel ready to release. For my team, we plan the time for the bug fixes and prioritize them accordingly so that we react quickly and have a vision of the release for the next iteration.
Kanban also works, but I think it depends a lot on the team culture. You can switch from SCRUM to Kanban if the situation calls for it (such as launching a new product that cannot be launched before the set of issues are fixed). However, if a Kanban is not well managed, there is a high risk of getting into a never ending development where you are never ready to release because new issues continually crop up. SCRUM ensures you release and ensures that everyone knows and agrees that the release will happen and is equally responsible. To achieve the same culture in a Kanban would require a lot more discipline from the entire team.
the development team has to do all the task requiered to fullfill the definition of "Done"
This depends on what the definition of Done is. If you have a feature that affects different areas or so different teams then yes. But if you follow SCRUM you will find that some parts of the SCRUM don't depend on others and you can have a release of the individually "Done" items while moving the unfinished items to the next iteration.
Use feature tems have any advantage, like easuer way to comper the productivity, make estimates, fast delivery?
SCRUM is a methodology. It is a list of guidelines and not a strict set of rules to follow. The most important lesson in SCRUM is to learn to adapt. Adapt to your team, your environment and your goals. Don't be afraid of making a mistake and learning from it. That is why you have a retrospective at the end of every sprint, to learn and adapt. And that is why you have a sprint, to time-box your work, keep it short, on schedule and learn fast.
Scrum can be used for application development or for maintenance projects. Ideally small changes or modifications are not added to scrum however for a middle to large sized projects, Scrum is a must.
Scrum helps you stay focused and at the same time takes burden off you to think about a large project on hand. It has to do with how a project can be managed in chunks that decides the efforts that a team need to apply.
For Maintenance projects, kanban or Waterfall approach also makes sense but for application development projects, opt for scrum, no matter you are a part of testing, UI designing, Development or any of the teams.
I'd say yes. Teams working on maintenance (application management) will rather benefit more from Kanban boards or other approaches.
On the other hand, maintenance teams might also work on releasing hotfixes or cummulative updates, which are projects that could be carried out according to Scrum.
Scrum teams consist of all the people needed to build a working product.
This is a core value of the Scrum framework. The Scrum guide states:
Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.
A team like this has few external dependencies, which means:
This is a more efficient way to work that usually delivers substantial productivity gains.
We also use Scrum for teams that have both new feature and maintenance tasks in a given sprint.
On established, selling, products, it is uncommon to see a complete segregation between maintenance and new features. Engineers who developed feature X on the previous release are likely to support it in the current one, and can't be pulled 100% to new work. Engineers also become subject matter experts (SMEs) in a given area, and have to devote some of their time to maintenance while working on the next release.
As L.Young correctly points out, maintenance work also has release and sprint targets. So, Scrum has to work in situations where teams are organized based on technical ownership, and again, in my experience, it does.
Kanban is a good approach when it comes to troubleshooting and dealing with unplanned issues from the field. However, as soon as the issue is understood and slotted for a release, it should fold into the same Scrum framework that is used for new features.
In summary, there is no strong reason to reshuffle them across features: not unless there is existing evidence that the current arrangement does not work. Moreover, if engineers are already engaged on a mix of feature/maintenance work, and/or you have many small features in your releases, then such a change is likely to reduce productivity, and drag people into multiple concurrent feature Scrum teams. On the other hand, if you have a few major features that occupy people 100%, and little maintenance work, then shifting into feature teams may help.
There's a bit more on that here: http://romankleiner.blogspot.com/2015/04/scrum-part-xi-module-teams-or-feature.html .
