The goal of this blog posts is to share why a team I coached used pull requests and how we did this within the context of a midsize product. I share this experience, knowing it’s not a perfect example, as it might provide inspiration on the advantages and disadvantages of such an approach.
Why are there so many IT people out there who have the feeling they're actually a firefighter? Why do they have the feeling to be jumping from one burning house to another? Why do they have the feeling work is driven by fire alarms? Why is it that the loudest voice in the office, the biggest fire, gets things done?
A bunch of questions I asked myself too, and there are some organizational patterns that we should consider. Once you know them, you can beat them!
Architecture is a business asset that deserves explicit investment and care to generate long term benefits. Let me explain.
Software architecture is as important as functionality, at least in the long run. Sounds reasonable. I asked more than 1000 technical people in the last year if they agree with this statement, and they overwhelmingly do so. But, what does this actually mean?
As the functionality of a system is recognized as a business asset, it follows that architecture of that system is a business asset as well. And they both should be approached with the same rigor.
A few months ago I was on an assignment where there was a clear request to use physical cards for their stories. It helped to give an overview by laying them on a large table. Always good to hear that people are thinking out of the box when searching for ways to visualize their work.
It is frequently seen that even though people are working on the same delivery there still is misalignment on the way of working, with what degree of finish (D.O.D. interpretations), etc.
This especially happens with different skills and contexts that imply different perspectives on how to look at software.
Either way you place it: knowledge sharing is lacking.
Dependencies in Software Development have been an issue since decades and lots of practices have been built to “manage” them, creating an environment that becomes more complicated with longer time-to-market times as dependencies grow (or the product/solution grows).
This is creating an illusion and no dependency management is alwys the only answer! Coordination to remove dependencies is usually a more sustainable outcome with less management.