Back in 2007/2008, I was working at a startup. It didn’t go well. Here is one of the rants I wrote.
The backstory: I had been advocating using Scrum to help us manage what was an increasing amount of scope creep, release pushbacks, and the assorted problems that come from running a startup half cocked.
The other devs and I were trying to manage the chaos by keeping each other up to date and every few days looking at the list of work items (because we didn’t *quite* have a backlog… except we kind of did). This list of items was even divided into releases (does that sound like a sprint backlog to you?). We tried to keep each other up to date on an almost daily (… daily scrum?) basis. So why didn’t we go the last few steps and actually jump on scrum?
Lack of management buy-in. The founder gave lip service to trying out scrum, threw me on the spot to present it to everyone during a weekly status meeting (after previously shutting me down on it), then promptly didn’t bother to try to fill the scrum master role (and he was really the only one empowered to do it).
Anyways, that turned into a separate rant, but here is my at-the-time griping about the startup:
Back in the dark ages, when people talked about “Process” in software development, they meant Waterfall. A lot of people that learned to be programmers in the 90s and earlier have this idea that process is all this hideous up-front work, regimented development, and tons of overhead during the entire escapade. They fear process. They think it slows them down and that they are smarter and better than big companies because they use an ad-hoc development procedure that basically consists of throwing man-hours at a problem until its solved, but hey it achieves some results sooner than the big company because they just finished their detailed design phase and are beginning development.
See, the thing is, the idea of process has come a long way since the days when waterfall was the only model. There are enough different process models that nobody really has an excuse to throw away effort in the name of moving quicker. If you really want to develop quickly and be responsive to changing requirements, try using one of the Agile methodologies like Xtreme Programming or Scrum. Scrum is really really nice. It emphasizes communication and just a smidgeon of organization without forcing 10 tons of documentation for each decision or development action.
Would you rather be on a team where nobody talked to each other, people were randomly assigned bugs with no regard to their strengths but merely their availability to do something, no thought was given to scoping features so last-minute additions cause releases to slip a week or more from their hopeful schedule, and planning is discouraged because its more important to get broken functionality there to fix later, and sometimes people don’t even know a release is planned to happen overnight until they are chastised going out the door that night? Or one where releases are expected on a 2-4 week regular cycle, developers take on responsibility for the features they choose and believe they can complete in the cycle, people take a little time to plan their work, and everyone meets daily for a few minutes to talk about where they are and what problems need to be addressed so everyone is on the same page? That’s the difference between Scrum and nothing.
Hmm. A little bit of time to communicate with everyone, every day? A half-day of planning every 3 weeks? Nooo! Run! It’s process!
Yeah, scrum is hard without management buy-in: because management will do things the way they’ve always done it:
“Let’s figure out all the requirements first! Then implement! Then test!”
Where as scrum is Agile…