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.
Me too - I'm building a presentation on Agile Design (designers integrating into agile groups) and could use more research into other people's setups. My contact info:
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!
What I meant is that the SCRUM inventors are telling you in great detail how to run the technical side of a software business. Not that it's telling the developer how to implement something.
Not true. They give some principles and you have to decide how to use them. The same with GTD: you can use a pen and paper or an iPhone. How you do it depends on you.
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.
Coincidentally the two times I have seen SCRUM at work so far it was deployed precisely to serve as excuse for the constant screw-up. Neither of the companies seems to have improved over that year of colored post-it notes either. But the CTO and product managers since then have new buzzwords they can use to justify why they still miss milestone after milestone...
It's okay to screw up if you're continuing to improve. Sounds like these guys weren't.
I tell my PMs that I train that no, I do not want them to be the CSM. I want them to work strategically, to work on all of those organizational obstacles that get in the team's way. You can't change the world, but good agile teams are going to be constantly reminding the CTO and everybody else that certain constraints are killing team performance.
You can treat it like a fad if you want -- just throw new labels on old crap. But whether it's Scrum, Agile, or Bob's New Process, at the end of the day the teams must communicate back to the organization frequently about what's screwed up. And the organization must listen. Or you can just keep throwing money and fads at problems you won't acknowledge. Reality is reality. The reason you end up with poor understanding at the CTO level is because nobody has the balls to tell him what's really going on. That conversation is the toughest part of adapting in a nutshell (pun not intended).
Well, I sure hope someone uses these processes as they are meant and as you describe. This was not aimed at you personally, I just have never witnessed it.
In fact the words "Agile", "XP" and "SCRUM" have pretty much turned into red flags for me. My immediate reflex whenever someone feels a need to mention those to me is to bill by the hour - because anything else would probably come back and haunt me iteratively ...
Even in true management fads, there's usually a grain of truth in there somewhere.
Just don't be the guy who never picks up any new skills because 1) people usually misapply them, or 2) you had a bad experience. Everything is a tool in your toolbox. Lots of tools means lots of options.
I've found that even with "heavy" process overhead, like CMM or CMMI, if you talk to the developers they're supposed to be practical and make sense. It's the way people in companies apply these things that are usually at the heart of why they don't work. At the end of the day, it all gets back to people.
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.