Agile Software Development with Scrum

bucketman writes "Saw this book at Chapter's and bought it and read it straight away. I've been kind of sitting on it for a month or two because my reaction to this book was so strong that I kind of wanted to see if time would mellow it. Well, it hasn't and I'm ready to post now. Note that this book has already been reviewed on Slashdot once, but I've decided to send in my review anyway, as it presents more detail as well as an alternate point of view and might be of interest." Read on below for bucketman's take on the book (and the methodology).

Extreme Programming (AKA XP) has been an interest of mine for some time, as I struggle to find ways to make it easier to say "yes" to in my domain (embedded systems) and it is in the study of this other development process that I first heard of Scrum. Both XP and Scrum are development processes under the "umbrella" of the Agile Alliance.

First and foremost, let's cover what Scrum is, as presented in this book. I will compare Scrum with XP as I go, for reasons that will become obvious later on.

You have the Scrum Master, who is more or less half technical lead and half project manager. He is defined as being responsible for the success of Scrum. I think the closest thing that XP defines to this is the Coach, but it's a poor fit at best.

You have the Product Backlog, where all the stuff that people want in the product is written (called Work) along with assigned priorities for each item and an estimate of some form indicating how long it will take to do. The assumption is that items with high priority will have more accurate estimates and more precise specifications and the low priority stuff will be more or less SWAGs. The Product Backlog also contains Issues, which are more or less problems that gate one or more Work items. Issues are turned into Work by the Product Owner (see below) at his discretion. The analogous concepts in XP is the Story and the Tasks.

You have the Product Owner. He owns the Product Backlog document and the prioritizations within. While he may need to consult others in the effort to do his job, it is his responsibility to maintain the list of work and issues, to decide the prioritizations and to decide what work will be done in the next Sprint (see below). The Product Owner also owns the estimates in the Product Backlog. It is expected that he consults with development to derive these numbers. These estimates are said not to be binding on the Scrum Team (see below). The XP role akin to this is the Customer, with the exception that, in XP, estimation comes solely from development.

The Scrum Team is just the set of technical people working on the product. So testers, documentation people, developers etc. Should aim to be around seven people (i.e. the "optimal" group size).

The Sprint is the development iteration. It should typically aim to be 30 days. It has a Sprint Goal, which defines the overall objective of the Sprint (think of it as a mission statement just for the iteration), and a set of items from the Product Backlog to develop during the iteration. These items are chosen during the Sprint Planning Meetings mainly by the Product Owner. A secondary meeting is held with just the Scrum Team and Scrum Master to decide who will do what and in what order within the Sprint. Also done in this meeting is the breakdown of Work to Tasks, which are smaller units no longer than 4 to 16 working hours in duration. The XP Sprint equivalent is simply the iteration. To my knowledge, there is no equivalent concept to the Sprint Goal. XP's Planning Game does the work of both the Sprint meetings noted earlier.

Because the duration of the Sprint is respected first and foremost, the Sprint Goal is used to determine what content to remove from the Sprint in the event it is discovered that the deadline is at risk. So, we move work from the Sprint to the Product Backlog while attempting to honor the Sprint Goal in order to satisfy our (e.g.) 30 day schedule. If that is not possible (and in some other situations, like irresolvable organizational impediments) the Sprint is canceled and redone from the Planning Meeting.

You have the Sprint Signature, which tracks the expected Work done against the actuals and provides a day-to-day description of what happened in the Scrum Team (similar to, nut much smaller than, the project log spoken of by Steve McConnell).

Once the Sprint is on, no one outside the Scrum team has anything to do with the Scrum team. XP, again AFAIK, does not state this, but the fact that iterations are, if anything, even shorter than Sprints means that in all but the worst cases, the stakeholders will likely be willing to wait until the next iteration to redirect the effort. In any event, because both processes return so frequently to the customer for guidance and because both processes allow the customer to introduce change throughout the lifecycle,, there is less risk that the customer will feel their wishes are not being respected. Lastly, XP's customer and Scrum's Product Owner both funnel all requirements to development. All the project stakeholders then direct their requests to this person. In so doing, the stakeholders never get told "no" per se, but rather are told that at worst their request won't be evaluated until the next iteration/Sprint planning meeting.

At the daily Scrum Meeting, each Scrum Team member answers the following questions:

• What did you do since the last Scrum Meeting?
• What will you do between now and the next Scrum Meeting?
• What, if anything, impeded your progress?

So, you say how you did yesterday against your commitment from yesterday. You say what you plan to do today. All this is recorded in the Signature which is kept by the Scrum Master. Lastly, you note any obstacles that got in your way. It is the Scrum Master's job to note these and remove them immediately. The Scrum Master is expected to report on his progress in this area at each meeting as well. If the obstacle is a failure to make a decision, the Scrum Master is responsible for making that decision immediately - failing that, to ensure it gets made that day. I really like that, BTW, as experience has made clear to me that, on balance, the risk of making the wrong decision has a much lower negative effect on a team than does leaving it in limbo frequently. In the Scrum meeting, no one is allowed to speak save for the Scrum Team and Master. Others may attend but may not speak. This is intended to keep to meeting focused and short. I like this part but suspect that to do it successfully, you'd be wise not to invite anyone that's not intended to speak.

The Sprint Review is held at the Sprint's end and is intended to be a half-day forum where the Scrum Team presents to the stakeholders what it accomplished during the Sprint. The loose equivalent in XP is the final (for that iteration) successful execution of the Customer Tests (nee Acceptance Tests). I say "loose" because the XP concept is stronger - the iteration's deliverable is not only presented but accepted.

To get the Scrum process to scale, a Scrum of Scrums is used where Scrum Masters from multiple Scrum Teams attend a Scrum Meeting run by a Scrum uber Master.

So, AFAICT, that's pretty much it.In reality, I don't see a whole book's worth of content coming out of this.

So what else do they discuss? There's a fair bit on work environments, the ill effects of heavy weight processes and so on - basically restating stuff in less detail that most everyone who will read this book would be likely to have read elsewhere.

There's a lot on the characterization of Scrum in terms of Process Control Theory and why it would be expected to be a better fit for software development than would other processes. This left me cold, frankly, because I tend to read these books looking for what to do, how to do it and what benefit I should expect to see. The underlying science of it is of some interest but not nearly so important to me as the answers to those three questions. Also I already implicitly favor these iterative approaches. So do many, many others - after all, the evolutionary lifecycle model and the "mini-milestones" proposed by McConnell in "Rapid Development" echo both XP and Scrums concepts.

We also get stuff like this:

"Overlapping development phases: In an environment where some of the requirements are discovered while simultaneously something is created with the information at hand, it is imperative that the phases of discovery, invention, and testing overlap to drive the creation of a new product to completion through self-consistency. Most problems in new product development arise when the phases of the project are separated. Empirically, this overlap in phases enhances shared responsibility and cooperation, stimulates involvement and commitment, sharpens a problem-solving focus, encourages initiative taking, develops diversified skills, and heightens sensitivity toward market conditions."

Other than "don't use the waterfall lifecycle," what exactly does all that mean? The end of it is completely unsubstantiated. It drives me nuts when development books do things like this. That paragraph doesn't say much of anything AFAICT but nonetheless manages to set expectations way too high.

Here's another (about the psychological effects of Scrum on the Scrum team):

"They become deeply involved in their work. Scrum drives individuals to focus, commit and excel.
They focus on the work and lose concern for themselves.
They experience an altered sense of time.
They consistently produce at high levels of accomplishment.
Scrum allows developers to concentrate most of their time in developing software, and by doing so developers enter 'flow' state."

I don't know what any of that means and I'd be scared to find out.

Out of nowhere, you get statements like this:

"Scrum requires a balance of individuals with at least 50% of them to be experts ..."

Well, I guess that's that then. I think I could define a process which would have demonstrably improved efficiency over the lifecycle with just that one statement - worse comes to worst just sack the other half and away you go :) Anyway, this requirement appears for the first time on page 121 in a book with all of 154 pages. It's hard to say if it's intended to be taken seriously - if it were, you'd think it would have been a lot more front and center.

But let's go back to what Scrum is, as shown earlier. IMHO, it is not a lot more than XP with at least the following removed (this from memory, please don't be too harsh):

• Continuous integration
• Refactoring
• Unit testing
• Paired programming
• Collective ownership
• Customer-defined acceptance tests
• The "yesterday's weather" estimation practice
• Sustainable pace (nee "the 40 hour work-week")

So, all the hard/useful technical bits from XP are removed. In return, we get the Daily Sprint Meeting, the Sprint Goal, the Sprint Signature, and the emphasis on decision-making by the Scrum Master. The remainder of the Scrum practices have analogues in XP, as I've shown above. It's for this reason I found myself smiling when the book notes success in industry in wrapping XP in Scrum - from what I can see, XP wrapped in Scrum *is* XP :)

