Agile Software Development with Scrum 166
| Agile Software Development with Scrum | |
| author | Ken Schwaber and Mike Beedle |
| pages | 158 |
| publisher | Prentice Hall |
| rating | 1 |
| reviewer | bucketman |
| ISBN | 0130676349 |
| summary | Presents the Scrum software development process. |
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:
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."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."
Here's another (about the psychological effects of Scrum on the Scrum team):
I don't know what any of that means and I'd be scared to find out."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."
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")
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.
How many ways can you say "iterate"????? (Score:1, Interesting)
How many ways can you say it???
Re:How many ways can you say "iterate"????? (Score:5, Insightful)
> cycle. Document. Release
That's not iterating, though... that's "big design up front". Here's iterating:See? Like they say: design is important - it's so important that it needs to be done throughout the lifetime of the project!
The Object Oriented way (Score:1)
for (int day=0;day != 14;day++)
{
current_project.design();
current_project.build();
current_project.test();
current_project.document():
}
Re:The Object Oriented way (Score:1)
Re:The Object Oriented way (Score:2)
Re:How many ways can you say "iterate"????? (Score:2, Funny)
the following list of words was generate from MS Word Thesaurus for the word "iterate"
Re:How many ways can you say "iterate"????? (Score:3, Funny)
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"????? (Score:2)
Re:How many ways can you say "iterate"????? (Score:2)
Re:How many ways can you say "iterate"????? (Score:1)
Worked on a ton of those. You in the cubicle next to me?
Re:How many ways can you say "iterate"????? (Score:2)
Re:How many ways can you say "iterate"????? (Score:2)
1. Implement the high-risk features first. (spiral development)
2. Implement the high-payoff features first. (evolutionary development)
Re:How many ways can you say "iterate"????? (Score:1)
Not that I'm an expert (Score:3, Interesting)
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? (Score:2)
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? (Score:2, Interesting)
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? (Score:3, Insightful)
I never knew why they collected that "Time spent reviewing" metric.
However, your example of 120k sloc in an evening explains to me why.
There is no silver bullet (Score:1)
That doesn't mean that it is beyond some control, but as with any development process, it must be adapted to the organization that does the development.
Although this is not an easy task, it is not impossible, the biggest problem is that this also requires a lot of common sense (the least common of all senses
Re:Not that I'm an expert (Score:2)
Re:Not that I'm an expert (Score:2)
Re:Not that I'm an expert (Score:2)
Re:Not that I'm an expert (Score:1)
Thanks! I don't need to buy the book now! (Score:1, Insightful)
We need more reviews like that!
whoa, not what I read. (Score:4, Funny)
Step away from the keyboard, I think its time for a break...
Re:whoa, not what I read. (Score:1)
Re:whoa, not what I read. (Score:2)
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
Re:whoa, not what I read. (Score:2)
Re:whoa, not what I read. (Score:2)
Flavor Of The Month... (Score:3, Insightful)
Re:Flavor Of The Month... (Score:2)
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... (Score:1)
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". Hehe.
Re:Flavor Of The Month... (Score:2)
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... (Score:2)
Re:Flavor Of The Month... (Score:1)
1. Author describes a process that has been successful in a number of situations.
2. Author presents his description with (natural) enthusiasm for its effectiveness.
I just don't see how this necessarily translates to "all-encompassing, one-size-fits-all." It can, but I don't think it has here, with this book.
Other than as a way to make money for the authors, I just don't see any
standard PM procedures? (Score:2, Interesting)
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? (Score:2)
Re:standard PM procedures? (Score:1)
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. Each sprint or iteration is made up of that work that is currently considered the most business-critical functionality. This is very different than traditional project management methods, where the emphasis is on planning the project u
Re:standard PM procedures? (Score:2)
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
Re:standard PM procedures? (Score:1)
Perhaps you're referring back to the old "big iron" days where projects were measured in man-years, but no one manages projects like that any more. A "time to market" of several months qualifies as long-range planning these days, and the incorporation of "class level" estimates with their corresponding degrees of accuracy (not java classes, but class "zero" being +/- 100%, class 1 being +/- 50%, etc) at various points
I might understand these programming methodologies (Score:1, Insightful)
Re:I might understand these programming methodolog (Score:2)
Unfortunately this is the root of the problem. Work needs to get done yet not all programmers are going to be enthused ab
Re:I might understand these programming methodolog (Score:1)
Our situation was: migrate existing functionality to a new platform (as the manufacturing of critical parts was being obsoleted) while introducing both improvements to the existing base and new functions at the same time.
The systems folks had a pretty good handle on this, however, having to wait for the better part of a year for the I/O drivers, execution and memory management pieces would
Doubletakes (Score:2, Redundant)
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...
Rebuttal (Score:1)
Re:Rebuttal (Score:1)
Re:Rebuttal (Score:1, Funny)
I found this under the link "Songs of the Extremos"
(http://www.softwarereality.com/lifecy c le/xp/extre mers.jsp)
Songs of the Extremos (Part One)
Imagine
Imagine there's no requirements. It's easy if you try
Just a bunch of coders, reachin for the sky
Imagine all the people, coding for today
Imagine there's no schedules. It isn't hard to do
No silly project deadlines, no one supervising you
Imagine all the people, coding hand in hand
You may say I'm an e
Rating mistake (Score:1)
I take the guess-work out of the buy/no buy decision by giving boolean-valued reviews
Re:Rating mistake (Score:2)
oh my oh my (Score:1, Troll)
Re:oh my oh my (Score:1)
I, for one, won't believe it until netcraft confirms it.
Bashing management practices (Score:5, Insightful)
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 (Score:2)
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... (Score:3, Insightful)
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
orka (Score:1)
Re:orka (Score:1)
I have looked and NEVER ONCE found any list of metrics by which the efficiency or effectiveness of any of these methods has been evaluated. It's all blowing smoke.
for a good story (Score:1)
Too much work (Score:5, Insightful)
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...
Re:Too much work (Score:1)
Re:Too much work (Score:1)
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...
Isn't that ultimately the point of these religious movements-- to fire up the believers to fever pitch so they work so much harder-- the specific dogma used being otherwise completely arbitrary.
Wow (Score:1)
hmm.. (Score:2)
I thought it was bink...am I missing my english slang here?
Re:hmm.. (Score:2)
Re:hmm.. (Score:2)
I am ashamed
Counterpoint to XP and other "agile" manifestos (Score:5, Interesting)
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.
Re:Counterpoint to XP and other "agile" manifestos (Score:2)
A true skeptic acknowledges that they don't have all the answers; the author didn't.
There are no best practices (Score:3, Interesting)
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 (Score:2)
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 (Score:2)
At the time of writing the best practice is
Layering!
Here is the proff. [all-technology.com]
L Ron Hubbard strikes back (Score:3, Funny)
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?
Re:L Ron Hubbard strikes back (Score:1)
I downloaded SCRUMVM... (Score:2, Funny)
Not dazzled by scrum (Score:5, Insightful)
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 (Score:4, Interesting)
my favorite development model (Score:1)
"death marches" (Score:2, Insightful)
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
Re:"death marches" (Score:1)
Self-organizing teams (Score:1)
Scrum has its roots in studies on self-organizing teams. That's why it does not prescribe working practices like collective code ownership, refactoring, unit testing, pair programming etc. It's left to the team to self-organize them if needed.
Historically Scrum is about 5 years older than XP. Therefore Scrum does not need to reflect on XP.
I think to really succeed with any agile methodology, be it XP or so
Anecdotal Evidence (Score:1, Insightful)
I worked for a team where their Director espoused "Agile Programming Practices", and encouraged "extreme programming" techniques for getting stuff done. As soon as I heard this, I smelled jargon-bullshit.
The fact of the matter was that the team leadership consisted of insular, nit-picky developers who were extremely poor intrateam communicators. They would pour out undocumented code full bore, and leave the non-leads to constantly pla
Why development methods matter... (Score:5, Insightful)
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... (Score:1)
I'll bite. Why do development methods make resounding success less likely?
Re:Why development methods matter... (Score:2)
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
Re:Why development methods matter... (Score:2)
As with all the other buzzwords (Java, XML, etc) Scrum is being used as a magic bullet. Oh, we don't know what we're doing, so we'll use Scrum and it'll be OK. If you've got good coders, a good manager and a strong vision of what the
Mass-produced software... (Score:2)
Software development is akin to furniture design.
Comment from the 1st reviewer (Score:4, Informative)
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:)
Re:Comment from the 1st reviewer (Score:1)
Ahem. (Score:5, Informative)
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. (Score:2)
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. (Score:3, Insightful)
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 (Score:2)
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
methodologies (Score:1)
I've always wanted to publish my methodology but could never find a publisher willing to publish a one-page book.
So, I've decided to publish it here on /. for free:
My Methodology
Find someone who knows what they want, find some people who know how to do it, put those people together in a room, and it'll get done.
Look for future URL for download.
an analogy from boeing (Score:1)
About two or three years ago, PBS had a documentary on how boeing was building its new airplane, a pretty large project with some severe failure consequences. A lot of interesting stuff, but the most pertinent were the sections where the camera sat in on a weekly status meetings. A person would say something like: " worked on the eng
I use Scrum and I like it (Score:2, Informative)
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
"salaried" != "slave" (Score:2)
Good grief! If, two weeks into a project, the developers are being admonished for not working over the weekend, I'd say the problem is with the manager's lack of planning skills, not the engineers' work ethic!! The old phrase "your lack of planning doesn't make it my emergency" comes to mind.
Except for true emergencies, planning for teams to regularly work weekends is simply asking for high employee bu
Re:"salaried" != "slave" (Score:2)
Programmers in many cases have become commodities. The dumbing down of code along with a complete lack of people who take pride in their code along with date driven rather than product driven applications has taken its toll.
Except for true emergencies, planning for teams to regularly work weekends is simply asking for high employee burnout and high turnover rates.
Agreed. Here is the
Damn (Score:1)
Seems to me... (Score:2)
Moo (Score:2)
To what book?
Re:Scrum? (Score:3, Interesting)
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:Scrum? (Score:1)
Re:XP couldn't finish C2 (Score:1)