It has been 10 years since the Agile Manifesto was written and although I have not been following the agile community for that long, I have been a developer in Scrum teams since 2007. In total, I have done system development for 30+ years so I have lived and breathed both waterfall and RUP before trying Scrum.
So what is on an agile developer’s mind these days? Here are my current reflections on three things today, Agile Development, Architecture and Acceptance Testing.
One interesting thing about being Agile is that immediate adoption to business needs and frequent demonstration of valuable functions, has got development somewhat off the hook. It is not we who are the bottleneck anymore, it is the rest of the organization that has their meetings and decision queues that can delay the process for months.
The problems of a slow organization surfaces when we are not busy creating big projects with big releases every six months. From our perspective, their lack of flow and clear strategy lands in an inability to get the priorities set.
So my conclusion in this, is that the agile thinking can spread outside development to a great benefit. Do not be surprised if you see a Kanban board at HR.
We still do not know how to combine architecture with agile methods. Disagree with me and I will be ever so happy.
However, the previous way, architecture centric, where we used months to create a architectural prototype that should be the basis for further development, was a misery.
Firstly, we used months of development time without delivering value.
Secondly, when the months had passed, business had already changed enough to make prototype slightly off target.
Thirdly, the architecture was described in a fat document that developers was supposed to read and understand, which they did sometimes, but still failed to apply. That in turn lead to an architecture that was described but with numerous exceptions to it in the code.
I look for a concept where the architecture evolves as the business changes and without loosing the grip on it, ending up in an organic mess.
My current approach is based on an idea that we must have the competence to understand that architecture determines the quality attributes of the system. We must quantify the value of those qualities, or the cost of not having them. With that visibility, any work related to architecture can prioritized against everything else since we are delivering something (the qualities) as opposed to working with something that is the basis (the architecture) for something valuable.
I am currently thrilled with the concept of specification by example as an implementation of acceptance testing. Acceptance tests are the tests that verify that the system is acceptable – duh – and with a growing system, the set of acceptance tests is growing. Therefore I conclude that unless the cost of regression testing shall grow in the same manner, we must automate them or skip some testing.
Furthermore, if we can write specifications with realistic, concrete examples, we can reach automation by specifications that are both readable and executable.
With concrete examples, we can quickly discover contradictions in requirements which will otherwise be impossible to do before we sit down and try to write the code.
So, that was my current thoughts on three things Agile.
What are your thoughts? What is the current most interesting things Agile when looking forward?