Tag Archives: scientific method

Agile as something you do

I have spent the last 2 evenings in Birmingham listening to talks by @diaryofscrum at @ScrumUK and @stevejpitchford at @bcsbrum about management and ‘Agile’ software development, which brought some of my own concerns into sharper focus, particularly about the Scrum framework. In many discussions with practitioners over the last couple of years, I’ve heard the following phrases:

“Agile is an adjective not a verb”
“Agile isn’t something you do, it’s something you are”
“Agile is a philosophy not a method”
“Agile isn’t a process”

Someone who ISN’T agile has to start somewhere. They typically need to DO something, to write software. Would we claim,”Scientific” is an adjective not a method? We wouldn’t, because it is both. The scientific method is a function which delivers what we call “scientific knowledge” as its value. If it didn’t, it would be pointless.

Managers are generally trying to get things done. Each team must agree its own Agile Operating Model (thanks to BCS’s ‘Agile Foundations’ book for that useful phrase.) What came out of the last couple of evenings was pragmatic application of philosophy. Many organisations take Scrum as a starting point, without realizing that “framework” is to be taken very literally. Scrum doesn’t paint the complete picture. It is (part of) a process to organize work. It says almost nothing about how to do that work. It is an alternative to writing a project plan “up-front”, when you know least.

An Agile Operating Model is a process which delivers a value, so it is a function. My scientific hypothesis is that it delivers valuable business function change, sometimes in the form of software. It is itself a business function. Agility has business functions as first class citizens. It doesn’t meet general expectations of a process because it can recursively self-modify. That doesn’t mean it isn’t one. As the kids say, “get you an agile function that can do both”.


Computational Science + Informatics = Software Development

1970s At university, I studied Physics and:

  • Computer Science

but it had very little to do with computers. It was far more about becoming a

  • Computer Programmer

1980s When I started work I heard about the increasing formalisation of the software development process and I wanted to be a

  • Software Engineer

1990s I’d moved into server management by the time I qualified as a

  • Chartered Information Systems Engineer

which fit in with my thinking that information is the important resource in any organisation but took me no closer to knowing how to make great software efficiently. I became disillusioned by watching people trying to apply the rigorous methods of hard engineering to the uncertainties and unknown complexities of software. I became interested in prototyping, incremental delivery and Agile.

2000s I was increasingly drawn to the idea that constructing software is a design discipline and that a software developer needed to be a

  • Software Craftsman

2010s After a few years working with an agile software team, I decided I wanted to try writing software again myself. A few weeks ago, an online MIT course on Python programming introduced me to an idea that I felt very comfortable with: a good developer is a

  • Computational Scientist (I’d settle for ‘Computing Scientist’)

and I’d add the option

  • Informatician, which overlaps with what librarians do now

Agile development processes are adaptations of the scientific method, to research what customers want and work out how to give it to them in the way that meets their opinion of best value, and I don’t see why software developers can’t be their own customer. Every great new software component starts off as someone’s experiment.