April - 4th Agile Principle
Business people and developers must work together daily throughout the project.
We are now getting to one of the most widely ignored principles of agile development. It is clear, succinct and quite definite. It says that business people and developers must work together daily. Note that it doesn’t say business people and developers should work together daily. The keywords are must and daily. Why is this principle often ignored? Because business people are often too busy to talk to developers. There are several reasons for that. First of all, they usually have other responsibilities than managing software development. Second, they may simply not be available every day. Third, business people and developers often don’t understand each other. It’s almost as if they speak a different language. Developers speak about technology and business people speak about goals, opportunities, and strategies.
Before we go into these issues, let’s briefly elaborate why it is important that developers and business people cooperate on an ongoing basis. Unlike the waterfall method or any other method that is based on a grand plan, agile development relies on a progressive formulation of requirements. This is the same feature that makes agile development adaptive and open to change. The drafting of requirements happens incrementally and thereby mirrors the development process. Specifications evolve throughout the project. There is no single prescribed method for how business requirements are being translated into detailed technical specifications. It can be done in a number of ways. However, it is understood that business people and developers must be in an ongoing dialog to make this happen.
Frequently, requirements begin with a high-level road map or whitepaper. This document contains a description of the overall goals and high-level functionality of the project. It is generally too abstract to be used for technical implementation. However, it may be followed a description of the envisioned architecture. The next step consists of defining different large-scale features (epics) that touch upon distinct aspects of functionality. This step again requires a dialogue of business people and developers. Epics are still too abstract and too large to be worked on directly. The entire process of requirements gathering can be seen as a successive refinement of specifications to the point where specifications can be encoded in computer language. Epics are broken down further into units of work that agile teams consider appropriate for concrete implementation,
so-called user stories.
A user story is a conceptual tool of agile development. It describes a software feature from the perspective of a user. For example: “As an administrator, I want to be able to approve new comments before they are posted.” This is a proper user story containing a user role and a feature description. During the course of technical planning of a user story, further details are specified, such as the user interface particulars for that specific story. Diagrams, tables and UI mockups may be created during this phase. This implies again that there is dialogue between those who provide specifications (business) and those who implement them (developers). Without continuous cooperation, requirements end up being too vague and software artifacts end up being incomplete or flawed. The requirements refinement process runs parallel to implementation and testing. It requires management from the business side. Together, they make up a sort of pipeline that runs from high-level specifications to usable software.
In a typical Scrum team, there is an appointed manager (called “product owner”) who leads the requirements refinement process. The product owner acts as a sort of intermediary between business and development. On the other hand, a typical Kanban team is
cross-functional and has no appointed roles. Members from business provide guidance directly without a project manager. Project management is often handled on demand by individual team members, depending on the nature of the task. In a Crystal team, project management depends on team size. There may or may not be an appointed project manager, often an executive sponsor. Business and development come together for Blitz planning sessions to define tasks and schedules. The refinement process is informal and relies on other methods such as co-location, daily meetings, or brief review-and-feedback loops with expert users. The problem of translating business requirements into software features and codeable functions can be solved in many ways. The one thing that all the different agile methods have in common is that business people and developers work together on an ongoing basis.
What can be done to improve communication between business people and developers? The problem of allocating sufficient time for exchanges can be solved in different ways. Appointing a product manager who works face-to-face with the team works well. Setting up regular meetings, such as feature planning, iteration planning, reviews, and backlog refinement meetings also works well. Having an executive sponsor working with the team is likewise a good solution if the sponsor is approachable and dedicates enough time to the task. Even informal communication can succeed if business people and developers are co-located at the same work space. The language problem can at least partly be tackled by developing a domain-specific vocabulary. Organisations usually have quite specific structures, roles, workflows, service offerings, etc. It is important to agree on a fixed terminology for these when phrasing requirements. This helps eliminating ambiguity, because ambiguity and vagueness are the principal obstructions to a successful implementation.
In summary, the 4th agile principle describes one of the most important factors to determine success or failure of software development projects.