Several weeks ago I was asked to facilitate at a release retrospective for another division of the company I work for. The situation was quite political and the situation pretty tense as the team had been unable to deliver a key feature of the release. This was part of a major product and the team was exposed to quite a bit of customer criticism as a result. The management of the business unit were keen that a lessons learned exercise be carried out so that they could get to the bottom of the problem and not have it repeated in future.
As I sat there in the room listening to them, it seemed to me that there were several areas where things hadn’t really gone to plan. Communication issues are always going to be top of the hit list of things to dig into and that was no different here i.e. writing things in the issue management system and expecting people to read and understand them is no substitute for a face to face discussion. These things though they thrashed out between them and managed to come to a consensus on how to improve in future projects.
There was one thing though that I did pick up that appeared to me to quietly slide its way in and out of the discussion barely raising any interest.
One of the areas that the team felt they needed to investigate was whether or not this feature was too large to be handled by the team in a single sprint. Initially the team had felt they could deal with it but as they got into the development they discovered that they had in fact bitten off far more than they could chew. The reason given for this was that the story was completely atomic and could not be broken down any further.
On about the 3rd or 4th ‘why?’ it transpired that the reason they believed the story to be both atomic and large was because it involved an architecture change. The system design was simply unable to accommodate the story and so the architecture had to be refactored. In this project the architecture was the responsibility of a single software architect who sat outside the scrum team and had provided the architecture to the teams before the start of the project. The team therefore did not feel that they had the authority to make the changes required to accommodate the new feature. Meanwhile the project management team were unimpressed by the situation as they felt that the architecture shouldn’t have needed any change and should have been designed to cope with the requirement from the start.
This situation got me thinking about how agile methodologies cope with architectural change. Agile methodologies embrace change and sooner or later, on any project, the team are going to hit this problem. The question is, do you spend a lot of time at the beginning of the project defining an architecture that is able to deliver every feature you’re ever likely to need in the lifetime of the product or do you accept from time to time that you will need to take a significant time out of a sprint to refactor it? If you choose the latter, how do you then justify to project management that taking the time out to do the work is beneficial and not just the rewriting of something that should have been right the first time? If you choose the former, how do you prevent the problem of over engineering a solution that, as in the case of the situation described earlier, ends up not fulfilling all the needs of the product anyway?
As it happens, I’m a fan of the second approach. My mantra has always been, “build the features, refactor the framework”. The reason for this is that by designing and building a framework to instantiate an architecture that covers any eventuality, a team is violating many of the core principles of agile development. The idea is to get something out there at the earliest opportunity that allows your customers to provide feedback and guidance on when and how to deliver the rest of the features. In addition to this, at the point of developing the architecture, you might have no idea how the delivery of the requirements will develop in future releases so the only way to build an architecture up front is to invest in a large framework that probably delivers no commercial value. Even if you manage to get the framework up and running in a reasonable timescale, chances are that at some point, as with what happened to my colleagues, some feature or other just won’t fit and architectural change will be necessary except that now having made the large investment up front, that is going to be a much harder sell.
This led me to look at agile projects from the perspective of the graph above. Assuming that the size of the team doesn’t really change, your project costs are going to rise proportionally to the number of sprints in the project. This is demonstrated by the blue line The commercial value, i.e. the value of features as part of a business case however, does not rise linearly and this is represented by the green line. Note that this is different to traditional Earned Value which would assign value to the framework development period even when it delivers no commercial benefit against the business case but simply because some work got done.
In the graph above I’ve divided the project into three distinct ‘zones’. The ‘Framework Zone’ describes that period of the project where few features are developed and most of the effort is going into establishing the architectural framework. At this time the value of the product might well fall behind the cost of development and so it would seem logical to try to keep this period as short as possible. The ‘Feature Zone’ describes the point at which the majority of the framework and enabling code has been done to support the required features. At this point the team starts to race ahead and deliver features very quickly. The product should now be generating revenue in excess of the development cost so it makes sense that you want to be in this zone for as long as possible. At some stage though, the cost to build new features might start to exceed the commercial value of the features being built. Now the business case is suffering and the product enters a ‘Retirement Zone’.
At the point that the project enters the Retirement Zone, you get to make a choice. You can either decide that the project has run its natural course and stop development or you can make the assessment that the drop in features is due to technical debt, that there is more value to be wrung from the product and enter a new Framework Zone. This would seem to be a prime opportunity for carrying out major refactoring work on the architecture.
So going back to the problems faced by my colleagues, how could this problem be resolved in future projects? In trying to keep the Framework Zone as short as possible so that we can create value early, we can make the choice to build a minimal framework (or adapt an existing one) and to get our product out there as quickly as possible so that it can start to deliver revenue. In doing this we accept that the architecture may well require change but because we are making this clear from the outset and providing the business with the reasons why, while at the same time delivering early value, there is likely to be far more acceptance of this by the project management.
It does require several other changes though. Firstly, either the architecture needs to be defined loosely enough and the development team empowered enough to be free to adapt the architecture as required or the architect must work much more closely with the team. Secondly, as architects we must remain open to the idea that change is both necessary and inevitable. Architecture must be able to evolve. Gone are the days when we threw documentation over the wall at the development team, we have to be right there in the thick of the action to enable the evolution to happen.