A friend of mine who briefly worked for Scribd once tried to convince me that Scribd enhances the experience of working with PDFs online because it offers better navigation features than PDF viewer plugins. I'm not convinced, but perhaps it makes it easier to understand the Scribd users?
I got a “old flash player” message. The fallback (download) link was a .docx. Not much better… considering it’s all text, I can’t see the reason it’s not, you know, HTML!
Okay, interesting post that left me with a "Well, yes and no" response.
The accusation is, that the "scrum master/coach" role in agile has gone from being an in-team activity to being a project management activity. I do think that is true. I also agree that Agile has become a buzzword that companies are adopting without truly understanding it (in the vein of http://www.halfarsedagilemanifesto.org/ )
But the reason Agile won't be killed is the same reason Waterfall hasn't been killed: it's the optimal choice in some scenarios.
(And before you sneer at Waterfall, go build me a nuclear power station with Agile).
I think the biggest problem is the naming. When I heard the title Scrum Master, I envisaged someone that was a master, someone with training - and yes, someone who runs the project. I recently read Succeeding with Agile by Mike Cohn and now understand it's just a role title - it's the person tasked with making sure scrum practices are used - regardless of how much scrum experience that person has - and is distinct from the project manager role. It really needs to be renamed - it's like a bad variable name.
I think it's referring to the sudoku TDD blog series that happened a few years back. Essentially, someone tried to implement a sudoku solver using TDD - and after several posts, never managed to finish. Peter Norvig then came along and wrote a short elegant implementation.
Some use this to say TDD - which has ties to agile - doesn't work. But most people conclude that TDD isn't a silver bullet and you have to know about your problem domain before diving in.
Ok, that at least makes sense. But ... sudoku is a puzzle - you don't (or at least I didn't) get there by iteration and testing, you get there by a flash of insight - "if I try searching like this, I might be able to end up with a solution to any sudoku board" and few hours later I knew I was right. In that way, it is unlike almost all large-scale software development.
Agile can't generate insight from nothing, it's not a silver bullet. But at least if you have some unit tests around your cool new code, you know that you won't accidentally break it later.
And before you sneer at Waterfall, go build me a nuclear power station with Agile
That would be interesting. Scrum says that your team should get themselves an appropriate set of tools and processes for the task at hand, and iterate, then inspect and adapt.
For a mission-critical lives-on-the-line software system, I'd imagine that there would be a lot of simulation and testing before the production release. Do you see a problem with that?
Except for the fact that almost everything we use was built with waterfall. From the CPU/GPU to the OS to my browser and most of my apps... almost all were likely built with waterfall.
Outside of a few websites, I don't think the full on TDD/Agile blitz has built much.
Those were the first 2 that I googled. I'm sure that some of them are not agile, most likely by default - e.g. the older Microsoft ones, before MS or anyone else discovered agile. But honestly, all you are doing is throwing out names of popular programs without any idea if they are agile or not, and then claiming success on the ones that no-body refutes.
After that behaviour, the burden of proof is on you - back each one up with references or go away.
It would be interesting if you found major projects that evaluated both agile and waterfall and still chose waterfall or deliberately changed to a less agile process, instead of the other way. Rather than just software written before the people involved knew what agile was.
Both projects you site have assets that are indicative of waterfall. Specs, designs, and dot releases.
The only TDD tests I've seen in either project are related to the language specs -- and there the specs were written first.
Agile doesn't simply mean shorter release cycles, although in both articles that's how its used. Iterative waterfall methods result in shorter release cycles.
The key diffs to know the difference:
1) Do you get requirements up-front for a release cycle? The length of the cycle doesn't matter. Can be 1 week or 6 months.
2) Do you have specs for the major features?
3) Do you design up front or do you write tests first?
4) Do you have a big test pass before release?
These are the main diffs in the way waterfall and agile manifests.
Honestly, the only people I know who use Agile are hacks. Every time I've seen anyone try to demonstrate it, it is a disaster. IMO, its the most embarrassing movement in software engineering.
I don't think that you know agile that well. If you define agile as "hacks" then it's no surprise that only hacks will match your definition of agile.
"requirements for a (short) release cycle" is a good description for a scrum sprint backlog. Scrum or agile does not say that you can't have "Specs, designs, and dot releases" in some form if you need them.
I use these specific definitions for agile as they are the ones that come up as real differentiators in practice. Of course Agile by itself is virtually a meaningless term that often simply means, "we're going to release more often", but really doesn't say anything about the SLC per se.
Confirm your examples. I want reports from developers saying, "We used waterfall to produce this software." You're the one making the claim, now produce some real evidence.
Why am I getting downvoted? Someone makes a claim without any support and gets upvoted, and I call him on it and get downvoted? Did reddit change its color to orange?
I agree with you totally, but maybe the wording or formatting was what people saw first. What works sometimes is not just calling "bullshit" on a shoddy post but going the extra mile that the shoddy post didn't.
I've always used the word "Agile" to describe a project management style that can move quickly and respond to change.
Becoming a certified scrum master and rigidly following the rules of SCRUM seems counter to this. Isn't the first line of the manifesto "Individuals and interactions over processes and tools"
Having said this, I should add that I believe even agile teams require strong leaders with a clear vision for the product, I'm not a fan of democratic software development.
This premise is a false dichotomy. Agile and the Waterfall development cycle are not binary opposites. If you take a waterfall and break it up into a number of smaller milestones, you start to get something that resembles the bare bones of Agile. If you look at a single Agile sprint, you will see a miniature Waterfall. Finding the balance point between these extremes for a project and a team is what makes "agile" work.
No, no, no. What you're describing is Barry Boehm's Spiral Model from the early 1980s. If you look at a single Agile sprint you should not see a miniature waterfall. In Agile, activities like requirements, design, coding and testing happen at the same time. This is the essence of Agile, and what separates it from the Spiral that came before.
How is it possible that you get requirements and code at the same time? Like I literally start writing code, while at the same time have a meeting with the customer to figure out if they want an accounting system or a CMS?
Because the customer has no freaking idea what the requirements are at the start of the project. That's always been the failure of Waterfall. You've never been writing code and suddenly thought of something that needed to be added to (or removed from) the system? Seriously?
I'm not sure how what you said is incompatible with waterfall/spiral. You can certainly add/remove/change requirements, but you don't start coding until you have at least a first pass on some subset of requirements.
Waterfall doesn't have multiple passes. You have to have all your requirements before you move on to design. And that has to be complete before you move on to implementation. That's why they use the waterfall metaphor, because waterfalls don't flow back up. And if waterfall seems completely braindead now, keep in mind that the old software guys used to be hardware guys, and it makes much more sense for hardware.
You're right about Spiral though... Spiral is iterative, so its much more compatible.
the only way that it can not have multiple passes is if the program is thrown away after V1.0. Any successfully program will be maintained and extended.
Because the customer has no freaking idea what the requirements are at the start of the project.
I disagree. to get a scrum project (or any project) going, you do need to have a vague idea of what you want (e.g. I want a website to sell my widgets online) and a few features for the next iteration (.e.g. List all the widgets. Take an order by email).
Scrum just says that you can inspect, adapt and iterate over that process.
They happen in parallel. You can be working on feature B while someone else is drafting a spec for feature C, and feature A is with the tester already. meanwhile the wishlist (features F, G, to ZomgPonies) is going onto the backlog in vague outline form for use in future iterations.
meeting with the customer to figure out if they want an accounting system or a CMS
That's an exaggeration. You seen some vision of what broad need the software fills before you start, and an initial backlog of high-priority features to get you going.
I think you'd find an agile sprint actually isn't a mini-waterfall at all. It'd be more accurate to say each story goes through its own mini-waterfall, but even that's wrong as the stages are almost completely different and not in the same order. For example, few teams write requirements beyond the story's acceptance criteria, specifications are almost never written, testing occurs throughout the lifecycle, and maintenance would come in the form of another story. They actually are very different methodologies.
I hit upon a pretty simple process a couple decades ago and it seems to work pretty well and doesn't require any fancy books, titles, lingo, paradigms, papers, etc.:
Nice. What percentage unit test coverage do you generally get? How do you deal with regressions introduced by bug-fixes? With technical debt? With requirements change and scope creep?
How much refactoring do you do? How big a team does this approach scale to?
46 comments
[ 3.4 ms ] story [ 102 ms ] thread--
EDIT: full text posted here: https://gist.github.com/710960
The accusation is, that the "scrum master/coach" role in agile has gone from being an in-team activity to being a project management activity. I do think that is true. I also agree that Agile has become a buzzword that companies are adopting without truly understanding it (in the vein of http://www.halfarsedagilemanifesto.org/ )
But the reason Agile won't be killed is the same reason Waterfall hasn't been killed: it's the optimal choice in some scenarios.
(And before you sneer at Waterfall, go build me a nuclear power station with Agile).
Or a sudoku solver.
Some use this to say TDD - which has ties to agile - doesn't work. But most people conclude that TDD isn't a silver bullet and you have to know about your problem domain before diving in.
Here's someone elses' blog post which includes links to both sets of posts: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
Agile can't generate insight from nothing, it's not a silver bullet. But at least if you have some unit tests around your cool new code, you know that you won't accidentally break it later.
Wasn't the point of Royce's paper that waterfall wasn't even suited to avionics?
I also like to ask about the specific (and testable!) assertion Brooks made in his most famous essay.
Anyone who can answer those questions well demonstrates a working understanding of project management.
That would be interesting. Scrum says that your team should get themselves an appropriate set of tools and processes for the task at hand, and iterate, then inspect and adapt.
For a mission-critical lives-on-the-line software system, I'd imagine that there would be a lot of simulation and testing before the production release. Do you see a problem with that?
Outside of a few websites, I don't think the full on TDD/Agile blitz has built much.
Stop using weasel words. Find real, confirmed examples or keep mum. "Likely" isn't worth a rebuttal.
Mozilla, Chrome browsers.
Android, iOS, and WinCE.
Word, Excel, Quicken, TurboTax, Photoshop, iLife.
Those were the first 2 that I googled. I'm sure that some of them are not agile, most likely by default - e.g. the older Microsoft ones, before MS or anyone else discovered agile. But honestly, all you are doing is throwing out names of popular programs without any idea if they are agile or not, and then claiming success on the ones that no-body refutes.
After that behaviour, the burden of proof is on you - back each one up with references or go away.
It would be interesting if you found major projects that evaluated both agile and waterfall and still chose waterfall or deliberately changed to a less agile process, instead of the other way. Rather than just software written before the people involved knew what agile was.
The only TDD tests I've seen in either project are related to the language specs -- and there the specs were written first.
Agile doesn't simply mean shorter release cycles, although in both articles that's how its used. Iterative waterfall methods result in shorter release cycles.
The key diffs to know the difference: 1) Do you get requirements up-front for a release cycle? The length of the cycle doesn't matter. Can be 1 week or 6 months. 2) Do you have specs for the major features? 3) Do you design up front or do you write tests first? 4) Do you have a big test pass before release?
These are the main diffs in the way waterfall and agile manifests.
Honestly, the only people I know who use Agile are hacks. Every time I've seen anyone try to demonstrate it, it is a disaster. IMO, its the most embarrassing movement in software engineering.
"requirements for a (short) release cycle" is a good description for a scrum sprint backlog. Scrum or agile does not say that you can't have "Specs, designs, and dot releases" in some form if you need them.
Confirm your examples. I want reports from developers saying, "We used waterfall to produce this software." You're the one making the claim, now produce some real evidence.
Once you prove your assertion, then I will present my evidence.
Yes, specifically because it was invented as a strawman to be knocked down. It was defined as a dead and useless development methodology.
No, please, be the bigger man and go first. heh.
Becoming a certified scrum master and rigidly following the rules of SCRUM seems counter to this. Isn't the first line of the manifesto "Individuals and interactions over processes and tools"
Having said this, I should add that I believe even agile teams require strong leaders with a clear vision for the product, I'm not a fan of democratic software development.
You're right about Spiral though... Spiral is iterative, so its much more compatible.
the only way that it can not have multiple passes is if the program is thrown away after V1.0. Any successfully program will be maintained and extended.
I disagree. to get a scrum project (or any project) going, you do need to have a vague idea of what you want (e.g. I want a website to sell my widgets online) and a few features for the next iteration (.e.g. List all the widgets. Take an order by email).
Scrum just says that you can inspect, adapt and iterate over that process.
meeting with the customer to figure out if they want an accounting system or a CMS
That's an exaggeration. You seen some vision of what broad need the software fills before you start, and an initial backlog of high-priority features to get you going.
1. observe/listen/read/question/collect-information
2. think (analyze, hypothesize, decide, etc.)
3. code (techically it is 'do', and the actual action varies by field, context and goal)
4. goto 1
How much refactoring do you do? How big a team does this approach scale to?
Business is a bunch of cheap pricks who don't understand the value of doing things right.