Repeat after me – “I have been born to be agile”. As Steve Jobs once remarked – “…I know what I want once I see it…”.
If you look at the human spirit, at heart, it adapts. It improvises. And ohhhhhhhh man does it survive. The human mind is great at being agile. In classic agile there are ONLY 4 things that matter:
• Find out where we are
• Take a small step towards our goal
• Adjust our understanding based on what we have learned
To capture the essence of things – when faced with two or more alternatives that roughly deliver the same value we take the route that is easier to change in the future. Agility is not “how you do” but “how you do it”.
If we look at the human mind, this is actually exactly what happens. When a person is faced with two alternatives that will get the same outcome, the obvious route is to take the easier most adaptable route.
This is the second in a series of articles that deal with the values in the Agile manifesto. “Working software over comprehensive documentation“. In agile, we acknowledge that the stuff on the right (the stuff in italic) is important. But we value the stuff on the left more (the stuff in bold). This article will unpack this particular value – it will ask several questions:
• What does this value bring to my data warehouse?
• How can I apply this value in my data warehouse?
• What mindset change do I need to go through to adopt the value in my data warehouse?
Before I start unpacking this value, I want you to ask yourself this question – when last have you actually observed what you really do when crossing the road? When last have you taken some time to study all the motions you go through to get across the road? In most cases the answer will be “….uhmm, never….”
Similarities to rugby
This weekend I watched my beloved Sharks team smash the Hurricanes at home. Very often the Sharks would go away from home and win as well. In fact, 3 years back they won at Canterbury for the first time. It was the first time a South African team won a Super Rugby game in Christchurch. In that game we were given one red card and two yellow cards. The red card came in the 16th minute. To say that we were up against it is the mother of all understatements. Yet we won. By a single point. But we won.
You may be thinking “what the hell has this got to do with agile?”. Here is the thing – in the rugby manual, 14 players against 15 players should never ever win. In theory, the overlap will be exposed. Somewhere, somehow, there will always be one player short. But the human mind never works in that way, the human spirit even less.
In software development, there are only two trends that apply. Either you cater for the rugby manual or you cater for the human spirit. So let’s say for example that you cater for the rugby manual – so you blindly code for the Crusaders beating the Sharks. You blindly model for a scoreline. And you have a report putting that up in lights. Your model, your development, and you reporting are broken. Because you haven’t catered for the human spirit.
So in agile, we iteratively document as we go along. We are not saying that we don’t need to document. But what we are saying is that we document just in time, when there is a need to do so. In the scrum, we refine this by saying that we would like to create a spec by example for the user stories that matter and that this spec by example would be used to test the entire story. Then we make sure that ANYTHING and EVERYTHING we do adheres to this spec by example. In essence, we are upholding the “Steve Jobs principle” – “I can only test what I want once I see it”.
Working software over comprehensive documentation
We have this thing called “consumer views”. In there are some real gems – the consumer of our data has actually put together some stuff that will drive value from our warehouse. And Mama Mia – it drives crazy business value. Nowhere in the process has anything been documented. Join “x table” to “y table” and provide “ordered analytic function z”. We could have gone back to the consumer and said – “please provide us with a spec document outlining how to join and what views are required”. If we had done this it would have required the involvement of a business analyst or system analyst at the very least. Instead, we engaged a developer to spend some time with the consumer in coming up with the requirement. The fact that a requirement is there there is no doubt. The fact that the requirement is not very “verbose” there is also no doubt.
In this past week I worked with a really good test analyst. The thing that bothered me the most was that we were spending more time actually testing than developing. I have zero issues with test-driven development please don’t get me wrong. But I have major issues when the function (testing) is not delivering business value. We negotiated. We bartered. We improvised. And oh man, did we get better.
Here is my big fundamental issue with the whole process…. For me, getting the darn software to work is of far greater value than proving that the software works. Sure, it is mighty important that I have negative scenarios (such as that business MAY provide me an empty file). But what is crazily more important is that I calculate credit risk correctly. Don’t get me wrong – before I can deploy to the next environment I would need to cater for both scenarios, but guess which answer is more “not negotiable” in the greater scheme of things….
For me, working software over comprehensive documentation is quite simple. It ties into individuals and interactions – as long as I have software that meets up to my user’s expectations. It isn’t always possible to document those requirements into some level of comprehensive documentation.
Besides, by the time the document actually is delivered to IT and the product gets built, the landscape can and will have changed several times. Would it not be better to document the immediate rules and then to add into the document as and when more rules are unpacked? So in agile, you deliver working software in small chunks. Would it not be best to describe those small chunks as and when they are needed as opposed to describing the whole darn thing up front? Remember, the landscape is set to change. So in all likelihood you will get more and more upset at whoever is upsetting your documentation karma – particularly the later and later it gets into the development cycle.
“Doing agile” versus “being agile”
In the above example, the tester was quite good at providing specs by example. After all, this is the agile scrum way of delivering value. But he absolutely didn’t factor in that his specs by example were hurting my team in terms of delivery (every item being tested required a ratio of one (development) : three (testing). The point is simple – if your process cannot support and underpin the foundations of agile, then maybe it is time that you brush up on what the actual foundations are.
Certainly, my team wants to be agile. Certainly, your inability to make them do agile is hurting the organization. It actually is so easy it is scary:
1. Document continuously
2. Document as little as possible
3. Document as late as possible.
If you can do these 3 things in harmony, you will go places. And that isn’t even agile; it just is what it is….
Traditionally, testers would test according to a specific test case. In this new order, more is expected of the tester. So I would expect a tester to actually live, eat, and breathe a requirement. Yet, what I find is that the testers are still very much reacting to a specific requirement. Until this changes, testers will always be the “people that wag the tail of the dog”; the people who put comprehensive documentation at a premium over working software.
In my next blog, I will be discussing the next value “….customer collaboration over contract negotiation….”
I would love to hear from you. Please feel free to comment.