Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
If one does use Scrum for the Software development portion of a project, does one still use PMBOK or some other project management methodology for the "other" tasks on a project e.g. the business, marketing, training tasks. What is the project management of non software development tasks referred to i.e. traditional project management?
A project is defined in the PMBOK as being something of fixed scope, duration and budget. Failure of the project is defined as breaking outside one of the three sides of this "iron triangle". Scrum is a set of principles, and a few concrete practices, for dealing with all sorts of knowledge work, based on Agile values, and is specifically designed for development efforts that may not be projects, or may have flexible scope, duration or budget.
You are right that Scrum only deals with a few aspects of the software development process, such as planning. It only defines a few roles, meetings and artifacts, this is to keep it as flexible as possible. Scrum can, and should, address parts of the value stream outside of the software development itself. However, as you mentioned, it does not deal with lots of things, such as software engineering practices, and analysing the business case.
Often the standard Scrum solution is to "let the team decide" on matters that are not directly specified by Scrum. Often the guidelines for dealing with such matters come from other cultures and value or principle-systems within the Agile world, such as XP, or lean software development. Other cultures providing useful stuff for Scrum teams include Real Options, the Incremental Funding Method, Evo.
Some of the PMBOK stuff can be useful to a "project manager" or PO on a Scrum team, however one has to be cautious as the PMBOK stuff implies a rather different value-system than that which Scrum is based on. It is usually best to look for solutions within the Agile culture. Some of the PMBOK stuff still applies in an agile context though.
If you look for mailing lists related to "agile project management" you will find many thriving communities discussing such topics.
Agile development and PMBOK should not be mixed. IF you do, you're likely to end up with Scrummerfall. I've seen this happen with traditional project managers who convert to agile. They just don't get it and seem to fall back to old patterns.
However, in my opinion SCRUM doesn't cover all you need for project management. It sort of lacks an overall strategy to rule by. One possibility is combining SCRUM with EVO project/value management or other value management methods. It will however require a different type of legal contract with the customer. Projects are then more like a continuous process that is time boxed, restrained by a budget or ends when the customer feels he gains less than his investment (using business cases and goal measures). An added benefit is that the customer will see you more as a long term partner than a short term supplier.
We have expanded scrum to other departments in the company, modeling, texture and animation artist. We had to adapt the method a little, but it does work nicely. We had problems that were solved by using agile methodology. Some smaller departments (audio, special effects) were already working fine so we didn't tried to fix what wasn't broken. Agile would have added an unnecessary overhead for them.
It is not necessary for all departments in a company to use the same methodology, the best is to be adapted for everyones' needs. But scrum can be the solution for people other than programmers, but may need a bit of adaptation. Daily stand-up, sprints, backlog, those can be a good thing for many types of jobs.
If your software development effort is just one facet of a larger project--for example, rolling out a new financial product--then sure, you will have to employ some kind of project management methodology to orchestrate all of the work involved. Fitting a Scrum-based software development effort into a project managed according to PMBOK principles can be challenging, however, since PMBOK prescribes a linear, phased approach to project execution whereas Scrum, like other Agile methodologies, promotes incremental improvement through iteration. That's not to say that the two can't coexist. Like everything else, it comes down to implementation. Just remember to be pragmatic and adapt the methodologies to your needs, not the other way around.
Scrum is NOT a software development method but a project management method.
Besides Scrum is often introduced with Lego, or other artefacts (search for "59 minutes Scrum").
Therefore it can be used to handle all of the tasks of a project, whatever their natures.
While learning about these techniques is great, can I suggest your main focus is actually on running the project and getting stuff done?
EDIT: that's a serious point by the way, not a throwaway quip.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am preparing a presentation. My topic is innovative software engineering methodologies. Agile is modern and innovative methodology but is the answer just Agile? What are the other innovative and modern methodologies? Are test driven development and behavior driven development also innovative methodologies? And eXtreme Programming is traditional methodology like waterfall?
I am not sure we can categorize these methodologies or frameworks as innovative, traditional or something else.
The choosing for a methodology or framework is completely depend on the product and customer needs. Any of them that meet the product requirements and provide efficiency to your team can be innovative in that scope.
Most of the software development process is developing complex products in complex environments in today's development World. I totally agree that agile methodologies, extreme programming, TDD and BDD are matches very well to the before definition of developing complex products in complex environment. Therefore, most of the agile methodologies are inspection of developing complex products.
Agile methodologies
The term agile is a really popular term used by software development professionals. There are lots of agile methodologies, frameworks like scrum, kanban or XP. They suggest methods to use to make us agile. The term agile is all covers these methods. Most of them solves the prediction, adaptation, transparency, inspection and empirical processes. All agile methodologies try to solve these problems faces during software development.
Extreme Programming
Extreme programming focuses on developing qualified software products and adopting to changing requirements and environment. Honestly, I really like XP. It does not suggest only development methodologies. It also suggests some about customer management, cost management etc. It is really basic, but hard to implement. I highly suggest to read the book Extreme Programming Explained by Kent Beck.
See Also :
Extreme Programming
Extreme Programming Explained, by Kent Beck
Scrum
Scrum is another framework for software development based on empirical process control: transparency, inspection, and adaptation. It is really simple and defines some role and event during software development. The roles are Scrum Master, Product Owner and Development team. The events are Sprint Planing, Daily Scrum, Sprint review and Sprint Retrospective. I suggest to read Scrum guide for further information.
See Also
Scrum Guide
Test Driven Development
Test driven development is a software development process. I can not say that it is an agile methodology itself. It helps software development to be agile. Test driven development support developers to test in the first phase. Test driven development also requires a mind set to think test before every development. It is not only writing unit test.
See also
Test-driven development
Test-driven development by Martin Fowler
Test Driven Development: By Example, Kent Beck
Behavior-driven development
It is another software development process and emerged from test driven development. It focuses on the cross team like development, management and customer have shared tools and shared processes to have the same understanding of the requirements. BDD suggest that business people, customer and technical teams should have same understanding for the product. Customer requirements, lets sat customer sentences, can be automatically tested by the tools.
See also
Behavior-driven development
10 Tips for Writing Good User Stories
Cucumber.io
Summary
The term Agile itself is missing without XP, Scrum, Kanban or any other methodology or framework. Any agile methodology or framework is also missing without TDD, BDD or Continuous integration. Any of these items must be supported by company culture, customer or business people. Every stakeholder in the project should have the mindset for product over project. Otherwise, Agile methodologies may not be helpful.
As a last word, I highly suggest to get well understanding of continuous integration.
See also
Continious Integration
Products over projects
The Clean Coder: A Code of Conduct for Professional Programmers
I think you are mixing up practises, methodologies and philosophy.
For finding new innovative software development methods you could look at the big tech companies and how they are doing it.
Let's take Facebook, they practise "The hacker way" as described in Erik Meijer's GOTO 2015 video. According to Erik its not Agile. It has a focus on making code, not talking a lot about code as in most Agile frameworks.
If you look at Spotify they have their own home-grown scaling "Agile" implementation. Looks really fun, see the Spotify engineering culture video's.
But are they really innovative? or is it just evolution of the cycle?
The things you name are not at all innovate anymore. Most are more then 10 years old. They are tried and tested concepts, some love them, some hate them, but innovative hell no.
In the end software development is a process where there is not a one size fits all solution. This because coding is a creative process, which is hard to standardise. Each company and product needs to find their own path.
"Agile" is a term coined in 2001 by a bunch of people who got together to work out why their projects tended to succeed (or fail fast) where other projects failed (sometimes expensively).
The Agile Manifesto came out of that meeting. You can see the list of people underneath. There are a bunch of people who are associated with principles, methods and practices that are all considered "Agile": Scrum, Crystal, XP, TDD, etc.
So "Agile" is an umbrella term for a bunch of stuff that follows the main values and principles.
The word "methodology" has a large number of vague meanings, so I'm going to take it back to its origins to. It comes from "method" and "ology".
From etymonline.com, the etymology includes:
Method: regular, systematic treatment... way of teaching or going... scientific inquiry... investigation... pursuit, a following after... a traveling, way... way of doing anything.
-ology: branch of knowledge, science
-logy: a speaking, discourse, treatise, doctrine, theory, science... the character or deportment of one who speaks or treats of (a certain subject)
So the "Agile Methodology" is an umbrella term for a bunch of values, principles, practices and ideas for how to do software development better; the teaching of those ideas; the following of those ideas; and the people who encompass that community.
I'll quickly go through the things you've mentioned so you can see how they're all part of Agile:
Test-Driven Development: part of XP originating with Kent Beck, popularized by other signatories too like Brian Marick who created JUnit
Behaviour-Driven Development: originated with Dan North, basically TDD without the word "test", except that's more profound than it sounds. Certainly derivative of Agile methods.
eXtreme Programming: Also Kent Beck, introduced TDD, definitely Agile.
Waterfall: typified by trying to get everything right up front, definitely not Agile.
However, there are a bunch of things which are emerging which come from other disciplines. A lot of the Lean body of knowledge, originating from Lean Manufacturing in Toyota, especially with respect to Deming's work, is starting to play into the space. So you get things like:
Lean Startup - ideas validated quickly through prototypes and experiments that might not be viable long-term, but which allow for immediate survival or profit
Lean UX - focused on continual UI improvement in collaboration with development team rather than requirements capture and analysis
Lean Product Development - Toyota's method for designing new cars applied to the software space, including set-based concurrent engineering, etc.
Kanban for Software Development - management methods that balance demand and capacity, also based on ideas originating from Toyota.
There's also a whole ton of other knowledge and ideas which are probably outside the scope of what you're looking for, so I'm going to just throw out the terms to raise awareness.
Product Development: Impact Mapping, Story Mapping, Example Mapping, A/B testing
Technical flow: DevOps, Continuous Integration, Continuous Deployment
People and Psychology: Dan Pink's "Drive", Cynefin, Neurodiversity, Social Capital
Scaled Agile methods: Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD)
Strategy: Lean Canvas, Enterprise Services Planning (ESP), Simon Wardley's Strategy Maps.
Some of the terms here really are emergent and will probably change; these lists are definitely not complete. Mostly I've included them to give you an idea of the scope of where Agile started, how wide the community is and where it's going.
I think in the future it won't be called Agile any more, and it's going to end up including the whole business, not just IT, which IMO is a fantastic thing. It's already started to increase collaboration across the world, beyond the borders of businesses, and that's the next step.
I would love it if your presentation ended with that as a note.
Hi #Yusuf as I mostly worked on agile and prototyping method while developing application. In my opinion prototyping is the most innovative way of applying software engineering practices since the client and the other stackholders are free to suggest any model and that model can be used to develop the prototype. And it goes on until the stack-holder get the desired software. Moreover I like and learn from the answer of #erencan
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I've been working on a CodeIgniter project with a friend of mine for almost a year now. We feel that our development process isn't as effective as we wanted to be, and currently we're not employing any software development methodologies. We're 2 man team, looking to have more people to work with us in the future, but we don't have enough people to start on scrum.
Right now, we're both working on this project on the side, would be nice to know which methodologies are best for us, to get our development going faster and more efficient.
Agile and Scrum won't make you faster or more efficient:
Since you tagged this with agile and scrum, I thought I'd mention this: neither agile nor Scrum has as its goal faster or more efficient development as you ask for in your question. In fact, changing to these approaches involves a significant learning curve, but if practiced well contributes toward very low defect rates, software that meets the customer's needs, and a development process that responds to changing requirements. Used long enough, Scrum can provide good data about roughly how much work a specific team can get done in a period of time.
Still, you might benefit from some practices:
All that said, there are a couple practices that may want to try:
Pair Programming and Test Driven Design (TDD)
Continuous Integration
TDD is not easy to learn, especially on your own. See if you can attend a CodeRetreat or similar event.
If you aren't already using a modern software change management tool (SCM) like Mercurial, git, or subversion, get one and learn how to use it.
Get regular feedback from "customer"
If you don't already know (you didn't say in your post), you might ask yourself who you are making the software for. Can you frequently and regularly demo it to that person and get feedback? Find out what they want next and put those items at the top of the backlog.
Try to make your product incrementally useful
Rather than making big product-wide changes, add small useful amounts of functionality. Your design will drift but if you have sufficient automated tests in place you can refactor as needed.
I'm curious why you say you don't have enough to do some form of scrum?
You're both on the team, one of you can own the process and the other or both of you can be the product owner. You do your daily scrum so you can know what each of you are doing - picking the work from the backlog you agreed to do. And as you add members you'll already have an established practice they can integrate into.
You can work in 2-4 week sprints, do sprint planning,review, and retrospective regardless of the number of members.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Is PMBOK more for after implementing software is built, delivering it to the customer while Agile or Scrum is more for building the software in the first place? Just trying to understand.
Thank you.
EDIT: My main concern is the PMBOK. They use it a lot where I work but not for development (they implement with it.) They don't develop a lot and so I have no way of asking, "Hey, what do you use for development?" I have to come up with the best plan on my own. I really don't care a whole lot about being PMP certified but if that's the best way to go to develop software using PMBOK I can justify learning it. If scrum or agile is the best way, then I'd rather use that and be successful than have a pmp by my name.
Well I can answer this question from my real world experience being both a PMP certified implementer of enterprise software solutions as well as an experienced Agile PM having managed a team of 14 in a Hybrid Agile software development project.
When implementing COTS (commercial off the shelf) software I find that the PMBOK can be followed quite closely. If followed to a "T" the PMBOK will steer you down the path of a "Waterfall" methodology. If you are not familiar with Waterfall, this is the approach where most of your project time is spent early in the project gathering requirements, performing design, estimating, etc. Build or development comes much later in the process. The reason this approach works well for software implementations is because the customer generally wants to know the cost upfront for the project. The only real accurate way to determine the project cost is to follow the waterfall approach...at least initially.
The Agile/Scrum methodologies work much better for building software. When I say build I mean the entire build process from design, development, testing, etc. I won't go into the differences between what is covered in the PMBOK, Waterfall or Agile methodologies as that is not what you asked. Agile is very much about iterative design & build, and less up-front design. In agile you want to iterate quick, and perform JIT (just-in-time) requirements gathering (using storing), design, build and testing (TDD). This reduces the amount of waste and produces usable software earlier in the project. Agile has many benefits to software development projects.
Now what I have found helpful is taking the waterfall approach as far as you need to build an accurate estimate and resource plan. Once that is complete you can switch in more of the agile processes to finish off your project.
Remember not to confuse the PMBOK with an methodology. PMBOK is a set of industry standard processes that can be followed to deliver a project; not just a software project, it could be engineering, municipal planning, etc. There are many parts of the PMBOk that are beneficial in the software development world such as: communication planning, risk planning, project close-off, etc.
It's a pretty broad subject so I hope this helps you make the appropriate decision for your project. Remember one size does not fit all.
I would personally suggest understanding Scrum and/or Agile ( whichever suits your organization best) before jumping into PMBOK.. The standards in PMBOK are more conventional and the phases are described in a slightly pseudo- waterfall method which is not as acceptable in IT industry now as before Agile and Scrum knocked at our doors... If you study PMBOK after knowing about Scrum, then its easier to filter out whats not relevant and get a better understanding of both concepts overall..
Both PMBOK and Scrum/Agile are for engineering as well as Implementation.. PMBOK covers areas other than the IT industry, that's all!
Also, Scrum is something anyone or everyone in a project team learns and implements.. but PMBOK is primarily for a Project Manager...
PMBOK is just a naff industry standard used to give the management in organization A who don't know any better the (false) peace of mind that organization B is doing things in the 'correct' PMI certified way.
Scrum as Pedro said is an agile project management technique that revolves around working in fixed iterations which is highly regarded by most software professionals. Although Scrum doesn't prescribe any engineering techniques it is commonly used in conjunction with the engineering techniques outlined in XP (Extreme Programming) such as pair programming and continuous integration.
For business reasons some companies have to at least appear to follow PMI, CMMI or ISO in order to win work, but in reality most serious software shops are practicing agile techniques such as scrum/xp/kanban behind the scenes.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
We have a four person development team that is in need of a formalized project management system. I have a general understanding of Scrum and Kanban but it's hard to truly understand until it's been tried. We don't have the luxury of trying one for a few weeks and then switching to another so I was hoping that someone out there in a similar situation might have thoughts on which worked better for them and why. Also, any other systems for managing development that worked would be great to hear about.
Another note: there's the possibility of the team growing, of course, so we would need a system that scaled well.
Yet another note: We work on three separate software applications in Windows all of which are based on a central library which we also wrote (so i guess you could say four projects)
Both Scrum and Kanban are really process "skeletons". Neither is specific to software development. Scrum was popularised by software development organisations but is positioned as general management technique rather than a software project management technique. Kanban emerged from manufacturing and has been adapted to software development, initially by maintenance teams. Both Scrum and Kanban aim to manage the flow of units of work through the team that is doing that work, measure how fast work flows so that estimates can be made more and more accurately, and make bottlenecks highly visible so that they can be addressed.
Because neither is specific to software development, teams using Scrum and Kanban add software development practices to the process to help them incrementally and iteratively release and improve the software. Most teams, whether working within a Scrum or Kanban process, adopt the technical practices of XP and reflective practices of Crystal.
XP is basically Scrum applied to a single team plus guidelines about what makes code "high quality" and how programmers can achieve that. Crystal Clear also applies to small co-located teams but is more flexible about programming practices although it also recommends the XP practices (the book describing the process is excellent and full of invaluable advice, whatever process you decide to go with). Scrum teams also usually adopt the reflective practices of Crystal: regular "heart-beat" retrospectives and larger retrospectives after every major milestone. Kanban requires continual reflection and improvement but some teams use retrospectives too.
If you want to start applying an incremental/iterative process in a small programming team, then I think XP is a good process to start with because it sets the bar pretty high for technical capability and is very well documented. How continuous-flow and Kanban best applies to different areas of the software development industry is still being debated on the kanban-dev mailing list and elsewhere.
I would recommend also performing regular retrospectives to improve the process and adapt it to your specific situation.
The most important part is to have a reflection/retrospective mechanmism in place which facilitates continuous improvement. Start with some process model and evolve it over time for your needs. Stop doing things that are not worth doing. Keep on doing things that bring in high value. Try new things that you think could be valuable or address specific problems.
I think Scrum works for small to medium team. Compared to XP it leaves out some details, so you can borrow from XP or do something that makes sense. Either methodology you pick, you have to consider the role of chickens(customers/managers/stakeholder/domain experts) role. Sometimes you have to play the roles yourself, but many agile methodologies work because there's external pace car with grounded knowledge of the domain.
Other key aspects are the communication level among your team and some form of quality assurance mechanism. It's hard to do pair programming if you are not located in the same building. Scrum tries to get a feature to acceptance within a sprint cycle, and XP tries to get the feature integrated within the day using unit tests, code review, and continuous integration.
*) Sprint can range from 15-30 days.
What is you question ? Is it which methodology would be most suitable ?
You don't get much benefit from all the overhead that a formallised system will impose with that size of team. Instead, try a good management technique to make sure everyone is listening to each other and blocks are removed.
I've worked with a team of that sice and even bigger on two teams that shared some common libraries. Scrum worked well for us. Now I work with a team with 6 members and we use XP and I think it works as well. The first team developed a product and the influences from 'the outer space' were not that big. So longer iterations worked fine. No we develop a customer project and therefore shorter release cycles are better for us.
But SCRUM and XP are more than that. Now we use TDD and Pair-Programming (both more from the XP world). We also have daily standup meetings that are more SCRUM like. So we adoped XP and SCRUM to work for our project and our situation.
I would start with short cylces (1 week) and reviews of this cycle. It will take some time to adopt a new methodology in your team but if the members are willing to learn and change it will work.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
My company has recently started using Scrum; we've done 2 sprints. We're still learning, but we've definitely exposed and fixed some problems in our development process already. So in general I think it has been good for us.
In reading many of the internet musings about Scrum from evangelists, cynics and everyone in between, three common and somewhat contradictory themes have stood out to me:
Scrum implementation fails because the processes of Scrum are not followed closely enough.
Scrum implementation fails because the organization does not adapt Scrum to its own environment/culture/practices.
The processes of Scrum are not important; only the values in the Agile Manifesto matter.
Examples of these can be seen in the responses to these SO questions:
Have you had a bad experience with Scrum or Sprinting?
Is Scrum evil?
Is Agile Development Dead?
I have to admit that we're not yet following all the guidelines of Scrum: we haven't done a release at the end of the sprints, our Scrum Master doesn't want us to move tasks out of the sprint backlog near the end of the sprint so that he can see how much our planning was off (which means the burndown chart never goes to 0), and urgent customer support issues still have incredible power to disrupt everyone's planning, for a few examples.
My question is: in trying to solve these and other issues, is it better to try and be closer to the official Scrum processes, better to be closer to some of our pre-Scrum processes, or better to meditate on the principles of Scrum to try and come up with a different process altogether?
I would say that you are really missing one of the key components of agility if you don't release early and often. To the degree that you don't do this, your process is not agile and bound to suffer the same sorts of problems that traditional, plan-driven processes have. It may be that this is a temporary condition as you are just getting used to things, but you need to start releasing soon (and regularly).
You'll always have the problem with show-stoppers, but you may be able to help this by shortening your sprint length. The customer may not be able to wait a month, but they may be able to wait 2 weeks for some things. A shorter sprint length, then, may help you to defer some requests to the next sprint making them less disruptive. You also need to be upfront with the customer that the disruptions are actually causing your pace to suffer. They may voluntarily choose to wait if they know that their chosen features are being delayed by some requests.
Another observation that I would make is that, as with almost anything, it's better to start out by following the pattern as closely as you can while you are learning. Once you have a good grasp of the fundamental principles, you can then see where some principles can be bent, broken, or replaced much more clearly to improve the process. Until you really get it, the things you change may hurt or help -- you really have no idea since you don't have the experience that tells you how things ought to be working. Unless your Scrum master is really experienced, you may want to hew closer to the defined practices until you've got a few more sprints under your belt.
Almost everything I've read on Scrum says that one of the keys is to adapt the process to fit your own situation. No two development teams are the same, and different things work for different people.
The main ideas behind Scrum are:
Have a tight feedback loop from requirements to development and back to the stakeholder(s).
This allows the development team to continually verify that they are building something that's actually wanted and allows the development to be easily adjusted as requirements and expectations change. Stakeholders can add or remove features at any point and they can adjust the priority of the features as their needs change.
Keep the software in a state where it's releasable at the end of any given sprint.
That's not to say you have releases every sprint, but that you could if the customer decides they want to have the latest stuff. This also helps a development team avoid the situation of integration hell that comes from people going off and working on a piece of the project on for months at a time in isolation.
Be completely transparent with what's going on in development and everyone needs to be willing to make tradeoffs.
This is where most projects fail and where Scrum can really succeed if everyone buys into the process. So many development projects are set up to where a release has to have X features released on Y date and no flexibility in changing that. This results in half-done features and bug ridden software as the developers cram to get in all the required features on their checklist.
The reality is, unexpected things happen in software development. With open communication and willing participants in the Scrum process, customers and developers can continually evaluate the current state of the project and make educated decisions on prioritizing the work remaining on the project.
Scrum does work. Not with all teams in all situations, but it has been shown to work.
I would suggest trying to embrace textbook Scrum as much as your business environment allows, see how that works out, and then tune it.
Why does your Scrum master not want to move tasks out of the sprint backlog? Does he not 100% embrace the principles of Scrum? (I would see that as worrying in a Scrum master)
Most problems implementing Scrum are actually just problems in the team or business being exposed by the Scrum process e.g. - if your sprints are thrown out by unforeseen support issues this suggests you are not allocating enough resource to support
Every company is different, every project is different and every client is different.
I think it's just as easy to fail by following scrum (or any other methodology) too closely in an environment that doesn't fit the methodology as it is to fail because you follow scrum too loosely in a project that does fit.
At the end some generic answer in a QA site is no replacement to serious analysis of your own project, company, team and clients - there is no magic formula and you have to make your own decision.
Answer: You need to adopt both Scrum and XP together to get the full benefits of scrum.
Reasons:
The reasons are based on years of doing XP and scrum, and specifically on what I learned from Jeff Sutherland's talk (for the ACCU in London, May 2009)
Scrum is a management technique - not necessarily a software production method. Some people use scrum in other domains e.g. preparing museum exhibitions and running religious institutions... so it has the mechanisms you need to make a multidisciplinary team deliver work adaptably in small increments.
Scrum, originally included all the extreme programming practices. Jeff Sutherland actually said that he's never seen a scrum project achieve the higher orders of productivity measured for scrum without using the extreme programming practices.
Scrum and XP both come from the same background - Object-oriented programming, specifically with Smalltalk. The programmers went off and developed XP whilst the management people created scrum. You need both aspects - development practices and management practices.
The XP practices were deliberately removed from Scrum to make it easier to adopt. - Implementing the XP practices is hard and it's difficult to get them adopted quickly. Jeff actually said that Ken Schwaber removed the XP practices to help people get started with scrum. The danger now is that this minimal scrum has become all that people see and expect.
Lots of non-technical project managers now teach scrum - but they don't have the skillset to teach XP
Not all developers find the XP practices easy to adopt - they can be hard sell and it takes a few months rather than the 2 days it takes to establish basic scrum.
Scrum doesn't attempt to address the technical issues in software development. It's just a small management process.
The strength of scrum is that it doesn't get in the way by prescribing lots of unnecessary or irrelevant technical work.
The weakness of scrum is that it doesn't tell you what good technical practices to do.
Extreme Programming does address the technical issues involved in software development and it fits very well within scrum. The reason the scrum people didn't force everyone to do the XP technical practices is that it takes about 6 months to implement those tech practices, rather than the 2 days it takes to implement the most basic scrum.
Whether or not scrum is "evil" - there are certainly drawbacks with it. We discussed the uneasy relationship between XP and Scrum at length at XP Days, London, 2009: http://xpday-london.editme.com/WhereHasXpGone
Scrum is not really the problem that you are showing. Most development methodologies work, even waterfall, as much as we like to bash it, works. Scrum does make you concentrate a little more on the important things, but it won't stop people from making bad decisions like not really following the process.
The system is pretty simple at its core.
See the problem.
Define what done is.
Create a series of tasks that will get you to done.
Estimate those tasks.
Select enough of those so that you can get something done in a short period of time.
Complete the tasks.
Rinse and repeat.
OK admittedly these steps are simplified, and I haven't thrown in a scrum master and a customer. But the point is that the framework is just a basic time management strategy. If the people in your system are chaotic and not good at getting things done then scrum really won't help them.
It's better to start applying Scrum by the book, and to really understand the underlying principles and values from the Agile manifesto, prior to customize it, so that the process does not get denatured. Be sure to run retrospectives at the end of each and every iteration (Sprint) to "inspect and adapt" your process and eliminate waste.
For your Scrum Master, he can track what is removed from the current Sprint. Also Sprints are planned based on the previous Sprints achievement, not on what was previously scheduled. I do no get its point.