During a recent meeting at Obtiva, myself and other senior consultants where told a story from Tyler Jennings about how recent experiences with his client have shown him that creating a mess is not the end of the world when done in an Agile process. Though the idea of creating a mess is not appealing to anyone and is not the goal of any project, he said it was kind of enlightening to see that breaking some of the Software Practices dogma did not kill his project yet helped the team a lot in learning what works best for their code design and architecture.
On the surface, that statement sounds paradoxical as no one’s goal in a project is to create a mess. Often, project goals are tied to a business vision, sometimes quantified with numbers, and thus creating a mess is the last thing anyone would want to achieve success. So, what did Tyler mean when he said that creating a mess is fine?
Tyler’s team follows an Agile process, and one of the things that an Agile process encourages is early management of high risks, making it difficult for messes to derail a project.
In traditional Waterfall projects that I have been on, software was often developed in a coarse grained fashion, releasing every 6 months. Before a release, when team members work on integrating their code, a lot of messes are often revealed, such as imperfect compatibilities between the APIs and certain integration-related bugs. So, it was very common to extend releases by 3 months at least to address all these issues before having a software solution usable by the public. As a result, business value did not reach the consumer until 9 month after the beginning of development.
In Agile projects that I have been on, software was often developed in 2-week iterations instead of 6-month releases. Iterations served as time-boxed deadlines for when to deliver fully-usable features from the user’s point of view, forcing a team of developers to solve all problems related to developing a feature, covering it end-to-end from the user interface all the way to the back-end. Since going through all the layers of integration is time consuming, that forces the team to develop features in small slices of functionality whereby each slice takes no longer to develop than one iteration, and each subsequent slice adds a layer of functionality on top of the previous one. For example, in a calendaring app, the first slice would perhaps display the calendar, the second one would add events that are date based, the third one would add events that are date and time based, and the fourth would add events that are self-repeating. In that fashion, some business value can potentially reach the user only after one iteration, and then each iteration adds more value gradually until the original goal of the project has been reached.
So, why would creating a mess not be a big deal in an Agile process? There are several reasons:
How does that fit in with Tyler’s story. Tyler’s project apparently had an architecture that did not scale well at first. That is because instead of the team spending weeks coming up with the perfect architecture, they just went ahead with one architecture idea they had. Given the iterative nature of development with their Agile process, the team learned quite a bit about what worked and what did not with concrete usage of their architecture by users, and that knowledge enabled them to recover from the initial architecture pitfalls gracefully in future iterations, emerging with a much stronger architecture.
That said, does mean that doing detailed analysis and deep thought about a software architecture is discouraged in an Agile process? Not really, yet it is important to time-box it or cap it to ensure delivering business value to users by the end of an iteration. For example, if you find yourself needing two weeks of thinking about an architecture, it often works out better if you spend less time coming up with a less than ideal architecture, testing with some users at the end of the iteration, and then taking all the feedback into consideration when revising the architecture during the next iteration. That may give you a better idea about what works best anyways in comparison to pure conceptual brainstorming while still delivering value to users.
Let’s end the article with a quote by Tyler Jennings about making a mess:
“Software can be like a puzzle. Sometimes you have to throw the pieces out on the floor and spread them around before you can begin to see how they’ll fit together. Experimentation is essential. That’s one reason to make a mess. The point is its transient, it should only live as long as your ignorance of the problem space.”
