For a disproportionately larger part of my career as a developer/technical designer, I have worked strictly within the sacred walls of the waterfall model. My work would begin with me receiving a Functional Design from which I would need to meticulously craft a technical spec. The development will not begin until the spec has been completed and suitably transitioned. At this stage, I would be able to iron out functional queries, check feasibility and test out different solutions. Since, in most cases, each functional design would typically cater to a substantial amount of functionalities (example: Create a purchase order form with all the bells and whistles ), I would acquire a better idea of the bigger picture. Thus, I could build my design with careful consideration for certain principles I hold immensely dear: reusability, flexibility and uniform coding approach. The technical designing phase was my opportunity to lay the foundation upon which a large and complex codebase could be built.
With more experience, eventually, I would gain some foresight into what may come and build in provisions in the design to reduce enhancement effort & retrofitting of code. As we would chip away at a monumental scope of functionalities, I would sleep better knowing the code that converts X to Y was not duplicated by every developer across the teams. Yes, there was a lot of effort in documenting everything, but to be honest, any amount of documentation is too much documentation for me anyway. I begrudgingly dealt with it then as I do now.
Then came Agile.
And it blew me away! The idea to break down the work into simple featurettes and then logically prioritize them to build an elegant app or a set of robust core functionalities is simple, intuitive and offloads so many organizational overheads to the agile tool itself that any other paradigm seemed archaic and uncouth in comparison. Requirements are easier to track, visualize and correlate. There is a better sense of working in a team and dragging and dropping a task to completion on the scrum board exuded a feeling of contentment. The instant gratification monkey in me liked it… a lot!
But of course, Agile is not without its flaws. They are well-researched and understood and this article is not really about them. My main gripe pertains to one side effect that arose with the incremental development approach. The culture of understanding the big picture gave way to thinking two sprints at a time. Under the guise of being agile, scope creep became an accepted behavior that exacerbated the situation. The focus on laying the groundwork for the future was replaced with that on delivering immediate values. This resulted in the increase of what I am calling purely for the purpose of this article, the ‘uh oh factor’ or ‘we could have saved time now if we thought about it four sprints ago’.
Technical designing has been retired, technical foresight is repudiated and in a feature centric process, technical elegance isn’t given the value it deserves. In an all-hands-on-deck state of affairs, there is no time to step back and take a holistic look to help create frameworks, design assets, determine opportunities of reusability. With that came duplication of code, writing more lines of code and cumbersome retrofitting. Code maintainability suffered and newer features tended to get shakily duct taped onto the wobbly frame of the MVP.
In our bid to attain that MVP, we sacrificed some venerated technical design philosophies. Of course, we have added a story in the backlog from time to time to address these ‘qualms of hindsight’. But in most cases, accumulating this technical debt later in the development phase turned out to be expensive and ended up affecting cadence, if not throwing the project timelines out of whack.
But how do we make it better? Will we ever have enough foresight in a fast-paced project environment to even attempt to improve this? Or is this a trade-off we’d have to live with? How can we introduce a culture of planning and avoid regret within Agile? It is quite impossible to plan for requirements that will arrive three-quarters away. But maybe we can find a middle ground within Agile, for projects that have matured vision, for projects that can be insulated from extreme scope changes. When these caveats are even partially accounted for, in my brief experience with scrum, the answer can be found within what we can call an Extended Sprint 0.
Sprint 0 already comes with a lengthy checklist. There are a lot of things to figure out, a lot of transitions to be made, a lot of system access setups to be sorted out. A typical Sprint 0 goes by in a blink of an eye just absorbing the basics of the project. And the very next day we dive straight into development.
This creates enormous pressure on the technical designers and leads to providing a robust design when every developer has already shifted to 5th gear. It quickly becomes challenging to establish a uniform development approach that’s tailored to the business process when development is already underway. All the technical design considerations become an afterthought and the effects start to show pretty soon.
This is why I strongly feel a longer Sprint 0 can be beneficial where time is provided solely for technical planning and dev team brainstorming. The length of it may vary depending on the size of the project, but it is imperative that that time is quite generously allotted. Is it far from being a silver bullet but it nudges the project towards an environment of better and cleaner development where best practices are respected and technical design principles are upheld. From what I have seen, that extra breathing room where I can get in the weeds, discover existing artifacts, and try out different approaches, and where the team has the time to internalize the best approach not only sets up the project for success, but it gives me confidence that the deliverables will be more maintainable, more flexible to future changes, and will save time and effort in the long run. And most of all, I will get a good night’s sleep.
View our LinkedIn, here.
