Mar 072010
 

Scrum, as a framework, is practiced in many different organisations and can be considered a mainstream approach to software development. To me agile is way of scaling common sense and while I no longer practise Scrum I consider it an excellent implementation and would happily return to it if my circumstances were better suited to time boxing. However as with all great ideas that are adopted widely, there are many instances where people are simply doing it wrong.

Warren Buffett has a neat way of describing this:

First come the innovators, who see opportunities that others don’t. Then come the imitators, who copy what the innovators have done. And then come the idiots, whose avarice undoes the very innovations they are trying to use to get rich.

In the case of software it’s reasonable to replace the goal of getting rich with that of successfully delivering software that is valued by the customer.

As such there are a wealth of posts discouraging the adaption and variation of Scrum, in fact the notion of Scrumbut is so well understood it even has a definition.

scrumbut [skruhmbut] noun.
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenents of the SCRUM methodology.
4. In general, one who uses the word “but” when answering the question “Do you do SCRUM?”

Project management will necessarily vary from company to company. As such the ubiquity of a term like Scrum has less value within a specific company, since the shared understanding of the company’s approach ought to be evident to all. When I talk to people outside of my company it’s useful to reference commonly understood terms as a starting point. For time boxed approaches Scrum is an obvious point of reference, but the specific system that I wish to describe is highly likely to deviate from Scrum in some way and I do not necessarily see this as a bad thing.

The challenge of software development is to produce something that someone will find valuable. There are plenty of different ways to achieve this and all are highly dependent on the context of the project. Generally an iterative and incremental approach that bakes quality in from the start is preferable and a number of ready made implementations exist such as Scrum, Kanban or Evo. In some cases it may be appropriate to lift something like Scrum wholesale, but in many other cases, there are legitimate reasons for adapting the process. For example a team might be writing an implementation of a system where the behaviour is well understood. In fact in order for the system to be compliant and therefore usable it must adhere to a large pre-written spec provided by an external party. Clearly this is at odds with Scrum but there is no need for the team to drop time boxing or stand ups as a result.

So adapting a process is not in itself something to be frowned upon. Clearly bad project management is bad, and if the manager blames their own failings on their inability to implement a methodology then larger problems exist. The key point is that good managers should not worry that they are running Scrumbut, or indeed if they are ‘doing it right’ as the only metric for correctness is that the team maximises the value they create.

  5 Responses to “In Defence of ‘Scrum but…’”

  1. Scrum is a *framework*, not a methodology.

  2. Interesting perspective, but… (Just kidding!)

    In many ways, agile is common sense. Unfortunately, common sense is sometimes uncommon. My take is that Scrum defines a simple set of protocols for teams to manage and monitor work. By understanding and using Scrum, you avoid re-inventing the wheel. And many other things are still up to the team, like determining which technical practices will be used. The Scrumbut problem comes into play when people discard the very things that can maximize their benefit and productivity – without understanding what they are discarding.

    “For example a team might be writing an implementation of a system where the behaviour is well understood.” Isn’t this very rare, and given the difficulties with many software projects? The norm in my experience is that some behavior is discovered during the act of designing and developing the software, hence the need for collaborative teams (like Scrum teams.)

    I do share your concern that you don’t want to get too process-focused. In situations where “process is the thing,” many other important aspects of software development get overlooked.

  3. @Dave Moran

    “For example a team might be writing an implementation of a system where the behaviour is well understood.” Isn’t this very rare, and given the difficulties with many software projects? The norm in my experience is that some behavior is discovered during the act of designing and developing the software, hence the need for collaborative teams (like Scrum teams.)

    I would say that in general this is rare, but was taken from a real example of something that I am working right now. There is still uncertainty since we have a functional spec as opposed to a design but the value of fortnightly feedback from a product owner, say, is diminished.

  4. @Anonymous, you’re right – updated accordingly, though hopefully it didn’t confuse the message of the post for you.

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>