So... methodologies. In my opinion, the biggest difference between Scrum and XP is in their prescriptions. Methodologies prescribe things, meaning they have sets of rules about things that you must follow in order to declare that you're adhering (cohering?) to the methodology.
ScrumScrum prescribes three things: roles, ceremonies, and artifacts. Roles include Product Owner, ScrumMaster, and Scrum Team. Ceremonies (meetings) are Iteration Planning, Daily Scrum, Review, and Retrospective. Artifacts include Backlogs, Burndowns, and (most importantly) Working Software. Wikipedia has a decent overview of the software development life cycle using Scrum.
I spend a good deal of time talking about Product Owners, Backlogs, and Working Software during this part of the lecture. It's important that the students understand the Product Owner role so that they know how to manage expectations -- both their own and those of the client sponsor that is filling the role. I also remind them that they have another Product Owner in the class instructor (see the Principles lecture notes).
Backlogs are important to the students because they will become communication tools as well as information radiators. Working with the instructor and with their client sponsor to elaborate and prioritize stories makes the project more visceral and manageable for them. Also knowing that you don't have to keep the entire project in your head all at once is relieving -- you only need a lot of information about the stories near the top of the backlog.
Working software is the most important thing the students can produce as a result of their efforts. I remind them that in order for it to be declared "working" it ought to be in the client's production environment. It can't be working on their laptop only unless they intend to give their laptop to the client and help the client wire the laptop into their production environment. Most of the students look at me like I'm crazy at this statement, and I'm glad they realize the absurdity of the scenario. :-D
eXtreme Programming (XP)XP prescribes practices. In fact, it prescribes lots of practices, but I generally only mention 4: test driven development, pair programming, continuous integration, and collective code ownership. Again, have a look at handy dandy Wikipedia for decent overviews on the definition of each.
I typically only spend a couple of sentences on each of the above four practices. The main reason for this is that software development as a craft is not the focus of this class -- project management is. However, I make easy suggestions around TDD and pairing to make sure the students understand that these practices can help them make decisions, keep moving forward, and increase their code quality without a lot of effort.
The final point I leave them with is that they are very likely to encounter prescriptions from both of these methodologies being enacted at the same time without giving credit to each other. There are a lot of high-functional cross-functional project teams that are gathering around an iteration backlog everyday to answer three questions that then break off to pair program using test-driven development so they can commit code to a continuous integration server that don't realize the last three things I said having NOTHING AT ALL TO DO WITH SCRUM. Those are, in fact, XP practices that the team has adopted. If they happen to get into a Scrum team in the wild that is not doing those practices, they have an immediate opportunity to improve the team by suggesting them. :-)
Post a Comment
Note: Only a member of this blog may post a comment.