The book is careful to point out that any and all of these "missing" practices (refactoring, unit testing et al) may be used but that Scrum does not prescribe them. And that's fine, but I'm evaluating it on what it actually does prescribe - if Scrum can take credit for what it does not prescribe, they it can lay claim to infinite credit after all. This is maybe a small point but it's important to what follows. Because Scrum does not tell us what to do in these areas, I'm assuming that they are free to vary.

So, if you accept my characterization of Scrum as XP with all the hard technical bits removed. what might you see in a Scrum project?

If you follow Scrum's iterative path with no refactoring to offset the inevitable software entropy, the software would tend to lose architectural unity quixkly. It would be easy to break and hard to fix. - and so on and so on, for all the ills which refactoring is intended to address. If Scrum does not prescribe refactoring explicitly, then we must assume that not doing it is an acceptable Scrum path. If Scrum requires refactoring as a key practice, it should say so. XP and Scrum turn every project into a maintenance project but XP bolsters that position with all the technical practices that ensure the team is *really* good at maintenance. Scrum does none of this. Combine the lack of refactoring with no prescribed regression (unit) testing and I think it becomes clear that Scrum projects that do neither would risk devolving into code and fix affairs.

Because we have no review process prescribed in Scrum, which XP provides via paired programming, and no stated ownership model, we would expect to see Scrum projects which explicitly prescribe neither ending up with code like little fiefdoms where the divisions between one guy's code and another's are painfully obvious. We also would expect to see de facto individual code owners with all the gone-to-greener-pastures risk that entails.

Because we have no estimation practice prescribed we would expect to see poor estimates. Because the Product Owner owns these estimates, there's no reason to expect them to be meaningful at all.

And in return for all this, what do we get? We get the Sprint Goal, which is a fine idea, IMHO. It defines, a priori, a way to sensibly cut work within an iteration. We get the fast decision-making from the Scrum Master. This is also fine by me. We get the intense project progress tracking of the daily Scrum Meeting and the Sprint Signatures. Hmmm ....

And so, at long last, and very much in my long-winded way, I'm finally ready to state my real conclusion about Scrum ...

But first here's another quote from the book :) It's an example Sprint Signature description:

Day 16-17 The team is discouraged by all the work remaining and didn't work during the weekend. No changes in estimated time remaining.

Day 18 The team works more and its remaining work declined. The team then met with the Product Owner and the Scrum Master to determine what tasks could be reduced or removed while still meeting the goals of the Sprint. Some Sprint backlog was dropped; other estimates were lowered because not as much functionality had to be supported. Overall estimated work remaining reduced to 1400 hours. If all this work is completed, the team will still meet the Sprint Goal, although with functionality implemented less completely.

Day 19 The team continues work toward the Sprint Goal using the new Sprint Backlog. Estimated work remaining declines.

Day 20-30 Team is motivated because it can still meet the Sprint Goal if it works hard. The team works regularly including during the weekends. Estimated work remaining declines to zero as the team meets its Sprint Goal by the 31st day."

Here's one thing I've learned in the working world - death marches don't just happen on their own. It's not easy keeping a real death march going. You need to brutally cut and slash the work items in the finest detail to ensure that what you're committing to is actually what's absolutely necessary. To do this, you need to get stakeholders interested enough to grovel around in these nasty details. To really run a death march (and sustain one), you need to track everything everyone's doing down to the granularity of hours so you can tell immediately if someone has returned to a normal level of effort (people will tend to do this long before their actual *hours* spent at work decline). You need to make this tracking of effort very public so people feel intense peer pressure to keep their effort as high as their colleagues. You need to keep the goal always seemingly in reach and make sure this perception is held by everyone on the team because once the expectations are obviously unrealistic, most people will slack off. As long as the goal looks possible with significant effort, people will still buy into it.

And, in the end, that's what I think of Scrum: if you take away all those XP practices and don't replace them with anything, I think you end up with a really good way to run a code and fix death march. And if you put back all those practices, you're pretty much doing XP. I believe parts of Scrum can be lifted and applied in other processes (particularly XP) but that you'd be insane to adopt Scrum as defined in this book without addressing the risks detailed above."

---

You can purchase Agile Software Development with Scrum from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Not that I'm an expert

[strictnein (318940)]

But I remember going through my classes at school, with many of the profs just so damn excited about XP and other types of programming practices. I've yet to expereience any of these enviroments really thoroughly followed in a company. For me, the only time they are followed is at the weekly development meetings, then we all play by our little roles. But after the meeting, we're back to the same old chatoic programming.

After reading the post, Scrum does less for me than XP does, which also does very little.

On a completely different topic, what happened to that Microsoft anti-linux post? Actually found that a little more interesting, but it was pulled before it ever reached the main page it seems.

