I worked with Ken Schwaber while at my last startup. I'd be happy to offer insights, but not in a public forum.
It's also very interesting to see SCRUM being given credit for "quadrupled revenue in 2007" at PK: http://bit.ly/RsRNm
In reality, pretty much all of that revenue (~70% increase) was due to a single very, very big deal with HCA: http://bit.ly/Rtq7i
That particular deal was based on a project that I identified, prototyped, developed, installed, refined and then went on the road to sell.
I can categorically say that it had very little to do with SCRUM and much more to do with a tremendous (and very small!) team of three that I had the privilege of working with who helped in identifying a fallow market, building a great product, and marketing it well.
I'm surprised that a startup would even consider following one of these processes. They are responses to the organizational constraints of corporate software development (and its symbiotic relationship with big-name consultants). A startup isn't, or shouldn't be, subject to those constraints in the first place. So a startup that feels the need for such a process seems likely to have more fundamental problems than a process can fix.
I don't mean to criticize anything that's genuinely working, and one can't tell much about a particular situation from a blog post. But all other things being equal, I'd say something is wrong.
Edit: I missed this from the original article and just read it in another comment:
The development team is run by a project manager. His role is to move the top priority user stories from product backlog to the sprint backlog and break them in atomic tasks that are distributed to your developers.
Is this a joke? This is not only ludicrous behavior for a startup, it's the very opposite of the process this startup has supposedly adopted. I take back "one can't tell much about a particular situation from a blog post". This says a great deal.
"You separate the business from the development. You need a product guy, interested in features that will move the product fwd. He is called the product owner. He keeps a file (an excel works best) - a product backlog - with all the features, called user stories. They are organized by priority. The development team is run by a project manager. His role is to move the top priority user stories from product backlog to the sprint backlog and break them in atomic tasks that are distributed to your developers."
"break them into atomic tasks": I didn't think this sort of hyper-specialization would work in a fast-paced environment. It seems to treat developers as just English-to-C++ translators.
My experience has been that specifying in great detail HOW to do things (as SCRUM does for s/w development) doesn't work as well as specifying WHAT to do and letting people figure out how to do it, but holding them accountable for results. The latter style will naturally result in the evolution of automated systems such as regressions, quantitative user feedback, beta progam etc to ensure that the work got done and quality is maintained.
One should have some structure and avoid reinventing the wheel, but I'm skeptical of detailed recipes like this.
My experience has been that specifying in great detail HOW to do things (as SCRUM does for s/w development) doesn't work as well as specifying WHAT to do and letting people figure out how to do it, but holding them accountable for results.
This description of Scrum is so wrong that it couldn't get wronger. Scrum says: the product owner says what they want, the team decides how much they can deliver in a month, then they go off and do it however the hell they choose. After a month they come back and demonstrate what they got done, in the form of working software and only working software. The stakeholders then get to decide whether they like the progress that's been made and whether or not to continue for another month. Nobody gets to interrupt the team while they're working and nobody gets to tell the team how to do their work. That's the heart of Scrum. You can see it's much closer to the opposite of how you described it.
But then I noticed that you were merely responding to this, which is obviously where the wrong idea came from:
The development team is run by a project manager. His role is to move the top priority user stories from product backlog to the sprint backlog and break them in atomic tasks that are distributed to your developers
This is risible. If that's what they're calling Scrum, I fully share your skepticism. It's the essence of the failed approach that Scrum was a reaction against.
When all the developers are the founders your approach will work. If you have a different dev team it is very very difficult to make your team so dedicated as you are. I think we have such a team but still having a system to put all the user stories on the same page and see how the team is moving helps a lot. If you reduce Agile to hyper specialization you loose a lot. It helped us a lot by:
- defining what Done means
- setting goals so we can release something new every 2 weeks
- measuring our activity: what doesn't get measured doesn't get managed
etc
And it is not about telling people how to do things. They decide how to do it, how long it takes etc... So I think you either got that wrong or I explained it badly!
Well, I'm a solo developer, so I've only kept agile strategies at the edge of my radar, but they've certainly persuaded me to keep aware of the issues... for that hoped-for time when I need to be part of a team.
Great to hear a new Scrum convert and the difference it can make in a team! (startup or otherwise)
Couple of notes from an old Agile guy:
1) The Product Owner goes away with a startup. Everybody is representing the business. The P.O. idea was always an oversimplification anyway. In reality you have to adapt. (This is true of all of this)
2) You don't have to plan every task. Some teams do, some teams don't. Stories are hunks of business value that you can deliver inside a sprint. Tasks are what you do to make stories happen. If you can grab a story and deliver it, tested and approved, without decomposing your story into tasks? Good for you. I say go for it. But it's a team decision. Some folks are just more detail-oriented than I am. All I care about is getting the value to the customers.
3) It's a framework, not a methodology. Scrum is a PM framework around Agile principles. It doesn't tell you how to do things, simply the process for keeping track of your team's to-do list and executing on that list. It's all goodness and wondefulness, sure. But it's not the end of world hunger. Just some nice rituals to keep the team on-track.
4) The most important part of Scrum, or of agile for that matter, is to adapt. It's okay to totally screw-up. What I want to see is a team that is constantly improving their ability to deliver value. Whatever you read in a book or see in a seminar, you have to own and adapt it for your use. I've found that many folks get the idea of "process is evil" and then start to use cookie-cutter processes for their agile teams. Ouch. All of those rituals like stand-ups, showcases, retros and such? They're there because over time we believe that most software development teams will adapt to use some form of them. So start with them for a few cycles, then change it up.
5) Because of all of this, there is no conflict between Agile principles and startups. In fact, every startup I've seen that was successful was in some fashion agile. Startups are about providing perceived value to the customer quickly. Agile is about providing value to the Product Owner quickly. Unless you screw it up, it's the same difference.
If you haven't looked into it, I'd give some agile concepts a look-see. Even when I sole-developing I use a backlog, sprint, "done", etc. Not because I'm a fan, but because it is just the best way of working.
[+] [-] sanj|17 years ago|reply
It's also very interesting to see SCRUM being given credit for "quadrupled revenue in 2007" at PK: http://bit.ly/RsRNm
In reality, pretty much all of that revenue (~70% increase) was due to a single very, very big deal with HCA: http://bit.ly/Rtq7i
That particular deal was based on a project that I identified, prototyped, developed, installed, refined and then went on the road to sell.
I can categorically say that it had very little to do with SCRUM and much more to do with a tremendous (and very small!) team of three that I had the privilege of working with who helped in identifying a fallow market, building a great product, and marketing it well.
[+] [-] DanielBMarkham|17 years ago|reply
[+] [-] gruseom|17 years ago|reply
I don't mean to criticize anything that's genuinely working, and one can't tell much about a particular situation from a blog post. But all other things being equal, I'd say something is wrong.
Edit: I missed this from the original article and just read it in another comment:
The development team is run by a project manager. His role is to move the top priority user stories from product backlog to the sprint backlog and break them in atomic tasks that are distributed to your developers.
Is this a joke? This is not only ludicrous behavior for a startup, it's the very opposite of the process this startup has supposedly adopted. I take back "one can't tell much about a particular situation from a blog post". This says a great deal.
[+] [-] psranga|17 years ago|reply
"break them into atomic tasks": I didn't think this sort of hyper-specialization would work in a fast-paced environment. It seems to treat developers as just English-to-C++ translators.
My experience has been that specifying in great detail HOW to do things (as SCRUM does for s/w development) doesn't work as well as specifying WHAT to do and letting people figure out how to do it, but holding them accountable for results. The latter style will naturally result in the evolution of automated systems such as regressions, quantitative user feedback, beta progam etc to ensure that the work got done and quality is maintained.
One should have some structure and avoid reinventing the wheel, but I'm skeptical of detailed recipes like this.
[+] [-] gruseom|17 years ago|reply
This description of Scrum is so wrong that it couldn't get wronger. Scrum says: the product owner says what they want, the team decides how much they can deliver in a month, then they go off and do it however the hell they choose. After a month they come back and demonstrate what they got done, in the form of working software and only working software. The stakeholders then get to decide whether they like the progress that's been made and whether or not to continue for another month. Nobody gets to interrupt the team while they're working and nobody gets to tell the team how to do their work. That's the heart of Scrum. You can see it's much closer to the opposite of how you described it.
But then I noticed that you were merely responding to this, which is obviously where the wrong idea came from:
The development team is run by a project manager. His role is to move the top priority user stories from product backlog to the sprint backlog and break them in atomic tasks that are distributed to your developers
This is risible. If that's what they're calling Scrum, I fully share your skepticism. It's the essence of the failed approach that Scrum was a reaction against.
[+] [-] vladimiroane|17 years ago|reply
And it is not about telling people how to do things. They decide how to do it, how long it takes etc... So I think you either got that wrong or I explained it badly!
[+] [-] biohacker42|17 years ago|reply
It's best use is as a conduit for the introduction of sane development practices like unit tests, systems tests, and continuous integration.
I remain very skeptical of SCRUM for small organizations.
[+] [-] CalmQuiet|17 years ago|reply
[+] [-] vladimiroane|17 years ago|reply
[+] [-] DanielBMarkham|17 years ago|reply
Couple of notes from an old Agile guy:
1) The Product Owner goes away with a startup. Everybody is representing the business. The P.O. idea was always an oversimplification anyway. In reality you have to adapt. (This is true of all of this)
2) You don't have to plan every task. Some teams do, some teams don't. Stories are hunks of business value that you can deliver inside a sprint. Tasks are what you do to make stories happen. If you can grab a story and deliver it, tested and approved, without decomposing your story into tasks? Good for you. I say go for it. But it's a team decision. Some folks are just more detail-oriented than I am. All I care about is getting the value to the customers.
3) It's a framework, not a methodology. Scrum is a PM framework around Agile principles. It doesn't tell you how to do things, simply the process for keeping track of your team's to-do list and executing on that list. It's all goodness and wondefulness, sure. But it's not the end of world hunger. Just some nice rituals to keep the team on-track.
4) The most important part of Scrum, or of agile for that matter, is to adapt. It's okay to totally screw-up. What I want to see is a team that is constantly improving their ability to deliver value. Whatever you read in a book or see in a seminar, you have to own and adapt it for your use. I've found that many folks get the idea of "process is evil" and then start to use cookie-cutter processes for their agile teams. Ouch. All of those rituals like stand-ups, showcases, retros and such? They're there because over time we believe that most software development teams will adapt to use some form of them. So start with them for a few cycles, then change it up.
5) Because of all of this, there is no conflict between Agile principles and startups. In fact, every startup I've seen that was successful was in some fashion agile. Startups are about providing perceived value to the customer quickly. Agile is about providing value to the Product Owner quickly. Unless you screw it up, it's the same difference.
If you haven't looked into it, I'd give some agile concepts a look-see. Even when I sole-developing I use a backlog, sprint, "done", etc. Not because I'm a fan, but because it is just the best way of working.
[+] [-] vladimiroane|17 years ago|reply