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.
Related
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
How to move a team from waterfall development model to scrum model? What all are the steps that one need to follow to achieve a smooth transition. What would be the acceptance curve and will it be successful altogether?
First the team needs to want the change, and the business has to support it.
There isn't a set sequence of steps, and success can vary widely, as much depends on your particular situation.
I'd recommend getting Mike Cohn's book Succeeding with Agile, which gives some excellent advice for such a transition.
Though there are many ideas on how to implement scrum within an organization, starting with one team is certainly a consistent thread. So good work on starting that way. From there find someone with experience in implementing agile. A contractor, a colleague, or advice at meetup groups. Here's a link to one I have attended in the DC area - http://groups.google.com/group/dcnova-scrum-user-group
From there, my opinion is to adapt scrum to your team. It's size, it's need for adjustment, etc. Everyone has opinions, but if your team doesn't buy it, it's not worth it. Don't take that as a license to cut things from scrum. Keep the daily standups, the commitment, the retrospectives, the demo (etc), but adjust the size of the sprint, etc.
I recently saw a compelling presentation that advocated implementing pieces of scrum/agile as the team/business was ready. See this gentelman's site for details - http://www.dragile.com/
A big key is to not get lazy - do scrum. And have a high standard. If you're going to go it alone (which can be dangerous) - read your heart out. Read examples, talk to others, go to meetups, etc. Don't let your inexperience in scrum sour your team to it.
Another good link for an example of one team's experience implementing scrum.
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
In my experience with learning to manage a team using agile there are two critical components to making agile/scrum work. I think that Jody's point about not being lazy is really important, with the more free-flowing work pattern of agile it can be easy to succumb to skipping meetings or other such nonsense.
Get a good web based task tracker. This allows developers to login and see what they need to do and will help track progress. I've been very happy with Pivotal Tracker (www.pivotaltracker.com). Of course the tracker is only worthwhile if you actually keep it up to date, which leads me to point two.
Having meetings EVERY day. The daily standup discussed in the scrum and agile books is by far the most important aspect of the routine. Keep the meetings short, do it in the same place at the same time every day. Update the task tracker during this meeting and keep it organized.
Transitioning a team from waterfall can be difficult. Having everyone on the team read about scrum is important. Also, understand that not every aspect of the scrum model will work in your environment. Facilitate an open discussion about what aspects of the model you want to adopt as a team. The more input you get from the team the more buy-in you'll have.
How to move a team from waterfall development model to scrum model ?
Strategizing Phase:
Well, the first step off course is the thought for change. Then comes the buy-in from the Management, and the Product Development Teams.
Release Planning and Virtual Product Discovery:
Ideally, you would start by identifying all stakeholders and identifying all the requirements by using the Agile Release planning method - which is a really lean way of doing Release Planning. You would identify virtual products at this stage if not already identified.
Team Forming and Infrastructure:
Next step would be forming cross functional teams based on what virtual products need to be built. This step can be tough. It may require RE-organization. Cross functional teams mean there will be no requirements gathering team, or software development team, or QA team. You would have to pull a experienced lot of people from each department to form a cross functional team. A Scrum Master and a Product for each team will have to be appointed.
Basic infrastructure will need to be established for the cross functional teams to operate smoothly, without interruption.
Start Sprinting With Team(s):
Start following the Scrum/Agile principles and have them Sprint. Capture various artifacts and use them to inspect and adapt.
WALAH you are Agile!
What all are the steps that one need to follow to achieve a smooth transition. What would be the acceptance curve and will it be successful altogether?
Steps are mentioned above in order. Acceptance curve varies based on how well you execute the steps I mentioned above.
Lastly Yes, off course it will be successful. 100% guaranteed successful.
Kidding, I wish I could guarantee that, but I can't. :)
What I suggest is this - When you read my statement "Yes, off course it will be successful", the hope you might have got, just hold on to that hope and take that first step!
I happened to be a part of a team which was migrating from waterfall to scrum. If the teams large and distributed, I don't think its easy for everyone to migrate to scrum all at once as a change in organization takes certain amount of days/months/years.
Once such approach that you may like to try is Tracer Bullet, although this term is used more in agile world, but you can surely prove your point to get the buy-in and lead by example if you/your team is stuck in the middle of waterfall and scrum and are looking to go nowhere in quick time.
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 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.
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 9 years ago.
Improve this question
We are looking at hiring a software development project manager. His job is going to be concerned with running multiple dedicated project teams focused on delivery of software for external customers. He will also need to provide support to our business development unit and oversee post-implementations support of the aforementioned software. What level of hands on development experience should we expect from the applicants? Successful candidate is not expected to do any coding.
Not important. We should be focused on proven project management experience in software area.
None.
Some experience, exact technology does not matter.
Heavy experience, exact technology does not matter.
Some experience involving same acronyms as we use daily over here.
Heavy experience involving same acronyms as we use daily over here.
Some experience, mostly with technologies we do not use.
Heavy experience, mostly with technologies we do not use.
This question is regarding the best level and quality of required technical experience and is not concerned with any other skills and qualifications of a software project manager. Many thanks.
As with any position, you need to assess first and foremost what skills and experience you need on the team for you to be successful. Then hire to fill the gap for the skills that you do not already have on your team.
If you already have a team with strong technical and technical leadership skills then you don't need to hire someone who is likely to compete with the people you already have. If you are missing this, you probably want to hire a technical manager with some project planning and tracking skills.
Great project managers are those that are multidisciplinary - they are most successful where they can bridge the divide between the various stakeholders and team. The primary role of the project manager is to manage risk and facilitate communication and collaboration. As a minimum, you should look for someone that has proven experience in either your industry or with the technology space that you are playing in, otherwise they will be unable to gain the respect of the rest of the team and perform their primary role.
Which brings me to something else you should consider carefully - what is your culture? For example in a previous job, we had development leads that were very strong technically and wilful. Project managers were always relegated to second chair, and pretty much ended up as glorified MS Project admin. assistants. Anyone good did not stay long. What do you need to do to allow the type of skills you want to acquire for the team to flourish?
Most of our project managers have zero technical experience, so I'm guessing the skill sets are different enough that it's not necessary. However, they have to be bright enough to grasp/learn the concepts involved in development -- just not the implementation.
That's not to say that a technical background would be a bad thing -- it could be a "nice to have". Then again, it could possibly get in the way and they could try to control the implementation.
In my experience the very best technical managers I've had had very strong technical backgrounds (and usually were a little reluctant to trade herding code for herding coders). The worst were the the ones that were merely average programmers at best and had more of a management background.
The tentative conclusion I've drawn from this is that while not all programmers are management material, all good technical managers started out as good programmers.
Note that this answer is coming more from the perspective of hiring an engineering lead. For a project manager - someone whose job is to interface between the technical people and the customer - technical acuity is probably less of a requirement.
Some technical skill would be nice, but far more important is that they understand the functional area your company exists in. So if you sell an OS, then you probably want stronger technical skills than if you're writing banking software, for example.
Go with point 1. "Not important. We should be focused on proven project management experience in software area."
Edit: (after re-reading your intro-para) Seems what you want is a product-manager, and in support you need team-leaders on the diverse teams to handle and report on the technical issues. (Also since customer-contact is involved: a little marketing experience won't hurt!)
As an aside:
You are focusing on the wrong skill-set. You want proven administrative skill; proven organizational skill; and above all: proven people skills - (s)he must be able to communicate without antagonizing or patronizing the audience. The technical staff and programming staff will have all the necessary experience in development. (S)He must be able to manage and control these staff members effectitively.
The manager has to be able to communicate with developers. This either requires a decent technical background, although not necessarily with the same technology, or enough humility to know when the developers know more about something than the manager. I've seen both work well.
I think what I'm saying is that having respect for the developers is important, and there's two paths to it: understanding what they do, or understanding that you don't understand what they do.
Answer is "4".
Heavy experience with some technology is critical. I know the mindset is "project manager does not have to understand technology, he just manages people".
Well no, PM does not manage people: he manages project that is supposed to produce some deliverable that is acceptable at least across some desired aspects (capability, performance, reliability, security, maintainability, etc). If he can't understand technology, he's lost. Of course, he does not have to be an expert in peculiar technologies used in a project: but he has to be able to filter BS away, to question programmer's estimates (we know how those go), to feel at least technical risk here or there, to be able to formulate business ramifications of particular technologies.
In some ways I think that PM's challenges re technology are even bigger than those of programmer: he has to be genuinely interested in technology, yet he can't / should not have any technology bigotry, to be actually fair towards them (what they are actually good for and what they are actually not good for).
Read "In search of stupidity" for evidence how non-technical managers drove many tech companies into the ground.
This is excellent summary by Spolsky: http://www.joelonsoftware.com/articles/Stupidity.html
Now, the small print #1: not every programmer will make a good PM, of course. In short, control freaks, toxic personalities, egomaniacs, people who are good at coding but not at negotiating, people who are good at coding but yield to pressure too easily -- will FUBR their projects.
Small print #2: It might be possible that people with very good analytical skills might make up for lack of experience with technology. I've worked with people who were excellent business process and procedure designers, who instinctively understood how UI should be organized and what the software should be doing in this particular place and why and who could detect BS quickly even when served by domain experts but who could not program if their life depended on it.
Most has been answered already, but I'll add this:
Keep the same mindset that you would have when hiring an office manager. While the technology knowledge is important, you'll find that ambition, a will to learn, coupled with a team leader attitude will get you a better manager than looking at mostly technology knowledge. Most projects have some company/industry-specific skills that are involved and a quick learner / great leader will bridge that gap quickly.
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.