SCRUM and XP are gaining more and more adopters for development of many kinds of software (transactional systems, web sites, apps for mobile and tablets, etc). Techniques originating either from the agile movement (as DevOps) or lean thinking (as Kanban) have also been taking over operations and services.
However, going agile is not an easy task. Although definitions of “agile” remain quite simple (the “Agile Manifesto”, for instance), they are fluid and too little prescriptive, thus leaving much room for interpretation. Furthermore, new techniques and tools are not enough: a cultural shift must take place, making the whole change process even more abstract and elusive.
Three authors found out sound, consistent cause-effect relationships which turned out to become “laws” of software engineering. These “laws” have been around for decades, but they apply perfectly to the present day and, more importantly, they provide reliable guidelines for adoption of agile techniques. Finally, these “laws” aren’t supposed to be unbreakable; they must instead be regarded as patterns for very frequent situations in software projects.
The first one is Brooks’s Law, by Fred Brooks, Jr:
“Adding manpower to a late software project makes it later.”
Brooks argues that a software project is basically teamwork, and the results depend directly on how well team members communicate with one another. Bringing new people to a project late in the game will take additional time and effort to integrate them effectively; this increases communication costs and makes management more complex, and the bottom line is lower productivity and missed deadlines. Brooks also recommends the use of small teams (which he called “surgical teams”, much like a medical team performing a surgery), in order to ease communication and management tasks.
The second law is Boehm’s Law, stated by Barry Boehm, and it’s about the well known fact that, during a software project, costs to find and fix bugs get higher as time goes by.
Costs up as bugs take more time to find
This one is easily understood: right at the beginning of a project, an issue can be clarified by talking with users and changing the requirements accordingly. Later on, when the software is already deployed, the whole process is much more complex and expensive: some problem is detected by users and must go through analysis by the project team; defective code is spotted and must be rewritten, so one needs to assess the impact of those changes; next come coding, integration, tests and packaging; this patch must be deployed, certified by users and finally go live. Costs rise exponentially: when compared to an error found during specification phase, another detected in production costs is not just as 2 or 3 times as higher, but 10 or 50 times bigger.
The third one is Conway’s Law, created by Melvin Conway:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
This assertion is rather subtle, because it links two abstract concepts: the way systems are designed and how people communicate within the organization. This relationship can be better explained by examples: organizations with rigid, stable hierarchy tend to produce monolithic systems, with many access controls; on the other hand, organizations with flexible structure and autonomous teams are likely to develop system with enhanced modularity and universal, well-defined communication interfaces.
Ok, so how can these laws be helpful to teams adopting agile techniques?
Brook’s Law helps us to optimize communication and proper interaction among team members, providing co-location whenever possible (face to face communication) and sharing information through visual workspaces (those famous boards with post-it notes). This proximity also reduces the need for documentation (issues can be discussed on the spot, when necessary). Additionally, small teams demand less follow-up, and can be even self-manageable units.
Boehm’s Law tells us to shorten the feedback cycle, so project information must be, as soon as possible, checked for consistency and completeness. Users (or business people as well) should join the team, so requirements can be understood and verified prior to coding (prototyping and BDD – Behavior Driven Development – can be used to support these activities). All code changes must be tested automatically, both on unit and system levels (by using continuous integration and TDD – Test Driven Development). Finally, every code delivery must be presented to users, so the team can get feedback about their work and correct it if necessary.
Conway’s Law recommends that systems must be designed as a set of interconnected components, with crisp boundaries, clear responsibilities and accessible through interfaces (REST APIs, for instance). In order to do this, teams must be independent of each other, work in parallel, and have autonomy to decide on internal details. It’s important to keep components small and extensible, so code can be reused easily and naturally.
We can conclude by saying that, as the agile scene keeps evolving with new techniques and tools, these three laws can help organizations to make better decisions on this matter, by taking into account the principles which suit their needs and fit nicely into their culture.
O Blog é mantido por profissionais da MATERA, e portanto, as opiniões não necessariamente refletem a opinião da empresa.