Implementing SCRUM - story of a Seedcamp winner
blog.seedcamp.com
How our team switched to SCRUM and why we believe it is important to have a development methodology when you are a startup.
blog.seedcamp.com
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.
http://alabut.com/contact.html
I've worked with scrum, agile and xp groups, and have been gathering feedback on real world pros and cons.
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.
"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.
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!
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.
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.
No it doesn't without proof. Can you show me proof that the methodology works when compared to others? Stats, studies, etc. where are they?
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...
YMMV.
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).
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.