We follow Scrum for software development in our organization. Although we have fair experience with Scrum, we stop short of producing good source code at the end of the day. People are talking about combining Extreme Programming (XP) with Scrum to produce predictable results.
I have gone through the Extreme Programming materials but couldn't get a good picture.
How are Scrum and Extreme Programming are used in software development?
Inspect and Adapt.
No Silver Bullet
There is no magic serum to make teams successful just because they're using Scrum/XP/Agile et.all ; Find your bottlenecks and eliminate them one at a time
Update: Some feel my answer isn't helpful enough. I claim 'agile scars' have left me this way - (Put on my helpful hat) Maybe you should read Scrum and XP from the trenches
Scrum is the Agile process for project management, and so it doesn't have an impact on code quality other than its tight focus on always having a potential deliverable system at the end of each 2-4 week "sprint". By keeping sprints short and getting daily feedback, the project manager gets a much better sense of how much effort new features take to implement, and the team gets a good feel for the relative importance of each new feature.
You still have to do the hard work of programming. There are many great books on this (such as McConnell's Code Complete, and Hunt and Thomas's The Pragmatic Programmer) and you should study them carefully and apply them to your work.
Both The Pragmatic Programmer (as mentioned by Jim Ferrans) and Clean Code are excellent resources for the agile programmer. You may also want to take a look at the books in the extreme programming series.
Scrum has nothing to say about programming.
In my opinion you can not be 'agile' without the software engineering practices that allow you, at a technical level, to respond quickly to change: incremental design, unit and acceptance testing, refactoring, continuous integration, collective code ownership.
This is on top of all the other things that are needed, such as a high level of involvement from your customers and effective communication within the team and out.
Along with the other books mentioned here, The Art of Agile Development by James Shore and Shane Warden is the best book on agile software development out there.
[edit] Some links to sources other people have mentioned here:
Scrum and XP from the Trenches by Henrik Kniberg (great presentation on infoq.com)
Each individual developer, his/her style, skills, and desire to always soak in new information have as much to do with the quality of the code and success of the final product as the development process.
If you don't have the right people, no PM technique will help you. Find the right people first, people that can produce good code separately, and only then worry about combining them in a team effort. One individual can undermine the whole team's effort.
On a side note, one thing I hate about SCRUM is the daily standup meeting. Yarrr.
In addition to agile/scrum, I recommend the following (some ideas must be implemented by management... so good luck):
Krish, what is your position? a team manager? I found that the best thing to do as a Scrum team leader is to place a problem before the team and let the team come up with a solution. For example, we were always off target at the end of the sprint. So, in one post sprint review, I placed the question "give me the number of hours that represents the capacity of our team for the sprint". There were three results:
We are using software tools (OnTime in our case) to keep track of all important measures and debate our statistics after each sprint. Also, we have a practice of changing at least one thing in each sprint.
Hope this helps, please feel free to ask for more
Matej
SCRUM practices are suitable for collobaration and prioritization with the product owner. However, by itself, SCRUM will not eanable sustainable pace by the development team.
The XP focus is on engineering practices Practices such as test driven development (TDD), shared code base, simple & evolutionay design, paired programming, automated testing, continuous integration, technical debt etc.
Of all the engineering practices, TDD is hardest to learn and in general, the engineering practices have a higher learning curve than the management (SCRUM) practices. However, without the engineering practices the code will come to a point where you will not be able to maintain velocity. The reasons being is the code will take to longer and longer to test and become to fragile to change.
If you are going to take on the engineering practices, it is best to embed into the team a technical or engineering coach. The coach would provide intro training for each practices and through pairing quickly propogate the practices through the team.
SCRUM and XP are a great match. Some research shows that combining SCRUM and XP results in the most effective agile teams. Given that each focus is distinct yet complementary, you will be wise to use both SCRUM and XP on any of your agile teams.
Scrum is an agile project management methodology. It does not address the practices required to create "goods" of any kind, but instead gives us the process that will take us from the inception of a vision to the final product, regardless of the actual development process. The Scrum process doesn't tell you how to create quality. It shows you what the quality is, where your problems are, and challenges you to fix them.
Extreme programing is an agile software development methodology. It gives us a process with which to create software in an agile and productive way. It deals with, though doesn't specialize in the management of the development process, and focuses mostly on the engineering practices required to deliver software, with quality.
When adopting Scrum for the purpose of software development, the engineering practices are imported from an agile software development practices, most often from XP. These practices, are those that can be adopted in a manner that is decoupled from the rest of the development practices. Most often, these practices are: Test-Driven Development, Refactoring, & Pair Programming, and User Stories, though by no means are these required in Scrum, or the only way to do things (just highly recommended). Agile Modeling is another common source of agile engineering practices.
So in short, when mixing Scrum and XP, which is by far the most common mix, you use all of Scrum's management artifacts, e.g. Sprints, daily Scrums, retrospectives, burn down charts, and so on, and add XP's TDD, refactoring, pair-programming and JIT design via User Stories.
Of course, Scrum being Scrum, this is how you start, and you constantly adapt (refactor, if you will) the process to answer your organization's specific needs.
You are writing bad code because:
I'm not sure any of these have to do with Agile/Scrum.
What do you mean 'good code'? Why is good code important? Are you talking about maintainability - does this need good code or good documentation? Are you talking about reliability - does this need good code or good tests and documented requirements? Etc
Use common sense, establish rational systems of criteria and assessments, try to ignore unsubstantiated claims of success attributed to some technique or tool.
Have a look at this matrix of good practices comparing SCRUM and XP made by James Shore. By the way I found his book quite usefull if you want to understand XP. There are also some articles that may give you an idea of some of thouse practices.