Why my teams can’t deliver on the market cadence?
Why do team members fear changing application source code? Or why teams can’t ship on the market cadence at minimal risk and cost? The answer is easy, “No-Design” culture.
What is the design?
Based on James shore’s new book, “The Art of Agile Development”, Computers don’t care what your code looks like. If the code compiles and runs, the computer is happy. Design is for humans: specifically, to allow developers to understand and change the code easily. Code is well-designed when the costs of change are low.
Fear of changing source code is a signal of bad design.
But what is wrong with Design in Agile teams?
In the waterfall age, we used to allocate substantial time for a Big up-front technical design. But with the spreading of scrum and other iterative approaches, the team is expected to finish several user stories every two weeks. So the managers or scrum masters focus on the project management side of work and ignore the technical aspects. The unintended consequence was a “No-design” culture as if the design had been completely forgotten. No design culture is about not allocating enough time for the technical design of features and applications.
In the long term, No-Design’s outcome will be devastating. The team’s codebase will have high technical debt, which makes changes costly and slower, and the CEO would say, “Why are our teams too slow? Do we need to hire more people? Do we need to increase salaries?”
Design in Agile teams is incremental. It means agile teams never stop designing; they constantly talk about design and do it all the time(Ron Jeffries used to say). Some conversations are very detailed and nitpicky, such as, “What should we name this method?” Others are much higher-level, such as, “These two modules share some responsibilities. We should split them apart and make the third module.” They constantly switch back and forth between details and the big picture.
You have two options to revive the design culture in your team. First, one is to start pairing and mobbing; it’s a great chance to talk about design. The second one, whenever you want to start implementing a new feature, set a design session; try to keep them informal and collaborative. Again, simple whiteboard sketches work well.
References: