Greetings from three days SCRUM Gathering held in Barcelona. I had in mind to write three blog writings about the Gathering and that I will do, even if the insights I got were a of different subjects than I thought they would be before I got there.
First day started with Michael Feathers speech “Feature trap”. Micheal shared a lot of ideas of the problems we face within software development and how business decisions affect the development. He talked about technical debt and the modularisation problem that we have in both, organisations and code.
Michael said that features can be seen as leaky abstractions. A leaky abstraction is any implemented abstraction, intended to reduce (or hide) complexity, where the underlying details are not completely hidden. Broblem with features arise when we try to manage SW development by features, as the feature descriptions do not take into consideration the architecture as whole, nor do they consider user behaviour in the system or the whole complexity of the product under development. If we base our selling process on features, we most likely build a time bomb that results in problems with the budget, timetable and customer satisfaction. This is all due to the reason that if we think the SW as features we do not get enough information to understand the different corners and hideouts in SW development and we will give a time estimate that is based on abstractions.
Another problem with features is that if we think of features as modules, we will add in a layer of modularity after another. Modularity brings in complexity and duplication. Both of these are a nice ground for technical debt to grow.
Supposingly we have a system that has been developed for four years and we sell a new feature to our customer. If we don’t think enough how to add this feature as part of our existing code base, we will end up in building a module on the top of the existing code. This module might have functionality that already exists in the code base, but which we can not use as it is not exactly what we are looking for. We go on a sidetrack and rebuild the functionality we need and capsulate the module so that systems other functionality is not affected by the new module. And then we go on doing this until we have layer after another and the complexity and duplication becomes too videly spread for us to cope with. We are trapped in a situation where we have to re-structure the whole system or stop the whole development.
Modularity and layers in organisations also bring in problems. When the organisation is multilayered and people are highly specialised, the information flow gets stuck on the barriers between teams and we can not schedule the work to spread evenly in teams as the people are specialised. Specialisation and modularity does not exist in such an extent in startups and this is why startups normally can make fast decisions, can introduce new products fast and the information is moving fast and effortlessly. When we become “older” as organisations the complexity of our working environment tends to grow, all of our systems become more complex and specialised. This includes everything starting from the whole organsation structure, our processes, our working practises, desicion making, tools we use etc. Keeping it simple and flat is not easy, but it will pay back and actually become an asset.
Based on the Conway’s law “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations“. Considering this, if our organisation is layered and modular and specialised, we are bound to build solutions that have multiple layers, specialised tasks and modularity/complexity. If we want to keep our code nice and clean, we have to start reducing the boundaries between different parts of the organisation, make sure that the information is well and effortlessly spread, keep our processes simple and stop thinking like “this is my box and I don’t care what happens inside yours”. Simple is beautyfull. I will continue the story in my next writing about managing technical debt.