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.
Agile Development
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.
Architecture
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.
Acceptance Testing
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.
Epilogue
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?
Great insights!
To me, the most profound revelation was when I realized the savings that agile could create. 50% or so of all features we implement are never or rarely used, so by prioritizing ruthlessly the things to do for each sprint, we can speed up development by 2. I think that is almost a silver bullet!
I am interested in your comments on architecture. What form of documentation do you use and how in depth is it? We have a high turn over of development in a small team and often only have time for high level requirements, basic use cases, and a database schema. It is pretty effective up front but does create a documentation void at the other end.
woooa – that’s something to bite in to.
My best bet is to have it on the walls in any form. It must be easy to change as well since the problem with any documentation is that it is outdated.
If you have it on the walls, it will be in your eyes all the time.
If you change it often, you will not look past it and it will stand a chance of being up to date.
Try to visualize the system with a metaphor. A city works in most cases but you may have something closer to your domain. You may start with simple boxes of vanilla UML but should break free from that to become more lively as it attracts the attention.
Rules for logging and error handling should also been on the wall but I guess it harder to visualize.
Interesting thoughts. I concur that unveiling economics of architecture work is of great interest. But first step is to understand where we want it to add value, and that is also a very interesting topic.