Is this agile? Scrum? How to improve agility?

Question

Is this agile? Scrum? Any suggestions on how this can be made more agile under the circumstances? Which points are positives and which can be improved?

• The product is developed for a customer who will re-sell it while paying us royalty.
• The team does not get to talk directly to the end user. Only to the reseller.
• A product requirements document was created before starting development.
• The requirements are rigid and do not change.
• A delivery schedule was agreed on with milestones such as "alpha", "beta" etc. and features/times attached to those milestones.
• All developers on the Scrum team report to the product owner, a software manager.
• Testers on the team report to a QA manager.
• 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.
• The product owner has created a backlog based on the requirements.
• The product owner is unable to answer some questions regarding the product. He refers to others or to the documented requirements.
• The team goes through the motions of Scrum. Daily Scrum, Sprint Planning, Retrospective etc. There is a ScrumMaster.
• Every sprint the product owner and management decide what backlog items the team works on.
• There is a burndown chart. Scrum board with stories and tasks. The estimates on those come from the team.
• 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.
• The team may be required to attend various meetings not directly related to the goals of the sprint.
• There are pressures to select certain technical solutions. Some tools and processes are mandated.

Answer 1

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.

Answer 2

Looks like a mini-waterfall rather than fully agile approach

This may be splitting hairs

Although on the surface it look like an agile approach I believe it may have more in common with "mini-waterfall". Mini-Waterfall projects assume that all (or most) requirements can be understood before designs can be created, and that coding follows each iteration or "phase".

This requires a high degree of certainty regarding the requirements. Agile assumes that all of the requirements are not knowable until a working version of the system is created.

Time boxing vs Feature fixing

Agile tends to be "time boxed" (using the Iron Triangle metaphor of time/features/cost). Waterfall tends to be more "feature fixed."

Problems with delivering mini-waterfall

The problem with delivering "mini-waterfall" to the client is that generally they don't get what they want. After they take a look at the working software, they realize only too late that what they said they put in the requirements document wasn't what they meant to say.

Client may change requirements once they've seen working software

This happens all the time, be prepared to make changes in your later phases to cater for changes in requirements. This may change how you approach designing your framework if you're expecting changes in your requirements.

Some advice to make this more agile

• http://simpleprogrammer.com/2010/04/07/dont-go-chasing-waterfalls-mini-waterfall-vs-agile/

If you want to stop thinking mini-waterfall and start thinking Agile…

stop thinking about building software serially, and start thinking about doing it in parallel. Stop thinking in terms of:

* Step 1: Get the requirements
* Step 2: Design the solution
* Step 3: Develop the solution
* Step 4: Test

Start thinking in terms of:

* Step 1: Figure out the first thing the user wants
* Step 2: Build a small piece, making sure it is right
* Step 3: Check with the user to see how to make it better
* Step 4: Continue until user is happy

Answer 3

A product requirements document was created before starting development. And then you build the project using Scrum and Sprints.

It is an iterative and incremental development and not really agile.

Quite a few of so called scrum projects have a requirements document (PRD) written first and also UI design done upfront, though they do not have rigid requirements.

At minimum for Agile, in addition to what you are doing, in sprint end demo Product owner, customers and team should give feedback and PO should have ability to change requirements based on that feedback. Additionally, team should be self organizing.

Answer 4

No. This is not Scrum, nor is it Agile. Specifically:

The requirements are rigid and do not change.

Scrum is designed to make it easy to change the requirements. You may have a Scrum project where the requirements happen to remain unchanged, but you can't go into a Scrum project with the restriction that they cannot change.

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

This wouldn't be possible in a real Scrum project.

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

This is a problem if the issue of "who manages who" gets in the way of team synergy. The fact that it's mentioned here is probably an indication that this is happening.

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

One of the fundamental rules of Scrum is that anyone can add anything to the backlog at any time. The backlog is a fluid, living thing that represents the evolving knowledge of the people involved in the project.

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

This is a massive red flag that this isn't Scrum. The PO is the one person in the organization with OWNERSHIP of the product. He can make all decisions about the deliverables of the project. If he can't, then you've got the wrong person in the PO role.

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

This is the biggest issue. In Scrum, the PO get's to decide what the relative priorities of the items in the backlog are, the Team has the sole right provide estimates and decide how many items will be worked on in each Sprint. No one is allowed to tell the Team how many items will be in the Sprint.

This feels like incremental development, but it's not iterative. Iterative implies that you re-evaluate the project, feature set, requirements, design and delivery schedule at the beginning of each iteration - putting it in front of the customer and working what you've learned back into the project.