I just recently finished reading The Robert C. Martin Clean Code Collection, which includes Clean Code and The Clean Coder. These books gave me excellent food for thought on what it means to set the bar for yourself and to live by a code of honour in your craft and your conduct.
The theme of both books is professionalism: taking full responsibility for your actions: writing thought-out, disciplined code, learning how to draw the line and only make promises you are able to keep, communicating and collaborating until all ambiguity is gone, and working toward the best possible solution with the information at hand. It is a commitment to excellence, even when it hurts.
In a professional role, there is no room for making excuses for dropping the ball or taking half measures. It doesn’t matter if you’re feeling pressured, cajoled, or rushed into cutting corners or taking risks; you are directly responsible for your own actions. These books are a good reminder that it is entirely in your power to conduct yourself in such a way that you can hold your head up high.
In the end, that is also what Agile is all about: putting responsibility into the hands of each stakeholder by removing barriers to full participation, engagement, and ownership.
Big Design Up Front vs. Iterative Development
For example, it is nearly impossible to fully design a product up front without requiring clarification and refinement. Even when every feature and screen is outlined in painstaking detail, communication is imperfect, and there will always be assumptions and misunderstandings. Not only that, once you can actually interact with the working product, it is natural to form new ideas and to scrap original ideas.
A product owner is responsible for upholding the vision of the product and ensuring that the implemented solution embodies that vision. How can the product owner hold to that responsibility if the developers disappear for several months and come back with their interpretation of the design document?
The Agile principle of iterative development allows the product owner to see a working application as quickly and as often as possible so he or she can provide regular feedback and verification. It removes the barrier of non-communication so the product owner can be fully responsible for verifying product vision.
Applying agile principles in an organization is not about following a to-do list and then calling yourself Agile; it requires taking a hard, honest look at the dysfunctions, miscommunications, and barriers in your company that cause failures, and then making them more visible so that you can address them and check on your progress. It also requires making all stakeholders more personally responsible for the success of each project, which can be a difficult transition as authority and communication is shared. But the growing pains of a team transitioning towards self-organization and interdependence are the coals that forge a bonding that cannot easily be broken.