Inspections?

[mekkab (133181)]

Aren't inspections supposed to be the catch-all for crap programming? Again, if your inspectors are morons, then the whole thing is shot.

That assumes you have reasonable timeframes.
I've worked on projects to get Demos out the door. Informal use of some XP ideas (coding in pairs) and tight, fast iterations of Coding,integration and test, coding, integration and test, repeat, which have showed some promise when deadlines are tight.

Re:Inspections?

[laalto (97788)]

Who inspects the inspections then?

I once witnessed a project where there was a customer requirement for source code inspections. The project manager spent a whopping evening "inspecting" 120 KLOC of code and marking them as "inspected".

Re:Inspections?

[mekkab (133181)]

THe Metrics collected from the inspections are then used to generate trends. One of these metrics is "time spent reviewing materials." (at least it is in our process). Also, the metrics of bugs found in the field. If more and more bugs are found in the field, inspections aren't working.

I never knew why they collected that "Time spent reviewing" metric.
However, your example of 120k sloc in an evening explains to me why.

Re:Not that I'm an expert

[TwistedSquare (650445)]

In my company, where the projects tend to involve very small teams (1-5), you can pretty much choose to do what you want as long as the result is what is needed. So some people use XP, some people do iterative stuff, some people plan it all out, etc.

Re:Not that I'm an expert

[twilightzero (244291)]

For a real-world example of XP in practice, take a look at Lakeview Technologies (the guys who make Mimix for your AS/400 gurus). They implemented it company-wide a while back and they've been turning good, functional product out the door in small fractions of the time that they were originally estimated at. I believe what convinced them to switch was a team who took a project estimated at 2 years and knocked it out in something like 4 months with half the estimated personnel. They have customers either

whoa, not what I read.

[mekkab (133181)]

I first read scrum as scrotum and said "Finally! Programming with balls!"

Step away from the keyboard, I think its time for a break...

Re:whoa, not what I read.

[mekkab (133181)]

Programmers by the balls, hmmmm, Oh! You mean I'm not a MANAGER yet! Gotcha! No, I'm not. I actually create things and add value. But as soon as I cease to produce anything of use, I'll most likely be leading the team.

Re:whoa, not what I read.

[mekkab (133181)]

For me, it's time to follow through on last year's New Year Resolution of writing more C.


Why? So you can hang yourself in a web of pointers to pointers to function pointers?! I wrote a kernel queueing system in C, and had every intention of writing clear and understandable code. Got-damn was it a mess of for and while loops!

And even with the use Strict pragma, I'm getting convinced more and more that Perl is a Read-only language. You are either a PERL programmer 100% of the time, or you forget everyth

Flavor Of The Month...

[doctechniqal (516085)]

I really hate these books that attempt to codify management processes in some kind of all-encompassing, one-size-fits-all way. By the time the processes have been codified and published, the economic climate and the state of things in the business to which the processes are to be applied have changed such that the processes rapidly lose their relevance and ultimately their usefulness. Other than as a way to make money for the authors, I just don't see any real sustainable benefit ever coming out of these books.

Re:Flavor Of The Month...

[rw2 (17419)]

Other than as a way to make money for the authors, I just don't see any real sustainable benefit ever coming out of these books.

1) Writing a book like this to make money is a big loser compared to working and making money.

2) Just because there are a lot of flavors doesn't mean they don't work. It is useful to be aware of several different methodologies and chose the one which best matches the culture of the project when organizing a project. Agile is not cool for a typical IBM mainframe project. Water

Re:Flavor Of The Month...

[rw2 (17419)]

You're a manager, aren't you? I don't think I've met a programmer who's ever mentioned anything about bring "value to the table"

Close. I'm a consultant, so I bring the worst of all worlds with me when I pan handle at your door. ;-)

(I'm also available for contracts right now. Companies getting into grid software should contact me. Resume [objenv.com])

Re:Flavor Of The Month...

[millette (56354)]

only this book was published in 2001 - that's at least a 3 years long month...

standard PM procedures?

[itwerx (165526)]

Am I missing something?
Not to troll but, other than a few different labels for things, I fail to see how this is any different from standard project management procedures that have been around for decades...?

Well done review though!
We need more like that! :)

Re:standard PM procedures?

[millette (56354)]

I hope you aren't sarcastic about your last comments on the review. I found it helpful - I probably won't be buying this book now. Also, I read XP refactored recently, and it sort of opened my eyes, I'm happy to admit :)

Re:standard PM procedures?

[itwerx (165526)]

