20
Sep

When Scrum Fails

   Posted by: wkossen_admin   in development, Tech

Sotto sforzo
Photo by Gilmoth
Scrum is a method used in software development that is aimed at creating software that fits the business needs better in managable projects with predictable outcomes. It can really help development projects along. There is however a big risk involved in the way selections are made what to implement, and what not.

Wikipedia tells us:

During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog,” which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed. The team then determines how much of this they can commit to complete during the next sprint.[4] During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.

The problem here is not the fact that the Product Owner decides functionality, but that the Product Owner may not have the right information to decide on the priority of non-functional requirements that originate in the technical teams within the organisation. Security, scalability, but also conformance to architectural principles, standards and directions are sometimes sacrificed against functional traits of an application. This is risky business that can stimulate unhealthy code and poorly performing software.

The method itself does not have means in place to insert priority boosters for non-business functions which is the main cause of the problem. The Product Owner therefor shouldn’t be a single person from the business side of the organisation, but a team of stakeholders. That way a balanced feature selection proces can take place and most of the risks are averted.

What’s your take on this?

Related posts…


If you enjoyed this post, make sure you subscribe to my RSS feed!
This entry was posted on Monday, September 20th, 2010 at 20:00 and is filed under development, Tech. You can follow any responses to this entry through the RSS 2.0 feed.

Word count: 382

You can leave a response, or trackback from your own site.

One comment

 1 

The PO manages stakeholders. An architect could be one of them… Then it's just an issue of playing the game with the other stakeholders and get the priorities right. At the end the customer decides what is most important it is the task of a good architect (as a stakeholder) to get the right priority on non functionals.

So, in my opinion it doesn't fail in this case.

September 27th, 2010 at 8:19

Leave a reply

You must be logged in to post a comment.

Copyright © 2008 - 2010 Willem Kossen

you're welcome to reuse under certain conditions. It is licensed: Attribution-Non-Commercial-Share Alike 3.0 Netherlands

Internet Blogs - BlogCatalog Blog Directory


Page Rank

look here:

Blog Directory Blog Directory