SCRUM – Suitable Projects for SCRUM Methodology

It looks like you took some fancy items from agile development, put them to waterfall process and now you call it agile.

The product is developed for a customer who will re-sell it while paying us royalty.

This is OK.

The team does not get to talk directly to the end user. Only to the reseller.

This is OK. Product owner talk to reseller and collects requirements.

A product requirements document was created before starting development.

This is not OK. I haven't seen the project where definite requirement set can be defined upfront. Change your product requirements document to product vision (short) with some initial set of requirements which are subject to change.

The requirements are rigid and do not change.

This is not OK and you will see in the future that it is also not true.

A delivery schedule was agreed on with milestones such as "alpha", "beta" etc. and features/times attached to those milestones.

This is not OK. The real schedule will be visible from the team progress. You can make general milestones but assigning exact set of features which will be implemented in these milestones is not agile. This can change during development.

All developers on the Scrum team report to the product owner, a software manager.

This is not OK. I would not say that developers report to product owner. Scrum process keeps visibility of the process but developers do not report anything except regular meetings. It is responsibility of product owner to be in contact with a team and as active participant see the progress himself.

Testers on the team report to a QA manager.

This is not OK. Testers should be part of development team because user story is not done until it is tested (there should be automated test to validate acceptance criteria). There can be separate QA but it is additional level of complex testing and it is usually done on customer side (but doesn't have to be) to validate that SW does what customer expects and the feedback is collected as new backlog items or bugs to existing completed backlog items.

Separating complete QA outside of development team leads to breaking the whole purpose of definition of done. Some QA must be part of the team and that part is not related to any QA manager - that part is doing commitment with development team.

The product owner has directed the team towards certain high risk technical tasks. The output of those tasks is not usable by the end user but rather some technology/code that will eventually be used in the product.

This happens in every project but it should be part of some product backlog item targeting end user. It can be included directly in backlog item implemented in current iteration or it can be included as a spike (proof-of-concept) to clarify complexity of some backlog item which should be implemented in the future.

The product owner has created a backlog based on the requirements.

This is a must.

The product owner is unable to answer some questions regarding the product. He refers to others or to the documented requirements.

This is not OK. It is job of the product owner to know answers. He has a responsibility and he must do decisions. If he doesn't know answer he must find it asap.

The team goes through the motions of Scrum. Daily Scrum, Sprint Planning, Retrospective etc. There is a ScrumMaster.

This is OK but it doesn't mean that team is doing Scrum.

Every sprint the product owner and management decide what backlog items the team works on.

This is definitely not OK. The product owner and management can make priorities but commitment (selection of most prioritized items) is teams responsibility.

There is a burndown chart. Scrum board with stories and tasks. The estimates on those come from the team.

This is OK.

The team sits in an open floor "bull pen" shared with other teams, all visible and audible. There is cross-team noise and there is foot traffic around the team area.

It is Scrum master's responsibility to make end of this if team feels like it reduces their productivity.

The team may be required to attend various meetings not directly related to the goals of the sprint.

It is OK, the time wasted on these meetings will result in smaller commitment (team will do less real work). It is up to Scrum master / management to reduce these meetings to increase team's velocity.

There are pressures to select certain technical solutions. Some tools and processes are mandated.

This is partially OK. There can be non-functional requirements for tools and architecture and there can be defined processes but still final implementation is up to the team.

In Scrum, the traditional role of the PM is really divided into the roles of the Product Owner and the Scrum Master, with some responsibility also falling to everyone on the Scrum team.

The Product Owner is responsible for defining the project scope, prioritizing work by maintaining the product backlog, deciding if the effort should continue into future iterations, and being involved in risk management and mitigation strategies as a representative of the user and customer. In other words, the Product Owner deals with things that happen outside the team, with regards to the user and customer, and provides a single focal point for this information.

The Scrum Master is more process and team oriented. This person manages the resources, often takes point on risk management and mitigation strategies, and deals with the process and ensuring that the people who need information but aren't on the Scrum team have access to it and visibility on the work being done and any successes and failures of the team.

Some work is delegated to the team as a whole. For example, there is no single individual providing organization and instructions - the team as a whole works with the product backlog and previous data to determine how much work to take on in a sprint. Also, risk management is another activity that falls to the whole team, with the Scrum Master facilitating the process.

Finally, some concepts don't map well to Scrum at all.

There isn't an up-front idea of the total number of iterations needed. The idea is to set a timebox on iterations (often 2-4 weeks) and have a potentially shippable deliverable that adds value. The project ends when the backlog is empty or the needs of the customer change such that funding another iteration would cost more than the value added by the work that can be done. Of course, it's not a blind idea - you know by watching the backlog and working with the Product Owner when the project is approaching a termination state.

In addition, potentially releasable software is produces no less frequently than at the completion of every sprint. The idea is that there is a value-adding product at the end of every iteration. This product has been designed, implemented, tested internally, and undergone acceptance testing. All documentation and guides associated with the product are also up-to-date. In other words, if the customer wants it, they can get it. However, they might not want to go through the effort of deploying a product at the end of every sprint, but it's an option. Because you are responsive to change, you should be able to denote an actually-shipped product in your sprint planning meeting.

It's not advisable to combine the role of Product Owner and Scrum Master because they are concerned with different things. The Product Owner is working from the perspective of the end user and the customer - deliver the most value in the least amount of time possible and demand a high quality product. The Scrum Master is team centric and provides a counter balance to ensure that the team isn't overworked, has the resources they need to do the best job, and that they are generally happy and productive people. I, personally, think that someone who is skilled enough can probably play both roles. However, it does take a skilled manager and leader to do so. There's a great deal of information about this in a Project Management Stack Exchange question about combining the roles of Scrum Master and Product Owner.