Sometimes you simply want to be clear if something is either true or false; fuzzy states are not acceptable. In this post I’ll try to help you to cope with such cases having agile methods in particular in mind. It’s about defining and crossing the threshold in order to enter into more efficient software development method. Once the goal is defined we need to know how to achieve it and finally measure the achievement when the threshold will has been crossed. We refer to Crossing the Rubicon idiom to address the topic.
The Rubicon
Why do we say Cross the Rubicon?
This high-level idiom comes from an event in ancient Roman history. In 49 BC Julius Caesar’s army crossed the Rubicon River, an action that started civil. It was forbidden for any army to cross the border river, so when Caesar’s army did, he knew he was doing something which would have important results that could not be changed later[1].
Factors:
- It is forbidden
- It is one way direction, cannot be changed
- It is the beginning of something new
- It has meaningful impact on the future
This idiom is a perfect analogy we can use here. However, I hardly ever use it in my life. Neither I hear it from other people. The last usage which got stuck in my memory is cerebral rubicon[2]. I found it while reading the book – The Lives of the Brain by John S. Allen[3].
Cerebral Rubicon
“Keith was probably the first to introduce the notion of the “cerebral rubicon”, a brain size at which it could be said that hominids passed the threshold from being simply a bipedal ape to being something human. […] Keith placed the cerebral rubicon at 750cc: a fossil hominid with a cranial capacity smaller than that was better considered something not quite human”[3].
This can be simply expressed:
If capacity(brain) > 750cc then human Else something not quite human
The condition – capacity(brain) > 750cc defines the threshold there. According to Arthur Keith once it’s crossed we consider new kind of creature. The factor of being forbidden doesn’t always matter when using the idiom. Now we’ve the idea of crossing the rubicon and we’re diving into agile context in the next section.
The Agile Rubicon
Could you name the way you and your team take in order to achieve development goals? Is it agile, waterfall or something else or even undefined? If you’re not in agile and if you want to be in it, you need to cross the agile rubicon.
First we have to be sure that you’re not in agile. It’s relatively easy to judge, even though some people can claim you are e.g. in Scrum.
What makes the Agile Rubicon in software development?
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
[4]
This can be expressed:
If isFollowed(manifestoForAgileSoftwareDevelopment) then We develop software in agile Else We don’t develop software in agile
Now the condition – isFollowed(manifestoForAgileSoftwareDevelopment) is the threshold. The isFollowed(manifestoForAgileSoftwareDevelopment) is the predicate which allows to asses if the Manifesto for Agile Software Development is followed in a context of a certain environment. The context is your agile implementation within the organization’s environment you work in. This is only the beginning. It’s a high level picture to be the base for further processing and to implement in a daily work. Take into account the Principles behind the Agile Manifesto[5] as well. Only correctly implemented predicate will answer if the agile rubicon is crossed. The implementation has to rely on the mentioned principles and your practices.
Let’s address the factors from original rubicon context to the agile one:
- It is forbidden. In some organization that’s unfortunately true.
- It is one way direction, cannot be changed. It can be changed, but probably it’d be a step back.
- It is a beginning of something new. That’s true.
- It has meaningful impact on the future. It will have, for sure.
The Scrum Rubicon
If we decide that we implement Scrum then we can express the Scrum Rubicon:
If isFollowed(manifestoForAgileSoftwareDevelopment) AND isFollowed(Scrum) then We develop software in agile, in Scrum in particular Else We don’t develop software in Scrum
Here we’re more precise about the development method. Scrum is the choice. The condition is a compound one extended into isFollowed(Scrum) predicate. In order to answer if we’re in Scrum in addition to agile manifesto, we need to be fluent with The Scrum Guide™[6].
Summary
How to cross the agile rubicon?
- Follow Manifesto for Agile Software Development
- Take into account Principles behind the Agile Manifesto
- Choose and follow agile method, e.g. Scrum
- Do not accept semi-agile solutions
- Define and accept common working agreements
- Do not accept exceptions from the defined agreements
- Constantly inspect and adapt where you are and where you want to be
Resources
[1] https://www.ecenglish.com/learnenglish/lessons/idiom-day-crossing-rubicon
[2] https://en.wikipedia.org/wiki/Cerebral_rubicon
[4] http://agilemanifesto.org/
[5] http://agilemanifesto.org/principles.html
[6] http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf