By Jann P. Thomas
The Chinese philosophy of yin yang is based on four laws.
- Yin and Yang are opposing. Yin and yang describe the polar effects of phenomena. For instance, winter and summer would be the yin and yang for the year.
- Yin and Yang are mutually rooted. They are complementary qualities that make up the whole phenomena, just as daylight and night together make up a single day.
- Yin and Yang mutually transform. That is, a change in one quality causes change in the other. For example, snow melting in the spring cause a rise in the river.
- Yin and Yang mutually wax and wane. There is a dynamic equilibrium between Yin and Yang; even as winter days grow shorter, the night grows longer.
Agile and traditional management methodologies have a yin yang relationship that is felt quite keenly by many project managers charged with moving a software team toward agile practices. Handed an edict from on high or a mandate from the software team’s own grassroots effort, the manager must figure out how to function in his new reality. Will the developers now have free reign to do whatever they want to do? Who will be in control? What is the job of the manager on an agile development team? How can I move from command and control to cooperation? Learning agile’s guiding principles and how their inherent balance translates to concrete actions is the first step to a truly productive conversion to Agile.
Balanced Principles
Like the yin yang philosophy, agile also has four guiding principles—principles that are also opposing, mutually rooted, mutually transforming, and mutually wax and wane. These principles are captured in the Agile Manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
Let’s examine the yin and yang of these guiding principles and see how it can help guide a project manager in converting to agile.
Individuals and Interactions & Process and Tools
This principle lends itself to several concrete actions. If possible, remove cubicles and have the team together in one shared workspace. Schedule daily stand-up meetings for each team member to discuss what they did yesterday, what they are doing today and what blockers stand in the way of completing work. Remove any blockers or impediments to delivery, whether that means buying tools or putting a process in place to encourage productivity.
A process? Yes. Agile is not anti-process. For example, take the familiar case of bringing in an enhancement to a product in mid-iteration rather than completing the work originally scheduled for that iteration. To do this effectively and transparently, the agile project manager must create a process for bringing in new, unplanned work. This process must also include recording what tasks were moved out of the iteration to make room for the new work so that the whole team, including the customer, can see and understand not only what changes occurred, but what the costs of those changes were.
To be an agile project manager is to be introspective. A good agile project manager should review and question all of the organization’s existing and developing processes. Is the process appropriate in an agile environment? Does this process help or hinder the team’s efforts to deliver working software? In addition, iteration reviews (retrospectives) give the entire team the opportunity to evaluate any changes they have made to their processes; the team keeps the ones that work and drops the ones that don’t.
Working Software & Documentation
Working software is the goal of every software project. Traditional approaches, such as waterfall and spiral methodologies, rely on the concept that the requirements of the product can be precisely defined before implementation begins. Agile development practices differ in that all software project activities, from requirements to installing production-ready code, are delivered in small time chunks called iterations. An iteration can range from one week to four weeks. The only fully defined requirements are the ones that the development team is working on in a particular iteration.
Agile teams and agile project managers are not opposed to documentation; rather, agile is focused on just enough documentation, just in time to create working software. On agile teams, requirements are developed only when they are ready to be used (just in time), which often results in a smaller set of architectural diagrams, use cases, and functional specifications. The documents that are created and maintained are only those that are necessary for development (just enough). If a document has outlived its usefulness, it is jettisoned by the team. Producing documentation is appropriate as long as it supports the working software.
Collaboration & Contract Negotiation
All software projects have some type of contract, whether implied or explicit. Implied contracts are used most often for internal software teams; explicit contracts are used for things like hiring an outside software team for a temporary project. The one thing that both of these contract types have in common is a date. Most project managers are familiar with the three sides of the constraint triangle: scope, time, and quality. If time (completion date) is fixed and high quality a priority, the only area for compromise is scope. Negotiating with the customer or product owner on scope is a key component of agile project management. Only the product owner knows the importance of a feature. Only the product owner can make decisions on the relative position of features and which features must be delivered first. Only the product owner can decide that rework of an existing feature is more important than new feature development. The fact that the product owner is part of the team and can see the work as it is completed allows agile teams deliver value earlier than they could using traditional software methodologies.
Responding to Change & Following a Plan
As anyone who has built a house can attest, having a detailed set of blueprints is only the beginning. Compromises and changes are expected and inevitable prior to final delivery. The same holds true in software. Just as a homeowner would not give the blueprints to a builder and never visit the construction site, product owners for software projects shouldn’t just hand the development team a list of requirements and then never see the interim product.
Agile projects allow the product owner to visualize the progress on his project as code begins to work. The product owner is empowered in agile projects to finalize details as work progresses. Returning to our building analogy, during construction, the homeowners pick out fixtures, choose cabinet colors, and sometimes move walls as they begin to see their home emerge. Similarly, the agile product owner fills in the details of his own requirements (or changes his mind about his requirements) as he begins to glimpse the working software. If the product owner decides there needs to be a change in something already developed and that change is more important than new undeveloped features, the project team makes that change. Agile teams, like home builders, respond to change.
An Agile Coexistence
Just as yin cannot exist without yang, the elements that agile practitioners value (working software, collaboration, change, and interactions) do not exist without their corresponding yang (documentation, contracts, plans, and process). These mutually inclusive agile principles also follow the laws of yin and yang. Agile principles are opposing: there must be a plan but the plan will change. Agile principles are mutually rooted: the contract, whether implied or explicit, will require negotiation, so invite the customer to collaborate with the team. Agile principles mutually transform: the team needs some sort of blueprint of what to build but only as much as makes sense and is reasonable to maintain. Finally, Agile principles wax and wane: all software teams need processes and tools to know their boundaries but individuals interacting daily build the best software.
