The next stop on the Magical Methodology Tour is Scrum. In contrast to XP,
Scrum is a top-down methodology, detailing more about how the project is managed. The development effort is broken up into 4-week units called Sprints, with a Sprint Goal - a short summary of the desired end result of the Sprint, as defined by the Product Owner, who is the person in charge of definied the product and priorities of features. Each Sprint is managed by a ScrumMaster, whose job is to keep an eye on the development, and remove any roadblocks the team encounters, and to hold the short Daily Scrum meeting, in which the team recounts the previous day's work, the planned day's work, and any roadblocks they face. The list of tasks to be done for the current Scrum is called the Scrum Backlog, and is set during the Sprint Planning Meeting, held at the start of the Sprint, where the highest priority remaining tasks in the Product Backlog are moved to the new Sprint Backlog. The ideal goal of every Sprint is a working version of the product, with each Sprint adding more functionality until a complete product results.
Now, as to the details:
Scrum is a lot less specific than XP, with fewer required practices, and a lot more freedom in the development techniques. It also is much more palatable to management in that it requires few changes to the actual development process - programmers still write code the same way, and the Product Owner role maps well to the common Product/Project Manager position in many companies. Priorities are still set by management. The most likely difficulties arise in the ScrumMaster's role - removing obstacles. This is not an easy job, nor one for a first-line manager - it requires authority beyond the usual bounds. The ScrumMaster must be allowed to prevent developers from being pulled into other projects, or redirected to support. And this is the big stumbling block - the development teams are usually low enough on the food chain that the ScrumMaster is not someone with such clout, and will be unable to deter these threats to the integrity of the team.
And that is a detail that I will return to in a later post.
Technorati Tags --
Software
SoftwareDevelopment
Computers
Programming
Friday, January 20, 2006
Thursday, January 19, 2006
Extreme Programming
Extreme Programming (XP) is arguably the hottest methodology in the Agile bunch. Entire libraries of books have been written about it in the last 10 years (if that long). Lately it appears to be dropping off the trend radar, but the boost it gave to Agile Methodologies ensures it will not fade away anytime soon.
XP consists of 12 Core Practices:
Refactoring is one of the hardest to explain to a non-programmer. As every developer knows, the design as originally planned never quite matches the code that you end up with. Reality forces numerous small deviations from the blueprint, and so the end product is full of hacks, compromises, and cruft. So developers need to spend some time periodically reorganizing the code structure and clean out the digital dust bunnies.
The problem is that managers often don't want working code to be touched, and since refactoring is intended to change the code structure without altering the function, it can be difficult to get buy-in for it. The best suggestion I have heard is to use Rube Goldberg as the metaphor - his contraptions worked, but they were hardly streamlined. A little time to replace the cats, candles, and buckets with motors, switches, and tubing, and voila!, it works, better.
Sustainable Pace is another one likely to stick in the craw of management. In XP vernacular, this means a 40-hour week, all the time. No Death Marches, no 80-hour-weeks, nada. XP holds that with all the Core Practices in place, the team should not need to work overtime. As far as I can tell, current American management is quite unlikely to accept "No, we're all going home at 5", if there is work left to do, especially if there is a deadline looming. Having been part of at least 2 Death Marches, and one pre-planned Zombie Stroll, I can attest to the diminishing returns of 60-80 hours a week for more than 2 weeks.
Onsite Customer is the one practice that I feel is hardest to introduce. Too many development shops are kept away from the customers because the managers feel uneasy with the developers in close proximity to the customers. Others have the problem that they have more than one customer with differing needs, so that it is difficult to reconcile all the customers' needs. Also, few customers want to dedicate a knowledgable staffer to the project for that much time - they'd rather throw a few hours into a RFP-style document and have the development shop do all the work from there, until the time for testing arrives.
Technorati Tags --
Software
SoftwareDevelopment
Computers
Programming
XP consists of 12 Core Practices:
- The Planning Game
- Small Releases
- System Metaphor
- Simple Design
- Test-Driven Development
- Refactoring
- Pair Programming
- Collective Code Ownership
- Continuous Integration
- Sustainable Pace
- Onsite Customer
- Coding Standard
Refactoring is one of the hardest to explain to a non-programmer. As every developer knows, the design as originally planned never quite matches the code that you end up with. Reality forces numerous small deviations from the blueprint, and so the end product is full of hacks, compromises, and cruft. So developers need to spend some time periodically reorganizing the code structure and clean out the digital dust bunnies.
The problem is that managers often don't want working code to be touched, and since refactoring is intended to change the code structure without altering the function, it can be difficult to get buy-in for it. The best suggestion I have heard is to use Rube Goldberg as the metaphor - his contraptions worked, but they were hardly streamlined. A little time to replace the cats, candles, and buckets with motors, switches, and tubing, and voila!, it works, better.
Sustainable Pace is another one likely to stick in the craw of management. In XP vernacular, this means a 40-hour week, all the time. No Death Marches, no 80-hour-weeks, nada. XP holds that with all the Core Practices in place, the team should not need to work overtime. As far as I can tell, current American management is quite unlikely to accept "No, we're all going home at 5", if there is work left to do, especially if there is a deadline looming. Having been part of at least 2 Death Marches, and one pre-planned Zombie Stroll, I can attest to the diminishing returns of 60-80 hours a week for more than 2 weeks.
Onsite Customer is the one practice that I feel is hardest to introduce. Too many development shops are kept away from the customers because the managers feel uneasy with the developers in close proximity to the customers. Others have the problem that they have more than one customer with differing needs, so that it is difficult to reconcile all the customers' needs. Also, few customers want to dedicate a knowledgable staffer to the project for that much time - they'd rather throw a few hours into a RFP-style document and have the development shop do all the work from there, until the time for testing arrives.
Technorati Tags --
Software
SoftwareDevelopment
Computers
Programming
Wednesday, January 18, 2006
Hello, World!
Hello, World!
This will be my attempt to expound some of the wisdom I've gleaned from 20 years of software development.
All the methodologies and books describe things in the perfect world of full management buy-in, clean handoff between phases, complete documentation, and such. Real-world developers find that these plans are scrambled by management using archaic practices, bar-napkin documentation, schedule changes, and features moving between releases.
So I'm hoping to describe some of the things that I've learned in 20 years of developing software in a variety of environments; things that are not part of methodologies, processes, and plans; things that might help newer developers have an easier job.
I'm keeping my name and employer(s) confidential so I can speak freely about some of the less-desireable things that I've experienced without facing legal and social consequences - I'm not looking for trouble, but I also want to honest about things.
This will be my attempt to expound some of the wisdom I've gleaned from 20 years of software development.
All the methodologies and books describe things in the perfect world of full management buy-in, clean handoff between phases, complete documentation, and such. Real-world developers find that these plans are scrambled by management using archaic practices, bar-napkin documentation, schedule changes, and features moving between releases.
So I'm hoping to describe some of the things that I've learned in 20 years of developing software in a variety of environments; things that are not part of methodologies, processes, and plans; things that might help newer developers have an easier job.
I'm keeping my name and employer(s) confidential so I can speak freely about some of the less-desireable things that I've experienced without facing legal and social consequences - I'm not looking for trouble, but I also want to honest about things.
Subscribe to:
Posts (Atom)