As opposed to a long-term project plan, where the work is laid out in detail for the entire project, SCRUM and XP say that you only plan in detail for your immediate set of work (vast simplification). Then after you finish that work, you replan.

Even so I am sure that there is in fact a long-term plan at some higher management level.
SCRUM appears to simply be focusing on the most granular level of the breakdown of project elements and responsibilities.
The lowest level team leaders in a large projec

Doubletakes

[greygent (523713)]

Had to do a doubletake there, "Agile Software Development with Scrotum".

Hell, I can barely type using all my fingers, let alone develop software by mashing my scrotum on the keyboard...

Ok well, maybe I could develop a VB app that way...

Bashing management practices

[ajs (35943)]

This is the obligatory defanging of management bashers...

In every badly managed company or group that I have worked in, everyone who was badly managed could identify that they were, in fact, badly managed. But time and again they were proven wrong as to WHAT the problem was, because their complaints would get addressed (often slowly) and the situation would not change (only the complaints).

Management practices like XP or Scrum are designed around the idea of solving for one problem: consistency of success. They may or may not prove to be reasonable aproaches in the long run, but what I do know is that most of the people (and I've already seen comments from a few) who are going to reply with some form of "mangers/consultants/paper-pushers are just looking for some buzz-words to keep them employed" wouldn't have a workable suggestion to counter with.

Some of the problem that managers face are so unquantifiable (like level of respect that team members have for eachother) that I honestly do not think that there will ever be a one-size-fits-all approach that works. I liken XP instead to just-in-time manufacturing (a manufacturing process that was popularized by analyzing why Japan was kicking US butt in terms of product cycles)... it is not, nor can it be, the absolute solution, but it may well be a valuable signpost on the way to consistent goal-meeting.

XP == Japan Manufacturing

[JWhitlock (201845)]

I liken XP instead to just-in-time manufacturing (a manufacturing process that was popularized by analyzing why Japan was kicking US butt in terms of product cycles)... it is not, nor can it be, the absolute solution, but it may well be a valuable signpost on the way to consistent goal-meeting.

I had the same impression, but for different reasons. At the university (engineering school), Japan's manufacturing process was analyzed in terms of quality control. They used randomized techniques to select prod

Consistency of success...

[DrCode (95839)]

Managers are always looking for a methodology for ensuring success.

What I've found, is that the only way to have success is to have good developers, and that means people who are not only technically competent and skilled at writing software, but also mature enough to get along with each other.

This isn't really unusual if you think about other professions. If you need surgery, you're most likely to find a doctor with a good track record. What you wouldn't do is come up with a "surgery methodology" and t

Too much work

[The Wing Lover (106357)]

Day 20-30 Team is motivated because it can still meet the Sprint Goal if it works hard. The team works regularly including during the weekends.

Is that supposed to be a good thing? The one thing that I like about working in an IT department within a non-tech company (rather than working in a tech company) is that there's none of that pressure to be a "real geek" and put in 90-hour weeks at the office...

hmm..

[IWantMoreSpamPlease (571972)]

...moistened-bint-lobbing-scimitars dept....

I thought it was bink...am I missing my english slang here?

Re:hmm..

[MightyTribble (126109)]

No, no, it's "bint", as in a derogatory term for a woman. I'm not sure if 'bink' has a place in English vernacular....

Re:hmm..

[IWantMoreSpamPlease (571972)]

(adopting the voice of the french cleaner shrimp from Finding Nemo)

I am ashamed

Counterpoint to XP and other "agile" manifestos

[scrytch (9198)]

Obligatory linkwhoring: The Skeptical Software Development Manifesto [hacknot.info]

It doesn't actually sit opposite any methodology, it simply extends the basic principles of skeptical inquiry into software engineering. It's anti-hype more than anything else.

There are no best practices

[Sean80 (567340)]

I've been working on a little theory of my own of late that there are actually no "best practices." Perhaps I'm crazy, but it seems to me that you only really "need" three things in software development - a) A measurement process, b) A process improvement process and c) a documented process, whatever it might be. Then, you can start out cooking chickens instead of doing software development, but the combination of the three will always drive you in the right direction, and you'll just keep on getting better and better.

Given that, you can then take books like this and try and integrate them into your process. One of the things that's always missing in these books is how they will impact your measurements. Reduce development time by 50% huh? Well, show me the money! In my view, things then enter the realm of Design of Experiments. How do I think I can best reduce measurement x? Well, here's this book, let's try this out and see how it affects x.

No "best practices," only "better" practices. Better and better every month. Perhaps I'm crazy.

Re:There are no best practices

[greenrd (47933)]

