The new Software Development magazine came a couple of days ago. As always, Scott Ambler has an interesting column. I often agree with his points but I don tMessage 1 of 40 , Nov 9, 2003View Source
The new “Software Development” magazine came a couple of days ago. As always, Scott Ambler has an interesting column. I often agree with his points but I don’t this time and since Scrum is mentioned in the article I want to pass along the reference.
The article is about using “the right tool for the job” and its teaser says that “When it comes to methodologies, one size doesn’t fit all. By examining all the options, you can create a mix-and-match approach that best suits your project.”
The part of the article that I think is subject to debate is a figure he shows. The figure has a vertical axis with “full lifecycle” at the top and “partial methodology” at the bottom. He puts Scrum near the bottom on this axis saying that “Scrum [focuses] only on one aspect of software development, …project management.” At similar levels on this scale are Code and fix, test-driven development, his own Agile Modeling and Agile Data.
The horizontal axis goes from Ad Hoc on the left to Prescriptive on the right. Scrum is shown slightly to the Prescriptive side of the middle. At similar levels on that scale are DSDM, FDD, and Agile Data.
Scrum is defined in a sidebar to the article as “a partial agile methodology” and says that to use it “Tailor Scrum into agile or near-agile development methods.” What’s odd is that other processes that seem far less agile to me (e.g, FDD) are listed as agile while Scrum is “partial agile”. Similarly, XP is listed as more ad hoc than Scrum. That’s a hard one—in some ways (good ones) XP is fairly prescriptive and there was a lot of early talk in XP circles that if you weren’t doing all 12 practices you weren’t doing XP.
If I had to place Scrum on a scale between Ad Hoc and Prescriptive I’d put it pretty far to the Ad Hoc side.
Placing it between Partial Methodology and Full Lifecycle is harder. Yes, it’s partial because it doesn’t define how everything happens but it seems fairly full lifecycle in that the path to a potentially shippable product increment is defined. There’s nothing in Scrum about how to end a project or about how to handle a project in its earliest, pre-funding or exploratory phases but some of that is what Ken’s been adding in the CSM classes. Still, I’d say it seems more toward the Full Lifecycle end of things than the Partial Methodology end of things.
Anyone else have any thoughts about Scott’s article and placement of Scrum?
In any event, the article is quite good. The print issue is out now and they seem to put the articles online at www.sdmagazine.com a few weeks afterwards. (As a bonus, this issue has another great article—Bob Martin showing how tracking velocity and product burndown help manage a project.)
While I agree with Mike in general, it is of interest that the first Scrum was building an OOAD tool and we decided the team should eat their own dogfood. ItMessage 40 of 40 , Nov 14, 2003View SourceWhile I agree with Mike in general, it is of interest that the first Scrum
was building an OOAD tool and we decided the team should eat their own
dogfood. It was also the first round trip engineering tool.
Every developer had the model of his components on his wall.
Our senior consultant, Jeff McKenna, an ace Smalltalker, would walk into a
cube and an hour later the model was in shreds on the floor. He had shown
the developer how to refactor the model and eliminate half the code while
enhancing performance and functionality.
I've never seen another team that can operate at that level.
At 05:07 AM 11/14/2003, Mike Beedle wrote:
> > Mike has said repeatedly that he feels that
> > modeling isn't necessary in order to produce quality code. Scott
> > Ambler, myself, and some within the XP community have the opinion that
> > modeling, when necessary, and to the proper level of detail and
> > formality, provides an important element in the design and
> > implementation of software.
>This is also a fact:
> We produce hyper-productive, high-octane, high-quality,
> high-quantity software with little or no models.
>So no, models are not important to us, as they are not as
>important to most agile developers. (We minimize "documentation time"
>by documenting after the fact.)
>But like I said earlier, if you feel modeling helps your team, or
>is needed for political reasons, or you like how the models look on
>display on the walls, hey, more power to you.
>Good luck with all of your projects!!!!
>(It was nice to talk to you on the phone earlier this evening, btw.)
> > P.S. I'm looking forward to taking the CSM course some time in the
> > near future. Perhaps I'll walk away cured of my modeling sickness. :-)
>In 1994-1996 I was involved in a 100+ person, 30 million dollar
>software development project. By year 2 we had 1000+ pages of:
> Elaborated Use Cases
> Class Package Diagrams
> Class Diagrams
> Sequence Diagrams
> Test Plans
>but no working software. Within the last 4 months of the project
>I took over the project, *ignored all the previous models*,
>applied Scrum to the project and delivered the first instance
>of the application to production on 1/1/1996.
>(I have many other, almost countless experiences like that.)
>This is why I don't do models anymore -- they NEVER delivered the
>goods for me in the trenches.