Understanding Agile [closed]

Closed. This question is opinion-based. It is not currently accepting answers. 开发者_如何学编程

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

Improve this question

I recently shifted to a new organization that follow Agile mode of development. The current project we are working has stalled due to many requirement changes that were reported recently. Since this is my first Agile assignment (after working in 4 years in non-agile environ), its a bit hard to differentiate where the problem really is.

Ruby on Rails is the platform that is being used for development. Since I can't ask a vague question, I will narrow it to this.

In agile, is it ok for the business team to relax and give requirements at will? (Some requirements given during the final sprints were altering the entire design of our app)

Or, its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?

---

In agile, is it ok for the business team to relax and give requirements at will? (Some requirements given during the final sprints were altering the entire design of our app)

It is OK (albeit not wise ;-)... so then an agile development team would tell them "fine guys, this would cost this amount of extra time and consequently this much schedule slippage."

• If they are willing to pay the price, all's well.
• If they decide that maybe the new feature is not that urgent after all, all is well too.
• If they insist on including the new requirements and keeping the original schedule, that project is not agile :-(

Or, its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?

I don't think the design should be ready to welcome any kind of changes and any new features - that would only lead to bloatware, and a lot of extra work which in the end proves useless.

Agile projects should have some sort of roadmap too, so that the developers have at least a rough idea where the product is supposed to be in a year's time etc. This would allow them to plan forward and extend the design to make room for probable future changes.

If business doesn't give timely information about the roadmap (or if it proves unreliable), that is (usually - barring really unforeseen market/environment changes) business' fault. If the team did not use that info wisely, it's their fault.

---

Agile doesn't mean you don't have requirements or specifications or you can be free and easy with them. The business leads need to know what they want. The benefits of being agile is that if you do need to change paths, you can do that in an easier way, so you can adapt quickly.

Requirements changing will be painful no matter what your development methodology. There still has to be a strong clear plan, at least at that point in time.

---

Agile projects are supposed to have requirements gathering, design, analysis, coding, testing; just like the waterfall development model. However, in an agile project, the phases are supposed to cover less ground and therefore, happen faster.

I agree with Péter Török's answer, but its also the responsibility of the agile team or the agile team manager to teach the business team that the project will deliver better results each round if they postpone new requirements until the next requirements phase. Since a round is supposed to be 30 - 90 days, most new requirements can wait. The few requirements that can't wait, need to have a time and schedule cost.

---

Opinion of a Scrum Master here. It sounds like the business is lacking a clear knowledge of what 'agile' is, or how they implement it. Agile needs to be applied with structure, whether that be Scrum or Kanban or something similar. Too often it is a synonym for 'we don't design or document' things.

If you are meaning a team using Scrum, this would be manageable as long as the Product Owner and Scrum Master are on top of their game.

If the business team are giving requirements 'at will' that do not align, it is up to the Product Owner to take these on board, and prioritise a list of tasks prior to sprint planning. If they don't align with what has already been done, they may be estimated as large stories, due to the need for refactoring etc. by the team. It will then be up to the Product Owner to decide if it is worth proceeding with them despite the size, or working on alternative stories that align with work already done.

This would be a tough environment for the whole Scrum team to work in, but you would expect the business to see the lost value by changing direction between sprints, and hopefully align the product to a direction before too long. It certainly is not the development teams fault for not anticipating this, I would more say the Scrum Master and Product Owner need to have some serious words with the business units involved.

---

There needs to be a buffer between the sprint and the backlog.

The Business Team own the backlog and the prioritisation of the stories in the backlog but once the Dev team have committed to x number of stories in the sprint then it is unwise for the business team to tinker with its content. If you find this happens I would suggest shortening the length of the sprints.

If however a super urgent new requirement comes up that just cannot wait for the next sprint then another story/stories of similar points value have to be removed.

It is important that the business team manage their backlog so that in the sprint planning meeting the next set of stories are fully specked, prioritised and ready to go.

---

In agile, is it ok for the business team to relax and give requirements at will?

Yes, it's ok to change requirements (maybe not relax), but in our teams we will not disrupt or change the scope of the sprint unless the work currently in scope of the sprint is made redundant as a result of the new requirements added to the product backlog by the product owner (not the sprint backlog). Also note that if you commit to 100 points worth of work in a sprint, you complete 80 points and the the requirements change enough for the sprint to be disrupted then the team has still delivered 80 points that sprint based on the POs original requirements. (important when dealing with external clients)

its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?

We have a very high-level understanding of the overall features/project being worked on, however before we accept User Stories (broken downs chunks of the feature/project) we ensure that we fully understand what the Product Owner wants. If the product owner is unsure then we will ask the person whom does know. Note I am not saying that you plan out the whole project, you only nail down 1 or 2 sprints worth of user stories.

(This is how I do it, but there is no prescriptive rules, every agile rule make Agile less Agile - My opinion)

---

No, it is not ok to give requirements at will.

There is a general notion that business and development work together on daily basis and do that not primary in written form, but as well face to face (often to review or plan stuff). The idea is not to make too much assumptions on the future, but some and go with these.

Having done this as a coder, the only advice I can give: Setup for change. As you learn about your framework, the product side learns about the business. If you run into problems like these: Its actually important that you fix this problem. This is what you have sprints for: Fail at something and then fix it after a retro. Doing this for a while should lead to a sane organized process how to get all the requirements at the right moment.

However: Proper engineering has hurt no-one yet as well as proper security and requirements engineering. If you need to do this despite your agile process: so be it.