What is the difference between situational analysis and a SWOT analysis?

What is the SWOT analysis on SCRUM (Agile Software Development)?

• Project Managers (PM) selected the SCRUM management and software development methodology to build-out and implement a customized a bolt-on application for SAP.If you are experienced with SCRUM, what is the 411 for a SWOT analysis on SCRUM (Agile Software Development)? Context I work as a contractor for an Agency of the Federal Govt. A project that my team of Change Managers (CM) is slated to work on is ramping up with the Change Management (CMnt) kickoff meeting scheduled at the end of the month. The Agency's Project Management (PM) selected SCRUM software development methodology to customize a bolt-on application for SAP. I am excited to learn the SCRUM approach to project management and software development. Here's the rub. CMs like to know everything and don't like surprises or unnecessary risks. You might notice the irony in that CMs don't like change...you'd be right. We earn our paychecks by minimizing or mitigation surprises or risks. So, I need inside information from SCRUM-savvy PMs, programmers and/or CMs to give us the 411 on the: Strengths Weaknesses Opportunities Threats (SWOT) analysis that SCRUM neophytes should expect to encounter as the project moves through implementation to flipping the switch at Transition. And, I am personally curious about CMnt activities between the Sprint events, what those CM activities look like, and how we can tie them into the next set of Sprint events. How about a road map from those who've been there?

• Answer:

  Well, I'm a PM and I've worked federal projects, and my company does use agile development methodology. But I've never done all three at once, know what I mean? From what I've read on SCRUM, though, and just simple past experience I can say the following: 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, shit will happen and happen hard. The daily scrum session will allow you to identify the shit, 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. Hope that helps. It's totally off the top of my head though, so please don't treat this like some kind of exhaustive, certified treatise on the subject. In fact, please treat this like something I jotted down on a napkin over several rounds of beer. Better to go with the links off the http://en.wikipedia.org/wiki/Scrum_(in_management) for actual roadmaps and detailed suggestions. Anyways, the key will always be how good your team is, what kind of relationship you can establish with the client, and making sure everyone knows what the hell is about to happen (buy-in on all levels). Because in all likelihood, with agile, things will look totally fubar most of the time, with outstanding tasks all willy nilly; but a good PM will reign everything in at the right times (milestones) to meet the objectives and keep everyone smiling. Good luck.