

Implementing SCRUM - story of a Seedcamp winner - vladimiroane
http://blog.seedcamp.com/2009/02/its-all-about-education.html
How our team switched to SCRUM and why we believe it is important to have a development methodology when you are a startup.
======
sanj
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.

~~~
DanielBMarkham
I'd like to hear more about your agile experiences, if you like. My email is
in my profile.

~~~
alabut
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:

<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.

------
gruseom
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.

------
psranga
"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.

~~~
vladimiroane
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!

~~~
psranga
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.

~~~
vladimiroane
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.

------
biohacker42
My experience with SCRUM is that is sort of works for large organizations, but
it's not a magic bullet.

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
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.

~~~
vladimiroane
True but it works even for small teams. Once you are more than 3 people in the
team it makes a lot of sense to use Agile methodologies.

~~~
omouse
> it makes a lot of sense

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?

------
DanielBMarkham
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.

~~~
vladimiroane
True: it is framework not a methodology.My mistake.

~~~
moe
_It's okay to totally screw-up._

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.

~~~
DanielBMarkham
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).

~~~
moe
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 ...

~~~
DanielBMarkham
I'd be careful of overgeneralizing.

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.

