Authored by Neil Johnson (submitted by Bryan Morris)
Hardware developers tend to see software development as a foreign land with odd people, languages, tools and techniques. Agile development approaches seem just as odd to most of us even though, according to Forrestor.com, they are becoming mainstream in software development. While software developers have largely accepted the merits of an agile development approach and spend a great deal of time debating the value of one agile technique against another, there is no such acceptance nor debate in IC development circles. This is unfortunate because the underlying values that drive agile teams are not only portable to IC development, they are highly desirable.
In the Beginning
The agile movement started with a collection of disgruntled software developers in 2001. At a weekend retreat at a ski lodge in Utah, a diverse group of individuals advocating differing approaches to software development met to talk about the current state of software development. The group agreed that the top-down, process centric, heavily documented, painfully deliberate style that many organizations followed was proving less and less successful.
As Jim Highsmith writes on www.agilemanifesto.org, everyone agreed that “In order to succeed in the new economy… companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies”. Two days of meetings resulted in the creation of the manifesto for agile software development. The manifesto itself is a set of four values and 12 principles. This article discusses each of the four values (the items on the left), their antithesis (the items on the right) and the implications for IC development.
The Items on the Left
Individuals and Interactions
Software development is carried out by people complemented by process and tools, not the other way around. The writers of the manifesto agreed that companies erroneously linked success to efficient process and tools. The manifesto encourages organizations to see people and communication as the critical factors in building great teams and great software, with process and tools being complimentary.
The insight that product documentation offers will always pale in comparison to the insight gained by seeing the product itself. This is why the manifesto emphasizes the creation of working software as soon as possible, then building on it throughout development. Working software gives the team, stakeholders and customers an opportunity to measure their needs and expectations against a working product. It also allows for refinement as the definition of customer value changes.
The primary goal of any for-profit organization is to actually make a profit. To do that, one needs customers. Happy, repeat customers are ideal. This is why the manifesto encourages regular customer collaboration. Engaging with customers early and often keeps a team in constant synchronization with customer needs. Even better may be to integrate customers with the development team, making them available at all times for consultation.
Responding to Change
For many, responding to change is the core value of an agile team. Software development is a creative process where it is impossible to predict, understand and plan with pinpoint accuracy over an extended period of time. In most cases, long range planning becomes a futile attempt to gain confidence and control over the development process. Absolute confidence and complete control are impossible. Customer needs, requirements, team dynamics and projects goals will change over time turning long range plans obsolete. Agile teams pride themselves on successfully absorbing change by combining detailed short team planning with long range estimates.
The Items on the Right
The final lines of the manifesto read as follows:
“…while there is value in the items on the right, we value the items on the left more.” (www.agilemanifesto.org)
What are the values on the right? They are the values that always seem to represent due diligence and professional practice but have repeatedly lead to project failure, dissatisfied customers and disgruntled employees when allowed to dominate the project environment. The items on the right are:
· processes and tools
· comprehensive documentation
· contract negotiation
· following a plan
Notice that the manifesto does not totally ignore the items on the right. It acknowledges that these items can and do benefit to a project. They should not, however, drive primary course or action for teams nor projects. The items on the right should be used to complement–not dominate–the benefits of individuals and interactions, working software, customer collaboration and responding to change.
Agile Values in IC Development
A preference for individuals and interactions, working software (hardware), customer collaboration and responding to change in IC development would be a marked shift in IC development where arguably, there is a heavy preference for the items on the right. IC development teams rely heavily on tools. They strive for process definition and comprehensive documentation–especially in ASIC development. Requirements are normally hammered out during contract negotiation and change to those requirements–aka. feature creep–is deflected whenever possible.
Is there room, then, for agile values in IC development? Is there any benefit to valuing individuals and interactions, working software (hardware), customer collaboration and responding to change? Could they really help IC development teams create a more productive, more efficient and more enjoyable team environment? Could these strange people from the land of software development actually offer insight that leads to better hardware? The answer to all of the above should be a resounding yes!
Whether they realize it or not, all teams already operate with some level of agility to respond to changing project circumstances. Teams that are more agile are able to minimize the impact of accepting changes; less agile teams cannot.
The challenge, then, is for IC development teams to assess their level of agility with the impact it has on their development team, development process, organization and customer satisfaction. From that assessment, a team can work to transform itself by becoming more agile, more responsive and more successful.
The key to transformation, which may seem counterintuitive and contradict all of what we believe to be true, is to relax the dependency on the items on the right! Consider instead the advantages of becoming more flexible instead of more rigid. Exam the merits of individuals and interactions, working software (hardware), customer collaboration and responding to change and how these values can lead to better solutions.
Subsequent to writing the manifesto, the group that met in 2001 became founding members of a larger body of software developers called the Agile Alliance (www.agilealliance.org). For the original members, other members of the agile alliance and software developers around the world, the manifesto represents an overwhelming opinion that in order to be successful, companies must reevaluate their purpose to gain a more comprehensive understanding of the factors differentiate success from failure.
Some may still trivialize software or IC development as an impersonal, assembly line process where individuals toss code from cubicle to cubicle; but successful development requires far more. On a fundamental level, software development and IC development involves creative problem solving and creative problem solving cannot be shoehorned into an assembly line. Successful products are built through real collaboration by a team that is constantly synchronized with customers needs; individuals understand the context of their efforts and the business they are a part of.
For many teams, being agile will simply entail striking a balance between legacy “Dilbert manifestations of make-work and arcane policies” (www.agilemanifesto.org) and the better rounded, refocused and more humane view of IC development captured by the manifesto. The goal should not be an overnight, wholesale agile transformation. That is sure to end in miserable failure. Instead, teams should take the modest approach of assessing how agile they are today and strive to become more agile tomorrow.
Manifesto for Agile Software Development
“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 plan
That is, while there is value in the items on the right, we value the items on the left more.”
|Kent BeckMike BeedleArie van Bennekum
|Martin FowlerJames GrenningJim Highsmith
|Brian MarickRobert C. MartinSteve Mellor
© 2001, the above authors – www.agilemanifesto.org
 Forrester, Agile Development: Mainstream Adoption Has Changed Agility, http://www.forrester.com/rb/Research/agile_development_mainstream_adoption_has_changed_agility/q/id/56100/t/2, 2010.
(c) Copyright Neil Johnson 2010 – all rights reserved