[PLUG-Devel] Scrum anyone?

[vodhner at cox.net]

Alan wrote:
> So, who here uses scrum?  What is good?  What is bad?

We use scrum.  The good part, that is.   ;-)

As Darrin's exellent "rant" pointed out, no Silver Bullet [TM] solves all the problems.  But some of the ideas involved in "scrum" -- or, some of the ways these ideas are presented -- are definitely useful.

Two of Darrin's points apply directly:

> * You MUST reduce complexity somehow. 

Short sprints, whose results go directly into the product, allow developers to target specific and achievable goals.  In our case, the overall product is hopelessly complex, since it embodies years of largely-forgotten business knowledge; and  yet I think this approach makes each piece of work less complex and better focused, and also helps us to quickly discover unintended consequences and interactions.
 
>  * Get feedback as soon as possible to find errors
> and extract hidden requirements. 

Again, pushing results into the product as immediately as possible helps to keep the customer close to what you're doing, so the customer can straighten you out before you've wasted too much effort on doing the wrong thing.

Where I work, management has officially adopted scrum as the way to pursue not only software development but also deployment and some special projects.  It is questionable whether all of these concepts could be implemented in any one shop, or in the same way from project to project, but some of the basic features of scrum are definitely in play here.

Our main business is an ASP service.  We develop our own software and then run it for our customers.  We came out of a cumbersome "process is everything" waterfall regime that held us back for a few years.  Customers told us they needed more responsiveness, and needed requested features to be in place more quickly.  Scrum was the answer, and it's supported by top management.  But it's not pure, textbook scrum, since we're a moderate sized operation and we have to keep a lot of squeaky wheels turning smoothly and can't risk disruption.

We work with a combination of heavy legacy software, mostly in C; some younger but well established java systems; and a lot of new development being done mostly in java, answered by adjustments in the C code.  We have not always had the luxury of well defined requirements in advance; so we need to be light on our feet to get things done.  

A "sprint" is a limited-length period during which certain things are to be implemented.  Product/Portfolio managers define the goals for each sprint, with a mix of new development and defect fixes.  During the sprint, project management is not supposed to move the goalposts, but they have had to do that several times.  In exchange, our manager tells them bluntly what they're going to give up for making us change course.  We are encouraged to speak plainly in such situations.   ;-)

I just hit on one of the basic points in any "system":  there are rules, and unless top management is willing to support them the system will fail.  So the key thing that's happening in our case is that certain rules are subscribed to, from the COO right down the line, so that any digression from the rules (which becomes necessary from time to time) is clearly recognized and opens the door to negotiating a rational response.