1 Provide the difference between an Agile Scrum Development

1. Provide the difference between an Agile & Scrum Development Structure.

2. Please create a SWOT Analysis for an Agile Development & a Scrum Development

Solution

1. The difference between an agile & Scrum Development structure are

-> In the SCRUM methodology a sprint is the basic unit of development. Each sprint starts with a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made. A Sprint ends with a review or retrospective meeting where the progress is reviewed and lessons for the next sprint are identified. During each sprint, the team creates finished portions of a product.

-> In the Agile methods each iteration involves a team working through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders.

-> Agile and Scrum are terms used in project management. The Agile methodology employs incremental and iterative work beats that are also called sprints. Scrum, on the other hand is the type of agile approach that is used in software development.

-> Agile is the practice and Scrum is the process to following this practice same as eXtreme Programming (XP) and Kanban are the alternative process to following Agile development practice.

2. The SWOT Analysis for Agile development and a Scrum Development are:

Strengths:

Agile development is well suited for custom projects where there are a variety of unknowns. Particularly when working with black box situations where the client does not have full working knowledge of the technology. In these cases, you don\'t want to set hard development timelines because, well, it will happen and happen hard. The daily scrum session will allow you to identify the problems, prioritize the piles, and get sprinting again once you\'ve scraped enough off.

Weaknesses:

Project scope can get way out of hand - and quickly - once the problems start presenting. You need a solid PM to be able to coordinate the development tasks and to keep the main objective in sight. When going rapid, it\'ll be harder to keep the client from asking for fixes to problems that you didn\'t create, or you may have to cross off some of your original assumptions about what should be done in order to better or more efficiently get the bulk of the project completed. Ideally, you\'ll want a PM on the client\'s side as well who understands what\'s going on from the get-go, and can be relied upon to communicate these kinds of decisions to their people. If one side can\'t keep moving, the wheels can come off completely. This is always a threat when dealing with bureaucracies...

Opportunities:

Agile requires programmers to speak up and identify the landmines that they\'re in the best position to see. This is usually a good thing, and a bonus is that they get a mini-camp on running their own project. If all goes well, the development goes faster with agile, and your team is more able to adapt to ongoing problems. Working and resolving crises with the client during agile development tends to promote stronger relationships (read: repeat business). It\'s never boring.

Threats:

Again, getting lost in the details and being sidetracked by derails is a big threat. If you can\'t adapt quickly to situations and keep making incremental forward progress (personality or ideology conflicts within the team won\'t help), you risk the project spiralling out of scope, time, and budget. If key people leave the project (something that happens in gov projects... a lot), that\'s a big setback, moreso than if the project had fixed and measurable objectives. And if your team doesn\'t deliver, it\'s gonna look like a huge bust... because now you\'ve gotta patch things up just to make it work again, and it looks like there\'s all kinds of extra parts lying around, threatening to start a fire.