Software engineering is a social science[*], and therefore a difficult science. There's too many variables to know for sure whether your lauded Factor X was really responsible for an increase in productivity. In fact, it's sometimes impossible to prove that there was an increase in productivity, when projects being compared are really different.

How do you measure productivity anyway? LOC doesn't really work, because rewriting code to make it smaller does not mean negative productivity.

--
[*] Forgive the

The best practices is Layering

[AeiwiMaster (20560)]

That is worng!

At the time of writing the best practice is
Layering!

Here is the proff. [all-technology.com] ;-)

L Ron Hubbard strikes back

[GMFTatsujin (239569)]

The team works more and its remaining work declined. The team then met with the Product Owner and the Scrum Master to determine what tasks could be reduced or removed while still meeting the goals of the Sprint. Some Sprint backlog was dropped; other estimates were lowered because not as much functionality had to be supported. Overall estimated work remaining reduced to 1400 hours. If all this work is completed, the team will still meet the Sprint Goal, although with functionality implemented less completely.

Following that, the Thetans will be clensed by the operator, and everyone will finish off with a nice glass of kool-aid.

Seriously... what the fuck gwan on with all this jibber-jabber?

I downloaded SCRUMVM...

[whyde (123448)]

...and have been playing "Software Development Supervisor" for the last two weeks! Best MMORPG yet! I still can't kill enough bugs to get to SEI level 3, though. Must be a process issue...

Not dazzled by scrum

[steve802 (99297)]

I have a lot of roles in my life. Yes, I am a programmer. But I am also a husband, father, and just a plain old damn person. Any time I hear of a methodology that encourages people to work lots of overtime I cringe. People cannot sustain a pace over 30 days where they are coming in early, staying late, and working weekends, to meet a goal that is only a few hours away, when another goal has just been met a few hours ago. Daily scrums have to be the biggest waste of time I have ever heard of.

At my company, one division used the Scrum method, and it failed, taking the division, 100 jobs, and millions of development dollars with it. The biggest problem I heard from senior programmers in other divisions was that the daily scrums encouraged people to build a great prototype to show what they would do, but there so never anything actually done. Programmers would work for hours in the morning to fix the problems identified in the prototype, make changes in the afternoon, and start again after the next scrum. Waste, waste, waste.

In our division, we have a product designer build a spec with the customer. The spec is handed to the programmer. The programmer works on the project as long as necessary without interruption (which is not to say that deadlines are open ended), and then the programmer hands it off to QA. At worst there are weekly meetings to check status. The big difference is that the programmer is on his own, trusted to call in reinforcements when he feels they are necessary. There's no need for a daily meeting if there are no problems. If coding is going well, then let it keep going.

I have no doubt that scrumming works well for some, especially those who need constant direction and/or hand holding, or those who have no life outside of work. But I'll take our methodology any day.

Re:Not dazzled by scrum

[ivey (999)]

Any time I hear of a methodology that encourages people to work lots of overtime I cringe.

Me too. Scrum doesn't encourage overtime. No one tells the team how to meet their goal ... if they decide to work a weekend to make a goal, they can choose to do so. Otherwise, they go home. Their decision. The team agrees to what is going to be in the sprint. There appears to be a pretty serious misunderstanding about Scrum here. Many of the most vehement objections that have been voiced don't have anything to do with Scrum.

"death marches"

[yetanothertechie (699283)]

Day 16-17 The team is discouraged by all the work remaining and didn't work during the weekend. No changes in estimated time remaining.

Whatever slick new ways are created to try to squeeze yet more blood, sweat and code out of already overworked programmers, it still shows a fundamental lack of proper planning when one has to resort to "death marches" for anything but highly unusual circumstances.

It all comes down to planning and organization, both at the beginning and throughout a project. Without c

Why development methods matter...

[Dr. Bent (533421)]

One of the things that must occur when you move from a artistic/tradesman style of production to a engineer style of production is that you have to trade a little bit of quality for a lot of consistancy. This is why mass produced furniture costs less than hand-crafted stuff. The hand crafted stuff is slightly different from item to item, and sometimes mistakes are made and you have to throw out big hunks of furniture (which makes it more expensive), but the product that you get in the end is much better. However, unlike furniture, there is no aesthetic appeal to hand-crafted software. Most software projects are done to solve business problems, which means most software projects have to live by the same rules as every other business venture. Ok, for a minute now, everyone put on a suit and pretend you're an MBA.

You have a $1,000,000 budget for the coming year. Your goal, as an executive, is to turn that money into something worth more than $1,000,000. The additional amount you get is called the Return on Investment (ROI). The ROI for the S&P 500 index has historically been 11%, and most companies will not embark on a project with an ROI of less than 25% (or so).

