6

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?

  • Hi Felo, welcome to PMSE! I've slightly restructured your question to make it more applicable to other projects, I hope I kept the underlying question still applicable. Feel free to revert it back if I missed the point. Notice I removed the last paragraph asking about the advantages of working feature (or story) oriented, since it's broadly available over the internet. – Tiago Cardoso Nov 15 '16 at 15:07
0

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.

  • 1
    Or with KanBan, you release multiple times a day, once for every card moved into done. – Michael Shaw Nov 15 '16 at 21:17
  • Yeah. -1 for a complete misunderstanding of Kanban. A story isn't done until it's been released, so you release whenever a story is ready, not once at the end of every sprint. The problem you describe doesn't exist. – RubberDuck Nov 19 '16 at 21:48
  • @RubberDuck "A story isn't done until it's been released, so you release whenever a story is ready, not once at the end of every sprint." - you're mixing up the concept of Kanban and Sprint here. In the case of Kanban you release once ready, in the case of sprint you release once the timebox is done. Maybe you misunderstood my comment. I don't know where you got the idea idea that I said a Kanban is released when a sprint is done. It makes no sense at all since Kanban and sprint are different methodologies. – L. Young Nov 29 '16 at 9:52
  • "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" -- I've not found that statement to be true. If anything, you release more often with Kanban. – RubberDuck Nov 29 '16 at 9:55
  • I disagree and following on your statement " A story isn't done until it's been released, so you release whenever a story is ready" - I think it is contradictory to you second statement. If you are working on an already released product then you release more often but if you are using Kanban for a new product (such as the example I gave in my answer) then you don't release until it is Done. Definition of Done being defined by the characteristics required. The point of my answer was, you need to adapt and be prepared to change depending on the scanerio. – L. Young Nov 29 '16 at 10:00
1

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.

0

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.

0

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:

  • They can solve most of their problems within the team
  • It is easier to plan
  • Communication is easier
  • It is easier to work out the team's capacity and so estimating is more effective

This is a more efficient way to work that usually delivers substantial productivity gains.

0

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 .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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