Slashdot Mirror
Agile Software Development with Scrum
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.I don't know what any of that means and I'd be scared to find out.
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 it???
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.
Casual Games/Downloads
That was pretty indepth, rendering purchasing the book meaningless.
We need more reviews like that!
I first read scrum as scrotum and said "Finally! Programming with balls!"
Step away from the keyboard, I think its time for a break...
In the future, I would want to not be isolated from my friends in the Space Station.
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.
I've always worked on projects with SCUM--so that's what the problem was!
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.
In the future, I would want to not be isolated from my friends in the Space Station.
when the last time alan cox did some laundry was
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!
unless you are a cute female!
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
Defending IP by destroying access to it? That makes sense, RIAA/MPAA. Go to the corner until you can play nice!
It doesn't work well. Try doing a project of reasonable size. The XP team never finished their payroll system and Chrysler scrapped. Chrysler also banned the use of XP internally.
For a long time I didn't understand how half of the merits that are often brought up are to programming methodologies would occur. Then, I realized that I had just assumed all other people are like me: wanting to do their best job at coding and make sure it's code that will work and be maintainable for years to come. However, I've discovered that most commercial programmers don't care about the quality of their output; be it because they've burned out, don't know what they're doing, or whatever. The idea behind these methodologies is to make a sacrifice a calculated amount of potential overall productivity to make sure that the team "leaders" can either (a) identify more easily those "bad" programmers or (b) make sure the programmers aren't bad because they have someone watching them and discouraging laziness.
;). Heh.
So, for those of you who don't understand the hype either: remember that not all programmers are as good as you might be.
I'm half joking, but only half
In return, we get the Daily Sprint Meeting, the Sprint Goal, the Sprint Signature, and the emphasis on decision-making by the Scrum Master.
Scrum masters and sprint meetings? I'd rather a motivational poster over my head and a bullet to my brain.
Makes all of the crap names with 'X's everywhere sound cool.
Scrum. What is it all about... is it good, or is it whack?
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...
Here is an article that discusses some of the downsides of XP and Agile methods: http://www.softwarereality.com/lifecycle/xp/index. jsp
The software development process is tricky to control, you are converting human intelligence (or stupidity) into bits.
;).
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
Should be 0 out of 1, not 1 - my mistake.
:)
I take the guess-work out of the buy/no buy decision by giving boolean-valued reviews
What really bugs me with these software engineering methodology books is that they seem to lack scientific rigour. A methodology should be empirically tested, right? I got the same feeling from XP when the sales pitch started...
-AC
Actually I prefer software developped for SCUMM, it's more entertaining. Remember Monkey Island and DOTT?
Extreme Programming is Dying!
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.
Are there any studies/graphs showing any real proof of which system works best?
s/sprint/sprite/gi
This is a whole lot of bullshit for techno wannabes. I've been developing software for nearly a 1.5 decades, and all I can say is process monkeys have ruined development. All you need are good software engineers with a passion for what they do, and the success is assured. Ever since this dot com scam, a lot of pundits have sprung up with methodologies that can place the blame on somewhere other than the process or the SCUM leader. Find a good team of developers who love their work, empower them by allowing them the freedom to experiment, and not restricting and tying their hands by hiding behind a process. When you have people who love their work and are good at what they do, you can achieve miracles.
can this scrotum run linux ably?
Yes its a rugby term, and I suppose its appropriate, because the best part of a scrum is when you put your heads together.
AC
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...
- In Capitalist America, law violates YOU!
A negative book review on Slashdot. This has to be a first.
everyone did
oh great, the whack troll is at it again? shit, time to get out the GNAA posts
...moistened-bint-lobbing-scimitars dept....
I thought it was bink...am I missing my english slang here?
So rise up, all ye lost ones, as one, we'll claw the clouds.
Agile Software Development with Scum
Sounds like being forced to working on a Extreme Programming project with a slashbot. Or worse, with eurotrash!
Have been here the whole day. Where the fuck have you been?
Obligatory linkwhoring: The Skeptical Software Development Manifesto
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.
I've finally had it: until slashdot gets article moderation, I am not coming back.
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.
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?
...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...
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 about the project. It's a tough situation and the best managers know how to manage that. They should write a book on that.
Or maybe managers need to be more like Paul Sr. and just kick ass as needed.
The ratio of people to cake is too big
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.
for (int day=0;day != 14;day++)
{
current_project.design();
current_project.build();
current_project.test();
current_project.document():
}
"hey kids, lets put on a play"
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 constant attention to these, along with the necessary technical expertise to assess issues as they arise, the project will not succeed.
Furthermore, the team has to be treated with respect and consideration, not as chattel. Ignore this and not only will your project fail, but you'll shatter any hope of a unified team, and eventually lose your employees.
Facts are stubborn things.
I'm no Scrum expert, but I've been interested in software development methodologies for a long time.
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 something else, you need a highly disciplined and skilled team. With a highly disciplined and skilled team, you can succeed with almost any methodology. Then it comes down to the fun/sustainability factor: you should only use a methodology if the developers are willing to use it on the next project as well.
The relationship between Scrum and XP is very simple: Kent Beck was well aware of Scrum when he put the practices that became XP together on the C3 project, and he quite deliberately used most of Scrum as the higher level project management part of XP.
So the notion that Scrum is XP minus the software engineering practices is backwards. XP has often been described as Scrum plus those software engineering practices.
That description makes both the XP and Scrum experts wince, but it's a good comparison for a quick overview.
At the Atlanta XP meeting in January we're going to have a Scrum and XP comparison from one of our members that's just come back from the Scrum Master class. He gave us a few interesting tidbits in December. One of them was that (IIRC) the reason Scrum doesn't recommend shorter iterations is because it doesn't have executable acceptance tests! That's supposedly direct from Ken Schwaber.
John Roth
A Scrum master and an apprentice.
In the time it took you to write that review you could have finished your coding work.
(Posted Anonymously to Protect the Fragile Egos of the Parties Named)
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 play catch-up. Informal meetings were pissing matches, and frequent interruption was a way of asserting one's dominance.
I left, because I wasn't learning anything from those who weren't willing to teach, and I couldn't operate in an environment so driven by cults of personality. I wound up finding a nice small team that spent time going through code bases, doing real code reviews, documenting and properly testing features and functionality. In addition, these guys were humble and a pleasure to interact with. As part of this new team, we produced one of the most polished and functional products I've ever worked on.
Last I heard, the "Agile Team" that I left was bleeding money from their parent like a stuck pig, and hadn't released a product in almost two years, with several intermediate products canceled.
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?"
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"? Now a review of THAT could get some good chatter going:)
*** Sigs are a stupid waste of bandwidth.
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.
Scrum...diddely...umptious.
Hi
I have a eigenpoll for comparing the
best books on Agile software Develoment
here
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
Teach Yourself XP in 24 Hours
XP Examined
XP in Practice
The CRC Card Book
XP Perspectives
It's not that managers need to develop buzzwords and buzzconcepts in order to feel productive, it is that they are always trying to solve problems at a higher level of abstraction. They are trying to solve probelms in general instead of the specific problem they have.
The most important knowledge a project manger needs is "a lot of". Project managers need a lot of knowldege and a lot of experience. When confronted with a *specific* problem in a specific context, a good manager will take little pieces from their knowledge and experience and totally rework them to get what works for the process under consideration. The end result will look nothing like any standard, be it waterfall, iterative, xtreme, rational unified, or scrum.
The problem with meta-magnagers is they want to codify experience into a product, abstracted from the actual project managers who are good. But you cannot do this -- the quality is in the product manager, not in the processes that the manager uses for a specific project.
Large software development is not just a matter of having programmers that are "wanting to do their best job at coding and make sure it's code that will work and be maintainable for years to come". It's about having all that talent working together in an efficient and sustainable manner. XP (and other agile methodologies) help put a framework around the uniqueness of those talents in a manner that is both tolerable by the technicians and workable for the customer/project manager. It's a decent middle ground between letting the programmers work solely when their muse calls, and the overbearing, measure each keystroke control that the PMs want. And best of all, it embodies the very qualities you want in a team such as trust, communication, responsibility, cooperation, and thoughfulness. And it addresses the major factors that contribute to programmer burnout; impossible hours, impossible deadlines, and processes and procedures designed to cover some PHB's butt without consideration for the impact on the project or one's soul. So XP isn't perfect, but it's way better than traditional programming in any number of ways.
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.
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 product to test, design criteria to test the product, and statistical analysis to determine if there was a problem. It was all existing theory, mostly developed by Western academics, but Japan was one of the first places where they could actually get management to put the theory into practice.
I wonder if programmers would be less critical of ideas like XP if Control Theory were a required course for a Computer Science degree. That class gave me a huge respect for feedback loops, constant sampling, and finding proper and measurable metrics to gauge improvement.
That is worng!
;-)
At the time of writing the best practice is
Layering!
Here is the proff.
Scrum is a painfully idealistic system that, if implemented perfectly and followed to the letter, might work okay. That's really hard to do. As many folks have noted, it often happens that developers are forced to work long hours, management changes their minds behind everyone's back, etc. etc. etc. In our case, many of these things happened and scrum simply served as a way for the management to feel better about micromanaging projects. Unfortunately, Mr. Schwaber was completely unable to stick to his own rules: projects got miserably out of hand, developers worked 80 hours weeks, communication between management and the developers faltered, and sprints were all but ignored.
Scrum's one positive contribution to the development group was to increase communication between programmers - in that, it succeeded.
So. There are some okay things about scrum, but it's pretty hard to get right, and pretty easy to screw up while you think you're doing the right thing. And, if you decide scrum is right for your company, it's my recommendation that you don't hire Ken to implement it.
It also has connotations of chaos, or at least lack of rigid organisation. In the UK, after a night in a busy nightclub, you might say 'It was murder getting a drink, there was a real scrum at the bar'.
"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"
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 engine mount. No progress; problem with titanium cracking at temp. Looking into heat treatments".
and for this large project, one had the impression that the mtg was really short.
I don't know if the software writing field has anything to learn from good manufacturing companys, but in the biomedical (pharma + biotech) research, we certainly feel we can learn a lot from boeing and motorola and toyota
About four years ago, the MD walked into the development room at the software house where I worked, fresh from a Microsoft briefing on a new, all-encompassing technology you may since have heard of. For some reason, he was curious about the technology we used to connect various parts of our application together, particularly over the Internet. "Do you use .COM?" he asked. "It's very good, you know."
:o)
I don't work there any more.
And the 8-man puts his his head up the second row's asses.
I'm one of the ppl that get to go to two scrum meetings a day. Seems great on the surface, but morale, quite frankly, sucks. Everyone on my development team feels like they have no opportunity to think, and problems tend to go for long periods of time unaddressed, since the groups tend to act more like military units following a design plan than committees trying to get the job done...
So in our company, using the scrum model has actually made the process worse... certainly not a magic fix by any stretch.
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 the best we can in the time given to a project.
The best part of Scrum is that we have a someone that can stop outside distractions and let me do my job. That is what the ScrumMaster does the best. If someone wants to change something or pull me off to do something else, I can defer it to the ScrumMaster. A single point of focus to keep the team on the right project and outside distractions to a minimum. The ham and eggs analogy is great to explain this idea.
And daily sprints do not mean I cannot work on a piece of the project more then one day. I just have a daily focus and work to reach a conclusion.
Testing is part of any good development and I never understood why you had to spell it out in the methodology anyways. overkill in my opinion
I really don't care what you call the idea of Agile Development or claiming to use the latest and greatest XP or Scrum. But I have about a fourth the worthless paperwork and meaningless meetings with a simple focus because we use Scrum. And that lets me do my job and actually create something with a focus and be able to adjust each 30 days to deliver the correct product. The funny thing is I don't think a single manager knows that we actually use Scrum but we are far more effective for doing it.
And if you were looking to match it to XP then you could match even the waterfall method. And didn't an earlier post mention that Scrum was developed about 6 years before XP so which is a breakoff. My guess would be XP.
We used this method to support a more rigours production process when time constaints made things otherwise impossible.
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 have put us in a very bad position (compared to competitors who were not suffering obsolecence...).
We used a SCRUM team to initialize the new hardware and start with a planned introduction of I/O drivers. Our initial execution manager was trivial and memory management static.
This allowed us to get something to the systems folks "asap". While they (the systems folks) were getting thier algorithms in place and tuned, we would then review our installed code, identify weakness in style and make improvements for maintenance and robustness.
Then another I/O driver or two and turn the cycle again.
Eventually the system integration became difficult (and needy) enough that we worked on memory and execution managment as well as power-down and other (not RUN=NORMAL) tasks.
This model worked very well for us.
Of course we had experienced people who could handle the
a) "just get it work at all"
followed by
b) "rigourous requiremnts"
followed by
major revision.
None of which would have been possible without management "buy-in". That is to say, most of the XP (or SCRUM) efforts that I have had experience failed to see the light of day.
This one, however, took to the delight of (most) everyone concerned.
>>"Day 16-17 The team is discouraged by all the work remaining and didn't work during the weekend."
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 burnout and high turnover rates. What ever happened to the notion of treating programmers like respected professionals instead of so-called "resources?"
I honestly have to say that the review of the book already bored me to death. Maybe I'll order the book as a nightcap...
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 then hire a couple random doctors through an agency.
The problem with this model of programming is that it puts too much emphasis on "where are we going next" instead of "how do we make what we have more stable than it is already". While both of these are important facets of a successful project I feel that this system has a tendency to overemphasise the former without due regard to the latter - new features are easy to quantify whereas stability is more difficult. This seems likely to give rise to the "Microsoft Outlook" syndrome where you end up with a piece of software that can do everything that can feasibly be expected of an email reader, but has very serious flaws both in implementation and ideology. I don't believe this is inherent in the "scrum" methodology but I do think that the centring on too-regular team meetings will cause over-focus on featurism at the expense of QA and stability checking. At best, it will take a stronger team leader to keep a "scrum" project on course than if it were developed by other, less short-term-goal-focussed means.
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
The software equivalent to mass-produced furniture is an automated CD-burner.
Software development is akin to furniture design.
In the same way that Sophia Loren is more than a girl and a Porche more than transportation, Scrum is far more than the practices, terminology and rules that were extracted from the book. Scrum and XP are both based in agile values and are complementary, while addressing separate problems in development projects - Scrum addressing management and XP addressing engineering. I regret that someone who has clearly never used Scrum interpreted it based on a sterile reading and distillation. Someone more knowledgeable would have provided more value analysis and shown how XP and Scrum successfully interoperate and when they need to. ... author and advocate
Ken Schwaber
I hate scrum. Many methodologies suffer from staleness, from a lack of involvement after the initial design phase and until the next iteration. Scrum tries so hard to get away from that, that it becomes intrusive. Daily meetings, no matter how short, are a waste of time, especially since a lot of the real discussion will be going on in the defect tracking software or e-mail, anyway. It doesn't work well with telecommuters or people who just can't make it to meetings on a regular basis. And if you get rid of the daily meetings, it's not all that different from XP.
So fuck scrum. And, for that matter, fuck most every other methodology. We use iterative models so our software can adapt to real world conditions. It seems kind of strange, then, that we build up these inflexible systems for people to live under. A little structure is necessary, of course, and controls are good (since software development, especially on government contracts, is a huge gamble). But there's such a thing as too much of a good thing.
Plus, I want to work overtime. I want crunch time. Some of the best code I've written has been under deadline pressure. Sometimes I'm in a zone and need to keep at it.
I completely misread the title of that post.
We use scrum, and it has been working for us.
... sure more features could have been added but the code quality would have suffered. The product owner must understand this.
We've been using it for about 6 months, and so far only the last sprint (right before the launch) turned into a death march, and even that wasn't too bad (compared to other places I've worked). During the other 5 sprints most of us worked just regular hours.
Scrum, I think, can succeed if the team had good chemistry. If egos or personalities conflict, then I can easily see some of the problems in the article arising -- little refactoring occurs, little code fiefdoms arise, etc. But in our team this has not occurred.
For example, a large refactoring ended up being a placed into the sprint backlog during one of the sprint planning meetings. The product owner was willing to accept this 60-hour item, because we insisted on it. If the product owner doesn't accept these arguments from development, or doesn't have a good communicative relationship with the team
So, if the team is has a good working chemistry (including, maybe especially, the product owner), then scrum seems to work. I would not be surprised if it failed if this were not the case.
--Kirk
"Then, I realized that I had just assumed all other people are like me: wanting to do their best job at coding and make sure it's code that will work and be maintainable for years to come"
When I first started my most recent job, I had a vision like this also. Then I discovered our log downloading was a blind shell script. With no detection for either missing logs or half-downloaded logs. Then I discovered that the PREVIOUS iteration was ALSO a shell script, only in a slightly different style (but still hard-coded addresses and such). Then I discovered the system BEFORE that was a series of RSH commands, also blind, also hardcoded, AND completely replaced for no reason whatsoever.
I was horrified. It was awful. Totally against everything I believed in. My job was cut out for me: The hours of checking for missing junk had to go!
I implemented over a few days a Perl-based downloader that had the following features:
- "+EOF" check to determine that the whole log was downloaded (a simple change to the webservers' rotate logs script)
- Additional checks to see that the download command didn't abort with an unusual error level
- Basic download throttling. It's a lot faster downloading 6 logs at once rather than 384 at once.
- Easily updated text configuration file (never made the CGI to administrate that, but it was dead easy in VI anyways)
- Descriptive variable names and clear processi within the script
- External documentation which included justification for all features employed as well as explanations of optimizations and whatnot
- Detection of changes to the domain names for the websites that may indicate that additional servers were added (or removed) from a given domain
- Support for multiple download protocols (SSH and FTP implemented initially)
- Support for a "download caching" area, as the hardware of the time was a big, faulty raid array that topped out at 250k/sec effective write speed (adding a 36G drive to download one day's of logs helped tremendously, and the logs could then be gzip-piped over to the dog slow raid at a reasonable rate (2.5 megs/sec effective with gzip))
To make a long story short, this system was everything the predecessors' systems were not: Elegant, extendable, maintainable, documented, fast, but (leaving out the configuration file) short. I no longer had to hunt for hours to find missing logs or run manual checks and harass system administrators to figure out if any hosts had been added/removed from domains, etc. Everything ran smoothly, and I had little to do but sit, relax, and try not to laugh at management's horrible new ideas. Any inebriated monkey could manage the new, improved system.
Unfortunately, as I was no longer critical to the operation, and an inebriated monkey was a bit cheaper than my paycheque, management gave me the old heave-ho.
I guess the previous maintainers who wrote poorly maintainable, useless code knew something I didn't.. doh!
Fuck I miss the days when programming was an obscure occupation.
o because my reaction to this book
To what book?
Have you read my journal today?
There are some more reviews of this book here.
This review is inflammatory, and (worse) inaccurate. Why not read about Scrum for yourself, and see if it strikes you the same way? The following site has been set up by Schwaber and Beedle, so the content matches the reviewed book: http://www.controlchaos.com Personally, I wouldn't want to work in most non-Scrum shops... (once you switch, you can never go back) Submitted by debhart 3 years' experience with Scrum