But ROI is not the only thing to consider when deciding whether or not to start a new project. The other thing to consider is risk. What are the chances that you're actually going to get your 25% back? What if, in addition to not making any money, you actually lose money by spending $1,000,000 dollars over the course of a year and getting nothing in return?

And here is where the software development methology steps in. Software development methodologies help to eliminate risk by setting down guidelines that help to ensure that a project will not fail. Even if it means that you take 20% longer than you would if you didn't use the methodology, and even if the product that you get in the end isn't quite as good, at least you have something that works.

What software development methodologies do is limit the bounds on the ROI for a project. They make it less likely that the project will be a resounding success, and they make it less likely that the project will be an utter failure. This, in turn, allows the planners to plan and the bean counters to count thier beans, and that is a tradeoff that they will gladly make.

It's predictabilty that businesses value. Not efficiency. Not quality. Not even raw cost. All of those things are secondary to the issues of "How much of my money will I get back?" and "Are you sure?"

Re:Why development methods matter...

[Dr. Bent (533421)]

Why do development methods make resounding success less likely?

Because they waste a lot of time by imposing procedures that do not create value (i.e. working, tested, maintainable code). Of course, those procedures are ususally designed to make sure that catostrophic failures don't occur, so they're important. Using a development methodology is like taking an insurance policy out on your project...you can't spend as much time designing, coding and testing (so it costs you more), but what you end up with w

Comment from the 1st reviewer

[bADlOGIN (133391)]

To this review's author:

As the author of the extremely short previous review, I commend you on your overview of the details. Considering how brief the origial book is, you've covered most of the book here:) However, I'd like to point out that the most important thing to keep in mind about this book is that Scrum itself is intended to be a management wrapper for _any_ engineering processing you wish.

I suspect that's why you gave the book such a low score: no "soup to nuts" implementation. Again, however, that's the point. You need to adapt your development to your organization, and the goal of Scrum is to provide a way to do that via change evolution rather than revolution.

Scrum itself has a relativly small set of rules and jargon (compared to some of the methodologies), even less than XP. But that's the point. Adapting Scrum into an organizations culture can give you better _management_ of your development process and bring about significant changes without as much infighting and issues as other "heavier" processes do.

Oddly enough, what I liked about the book is most likely what you disliked about it. It's attempting to illustrate why there are so many problems with viewing software development as a defined process (like building lawnmowers), because it's not well modeled as a defined process. Again, I go back to viewing this book as containing more of the "why" of Agile software development as opposed to the "how" of Agile software development (XP, in my opintion by popularity).

Thanks for your good review work. While I disagree with your rating for being too low, in retrospect, think mine may have been a bit high. All in all though, as content coverage and explanation goes, I commend you for doing an outstanding job.

P.S. Any thoughts on Yourdon's Second Edition of "Death March" [amazon.com]? Now a review of THAT could get some good chatter going:)

Ahem.

[johnbr (559529)]

Having read the book, taken the ScrumMaster course and implemented Scrum in my organization, I think I have a somewhat different take on the value of the beast. (I, btw, also have almost 1.5 decades of experience in software development)

First, SCRUM is not trying to supplant XP. It is trying to supplant RUP and waterfall. If you don't believe me, check out www.xbreed.net, which tries crossbreed SCRUM and XP, and was written by one of the authors of SCRUM.

Second, SCRUM specifically says that is is a "candy bar wrapper, not a candy bar" (i.e. it is a wrapper around development practices, not a replacement for them). I recognize that the name might be confusing, and I accept that. But the book does not ever say that you shouldn't use good development practices within the SCRUM model.

