Formality, Not Rigidity

Many people conflate formality and rigidity, treating them as inseparable. It is easy to see why. Formality leads to rigidity as mechanisms are put into place to ensure formalized practices and processes are followed. You have likely seen this go wrong as I know I have. Architecture groups and PMOs shift their focus. No longer an aid to progress, they become an obstruction. They keep their formality, but lose their purpose as they become rigid.

Agile is, in part, a reaction to the rigid process models of the past. It is no surprise that many throw formality out as well. However, without a degree of formality, we lose repeatability. This has happened in countless efforts to implement Agile methods. The team, seeing a chance to break from the rigidity, pushes off any attempts at formality as well. As the project progresses, cracks begin to form. There is no formal test plan, so high-level bugs creep in. That is, while the expressed stories may work as requested, certain aspects are simply not covered. Because there was no formal effort to design the user interface flow, usability of the product starts to plummet as the complexity of the combined requirements weighs upon each successive screen.

These, and other aspects, are things we as software development professionals have learned to do reasonably well in the last 30-plus years. Ignoring them hurts our chances of success. Are these things non-Agile or anti-Agile?

No they are not. To completely ignore formality would be to throw even Agile practices out the window. Software development requires people to coordinate actions. The amount of formality to do so varies based upon the team and its goal. However, some degree of formality can be an aid when more than one person is involved.

It is all in how we apply formality. Things such as test plans, information architecture and user interface flow, and domain modeling applied in an “all up front” fashion would be difficult to reconcile. However, none of these things has to be rigid. They can adapt just as easily as we can refactor our code. If the plans are designed with this in mind, small adaptations are easy while larger ones remain possible.

It is worth repeating that not every effort requires the same degree or type of formality. If a project is just starting or has only minimal and very simple user interactions, perhaps a comprehensive outline of user interface flow really isn’t necessary. However, we must train ourselves to recognize when it becomes necessary. As soon as anyone in a retrospective or user demo says, “I can’t find a screen where I can do X,” it might be time to examine the flow. In fact, it may be worth formalizing a list of “smells” that point to the need for adding some of these practices. Somewhat similar to those in Agile Adoption Patterns. What do you think?

Tags: agile, retrospectives