Grass Roots Agile

Sustainable Pace

It’s little surprise that traditional development efforts tend to fall further behind schedule as the deadline looms. Foremost, attempting to predict completion through estimating and detailed planning does not work. Software development is a minefield of unknowns that cannot be predicted. And while planning is not bad, the value of planning is not the plan itself but instead the insight gained from the planning experience. Planning must be a continuous activity to remain effective.

To maintain a sustainable pace, however, development teams must track where they have been, and what they have accomplished. While promising delivery is received with fanfare early in the project lifecycle, broken promises have a steep price. Clients and key business stakeholders quickly lose faith. But showing sustainable progress over time earns their confidence, and that trust is a valuable asset to the software development team. A prime directive of software development is to maintain forward, sustainable progress.

Intense Collaboration

When we gather the requirements for a software system, we meet with our business clients and ask questions. The very process of eliciting requirements demands intense collaboration, traditionally between a business analyst and a subject matter expert representing the business client. Each bullet point, business rule, precondition, and postcondition in the requirements specification is based on detailed discussion.

Documenting that discussion is not a bad thing, but relying on the document as the sole form of communicating that discussion to developers cannot work. When you read a novel, you will never understand the thought process of the author. Similarly, when reading specifications, you will never experience the deep insight gained by hearing the discussion. Without that insight, attempting to design and code from a specification will lead you astray. We must avoid using documentation as the primary form of communication, and seek involvement in those discussions producing the documentation.

Frequent Delivery

All things equal, frequent delivery of functional software that provides incremental business value to a client may be the single most important activity a team can perform. It’s not necessary that a product be delivered to a production environment, only that it be delivered to an environment accessible by the business client.

Frequent delivery provides significant value. Business clients interacting with the system early in the lifecycle will experience the growth of the system, and gain additional insight to how requirements are manifest. Customers will feel much more engaged throughout the development effort, and will undoubtedly identify areas they would like changed.

The development team will also experience many rewards. A functional system proves architecture and infrastructure, and allows the technical team to begin many important testing activities, including load testing, usability testing, failover testing, and even user acceptance testing. Of course, frequent delivery is one important way of seeking feedback on the quality of the application.

Continuous Feedback

Ensuring the development effort never strays too far from the intended target is vitally important. One way to achieve continuous feedback from business clients is through frequent delivery, and it is this type of feedback that ensures the development team is well aligned with business objectives.

But there are other forms of feedback that are important to the development team, as well. Software undergoes constant change, and the resiliency, malleability, and extensibility of the software’s architecture and design is critical. Code quality, design, and coverage metrics offer objective feedback, that when used judiciously, can aid refactoring efforts that ensure source code maintains a high degree of quality and integrity.

Embrace Change

Throughout the software development lifecycle, many things will change from inception through final delivery, and experienced developers recognize that change is inevitable. Traditional methods have achieved very little success in stabilizing requirements early in the lifecycle. But we still try, for two reasons. First, we want stability. Second, we seek predictability. We get neither. Believing requirements are stable provides the false sense of security that leads us to believe we can predict. We cannot.

Instinctively, we may feel change impedes progress, but agile developers embrace an attitude where change is viewed as an opportunity to improve the system. Therein lies a key to embracing change - attitude. We cannot hold business clients accountable when change occurs, as this only causes friction between the development team and the business team. A key step toward building a trusted relationship with your customer is to remain adaptable. Instead of resisting change, seek for ways to accommodate the request. Prioritizing features and exploring and explaining risk helps everyone more fully understand the consequence of change.

Empowerment

The most successful teams are powered by people, not process. A key differentiator of agile teams is that process conforms to people over people conforming to process. While process may serve as a useful guide, teams must trust their intuition. It is the team with the vested interest in the outcome of the development effort. It is important that decisions be pragmatic based on the current state of the project, and not driven by the next activity dictated by the process du jour.

Team organization is also important. The most successful teams have naturally emerging leaders who are passionate about their area of expertise. Appointing architects and team leads is common, but allowing leaders to emerge naturally is more rewarding.