Third, SCRUM simplifies reporting and tracking, in ways that are analogous to, and quite possibly simpler than XP (I've used XP too). I know all you code monkeys disdain reporting and deliverables and tracking all that, but those of us who manage you monkeys need to be able to report some sense of progress, and SCRUM gives us tools that do exactly that.

Fourth, SCRUM establishes an additional goal for each 30 day sprint - deliver something of demonstrable value to the customer. That, by itself, is a very powerful mindset, because it strips away a lot of the bs programming, leaving stuff that the customer will use. Ideally, the customer would be there every day, but I have yet to see that happen, except when the customer is in the office/cube down the hall.

More than anything else, I'm amused. It's like you got the elves coming up to Helm's Deep to aid in the fight against the Uruk-Hai, and the humans in the castle attack the elves for having different weapons! Nothing about SCRUM is in any way contradictory to XP w/a 4 week iteration If anything, it provides some additional benefits. We use the core set of XP development memes (UT, daily builds, PP and Refactoring, etc), and we use SCRUM to help guide the month's worth of work. And it works very well for us.

Re:Ahem.

[PissingInTheWind (573929)]

> Having read the book, taken the ScrumMaster course and implemented Scrum in my organization [...]

Of course you beg to differ.

The higher the investment you made in learning something the harder you'll vouch for it, wether it's good or not.

Re:Ahem.

[William Tanksley (1752)]

The higher the investment you made in learning something the harder you'll vouch for it, wether it's good or not.

And the less you know, the more competant you imagine you are.

Do you have any reason to suspect that the original poster is wrong? I.e. do you believe it's good or not?

Or were you just wasting electrons?

-Billy

Eigenpoll

[AeiwiMaster (20560)]

Hi

I have a eigenpoll for comparing the
best books on Agile software Develoment
here [all-technology.com]

rigth now it have the following books

PeopleWare
Agile Software Development PPP
Lean Software Development
XP Applied: Playing to Win
Agile Software Development
XP Explained: Embrace Change
Refactoring
Planning XP
Test-Driven Development
ASD Ecosystems
Pragmatic Programmer
ASD with Scrum
Agile Modeling
XP Installed
Unit Testing in Java
Adaptive Software Development
Testing XP
Pair Programming Illuminated
Writing Effective Use Cases
XP Explored

I use Scrum and I like it

[jeremybguero (682870)]

Scrum doesn't turn into a Death March.If it does then you ScrumMaster needs his head examined. I personally try to avoid any job where my boss is an idiot.

The basic purpose for my team using Scrum is to keep focused and be able to work towards a single goal.

The daily scrum meeting helps to coordinate the group and help each other out if there are problems. And we can find out in that meeting if someone is off track on the project or had a better method to do something.

We stick to our 40 hours and do

Re:How many ways can you say "iterate"?????

[tcopeland (32225)]

> Requirements. Design. Build-test-debug
> cycle. Document. Release

That's not iterating, though... that's "big design up front". Here's iterating:

while (two_week_iteration_in_progress)
design/test/build/document
end

See? Like they say: design is important - it's so important that it needs to be done throughout the lifetime of the project!

Re:How many ways can you say "iterate"?????

[musikit (716987)]

i donno can you repeat, restate, say again, rephrase, reiterate, reword, utter again, go over, or emphasize the process a bit more?

the following list of words was generate from MS Word Thesaurus for the word "iterate"

Re:How many ways can you say "iterate"?????

[IWorkForMorons (679120)]

Easy...have a "management committee" come along with a project to replace your aging AS/400 systems with Unix and PeopleSoft. Then it becomes:

Requirements. Document. Redo Requirements. Document. Redo Requirements. Document. Document. Document. Design. Document. Redo Design. Document. Document.

The next steps are supposedly the "Build-test-debug cycle" and "Release" parts. But considering the rest is 3 months overdue already, and doesn't look like it's ending anytime soon, I'll probably ge

Re:How many ways can you say "iterate"?????

[fliplap (113705)]

Hah. Do you by chance work for a large bank?

Re:How many ways can you say "iterate"?????

[IWorkForMorons (679120)]

Nope. Insurance. Almost like a bank, but without the annoyance of handling real money.

Re:How many ways can you say "iterate"?????

[TrueJim (107565)]

There are two ways to say it.

1. Implement the high-risk features first. (spiral development)

2. Implement the high-payoff features first. (evolutionary development)

Re:Scrum?

[GTRacer (234395)]

IIRC, it's a situation in English/Aussie rugby/football where players on both sides form a "super-huddle" and try to shove the player with the ball in the desired direction.

I used to get Fox World (damn you ComCast!!) and was much clearer on rugby play. What's funny is that it always seemed that a scrum was a standoff, an odd choice of name for a programming process...the tension only broke when the ball was passed or stolen out of the scrum.

Or maybe not.

GTRacer
- Plays footy of a different ilk

Re:Rating mistake

[millette (56354)]

*hehe* Doesn't leave much room for mistakes either, now, does it :)

Re:I might understand these programming methodolog

[Cthefuture (665326)]

Well, that's part of it anyway. In my experience (good) programmers tend to be a lot like artists. That is, they can only work when they feel like it or are motivated. I wouldn't want to go off labeling quite possibly the best programmers you have as lazy or bad just because the mood doesn't strike them at the moment (hehe, I get this image of Paul Jr. in my head [American Chopper]).

Unfortunately this is the root of the problem. Work needs to get done yet not all programmers are going to be enthused ab