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

Advertisement

Practising your Process

My very sincere thanks to Simon Powers for posting the ‘onion diagram’ in his ‘What is Agile?’ post on LinkedIn and for answering my question. The post is also available on his own blog http://www.adventureswithagile.com/2016/08/10/what-is-agile/
It shows ‘tools & processes’ separate from ‘practices’. I’ve been thinking for a long time about whether there is any real difference between process (what) and procedure (how) or if they are simply different levels of detail. I think I’ve just been convinced that the equation I’ve been searching for is:

• process + practises = procedure

Simon actually listed in his answer to me, ‘roles, interactions and artifacts’ as the difference between the set of Agile practices and the set of Agile processes, so I’ve corrupted his definition for my own purposes but I haven’t broken his diagram so I hope he’ll forgive me. (Or maybe I don’t understand whether the layers of an onion diagram are inclusive or exclusive.)

I think making the process one of the practises would make the function recursive and this is supposed to be one of my Lisp rest-days. If my process diagram shows roles or artifacts then I’m sure I’ve moved into the realm of specifying practice. Interactions may be input-output that is part of the definition of the process, so it is probably necessary to split them down more, into message type & format.

To Be Derived

I thought I’d said something about this but I can’t find it, so sorry if you’ve heard this before:

Professor Brian Cox turned to Dr. Hannah Fry and said, “You have 30 seconds to define ‘calculus'”.
She replied, “It’s the study of change.”

What we call “The IT Industry” deals almost exclusively with change. As a business analyst, I’ve worked in business process re-engineering which is the process of changing the processes which cause those changes. I’ve worked in agile software development teams that try to change software while the requirements for the target they’re travelling towards are changing, so the changes have to change.

I’ve met calculus in maths and physics but never in computer science. Why on earth aren’t computer scientists up to their necks in calculus?

Applying the Science Process to Process Change (see Recursion)

Now that we’ve established that very few people who work in “IT” have anything to do with technology, except as a tool, and that “computer science” isn’t about computers, we’re back at the original reason I began to write a book. I was once an ‘Information Systems Engineer’ and wasn’t very sure what any of those words meant, particularly “information”.

Software development teams often see their role as solving their customer’s problems. Software package providers say they are “solution providers”. What does the ‘unspeakable profession’ actually do? We got some clues from Hal Abelson in the video I linked to in my last post, that new areas of intellectual endeavour often confuse the ‘essence’ of their subject with their tools; so do we really engineer software?

Hal said that writing software is the process (or function) of formalising our intuitions about process (function.) Our software is a speculative formal abstraction of our intuitive understanding of a process we may not entirely understand. No wonder software projects so often fail. Like the rest of science, software is built on ideas that haven’t been proved wrong yet.

Software developers are presented with, or attempt to discover, experts’ (declarative) knowledge of the business process in the ‘domain’ we are about to change. This is ‘the abstract requirements’. Some of this may have to be implied from imperative knowledge embedded in existing software. It may be presented as imperative solutions. It may be incomplete.

We then follow our own process (function) for: ‘the way we do software’, in order to design a new process, some of which is also likely to be have to be embedded in software. Applying functions to change functions? That’s what functional programming does, isn’t it?

I believe that the ‘stuff’ of ‘computer science’, is state-change of systems of process and data. Who remembers ‘Data Processing’? Functional programming points out that the processes themselves are data and dynamic state-change is unpredictable and therefore dangerous.

Engineering would apply ‘project thinking’ to this unstable, poorly defined change. I may once have tried to be an information systems engineer but I saw that it didn’t work and took a 20 year break from software development.

Agile frameworks recognise such changes as risky experiments and carefully apply the scientific method, incrementally with feedback loops, to check assumptions.

We may need to return another time to see what functional programming has to say about 2 projects making concurrent changes from the same initial state. Until then, good luck with those.