The Agile Manifesto values “customer collaboration over contract negotiation.” A more traditional way of doing things would be to lock-in the system requirements early on in the project. Any subsequent change in direction will require contractual changes for “added scope” or “scope change”, and formal CCP (Contract Change Proposal) negotiations. Although this type of project control mechanism helps keep the size of the project in check (and thus helping limit growth in costs and schedule) in the end it may mean that a very long time could be spent up front developing, refining, and validating requirements, but the customer may not get the best software product. The customer may get what they agreed to contractually, but not get the software that they really need.
There are two distinct problems with this “fixed requirements” attitude: –
The “ah-hah” moment: the first time that you actually use the working product. You immediately think of 20 ways you could have made it better. Unfortunately, these very valuable insights often come at the end. (Deemer et al. 2009) – It is a well-known fact that undetected requirements defects can wreak havoc on a project if detected late in the schedule. Indeed, that is one of the reasons that the Waterfall method came to be, to lock-down and specify the requirements so that later development could proceed without turbulence. However, as discussed previously, in a changing environment requirements must evolve. When requirements are locked-in up front, there is no room for making the product better later in the development cycle.
Often the customer (e.g. the DoD) interfaces with the contractor’s business operations and project managers. Requirements are generated by business analysts (in some industries also referred to as “system engineers” or “domain experts”) and are flowed down to the development team. This means that the people implementing the software are at least two or three degrees of separation away from the customer. To make things worse, the customer is often not the end user of the software product. For example, the real end-user might be a soldier in the field.
Consider how the waterfall life cycle evolved. First the software development process was divided into phases—planning, analysis, design, coding, testing—and then roles were assigned to each phase—planner, analyst, designer, coder, tester—and then documents were defined for each phase—plan, specification, design document, code, test cases. As roles gave rise to specialized groups and people believed that documentation could convey all the required information to the next group, the barriers to conversation became greater and greater. (Highsmith 2002b).
For this research, the “Customer-focused” gene means accepting changing requirements and including the user and/or customer in the development team (to the degree that this is possible). This can be in daily stand-ups, design reviews and product demos. The customer’s availability and input to the development process helps to reduce uncertainty and identify rework early. This requires working with the user/customer to evolve the requirements throughout the process – with later requirements informed by insights gained from earlier development.
An Example of this is the “Product owner” role in the Scrum process, whereby a customer or user proxy is present at all team meetings (the daily Scrum), and is the witness of product demos to give real-time feedback.
Team Dynamics
The “Team Dynamics” gene represents the collection of “soft factors” and effects related to unique agile practices and approaches, and how they affect the development team’s performance.
The majority of Agile methods call for frequent meetings to allow teams to self organize, prioritize, and assign tasks, while communicating roadblocks. The most efficient and effective method of conveying information to and within a development team is face to-face conversation (Allen & Henn 2006). Practices such as ‘pair programming,’ and attitudes such as ‘collective code ownership’ also are claimed to have positive effects on project performance.
A unique team dynamic that emerges in agile teams is a distinctive “social/schedule pressure” effect – As teams convene frequently (on a daily basis, in most cases) to report on what they are doing, what they have done, and what they plan to do next, a certain level of peer pressure comes into play, driving individuals to perform at a higher productivity. Additionally, when developing in short increments/sprints, the team experiences more frequent bouts of schedule pressure coinciding with the end of each iteration, as opposed to a single end-of-project schedule pressure effect.
Another well-known agile practice is that of Pair Programming. In pair programming, two programmers jointly produce work products (e.g. code, design documentation). The two programmers periodically switch roles as “the driver” controls the pencil, mouse, or keyboard and writes the code. The other partner continuously and actively observes the driver’s work, watching for defects, thinking of alternatives, looking up resources, and considering strategic implications. The partners deliberately switch roles periodically. This practice has been reported in most cases to reduce productivity but produce higher quality code.
Team co-location and open workspaces and environments are also preferred in Agile teams. These also help promote the flow of information between and drive team performance through transparency.
Continuous Integration
Agile methodologies often include certain policies and approaches to Configuration Management (CM,) as well as a high level of automation of as many aspects of the development process as possible, to speed up the development by eliminating repetitive and manual tasks.
Traditionally, the popular CM approach was to have different teams develop portions of the software in isolated environments, and integrate their work products later, towards the end of the development cycle. In the mid-1990s, Microsoft moved beyond the Waterfall approach to a “synch-and-stabilize” process which relies primarily on daily builds for frequent synchronizations and incremental milestones for periodic stabilizations of the products under development (Cusumano & Smith 1995). This is one of the early examples of automating nightly software builds and frequently integrating various pieces of software under development to detect early conflicts. That is one example of Continuous Integration.
This gene also includes test automation. Testing can be automated at various levels, from unit testing, to the of system-level tests. Test automation means having software perform the testing that would otherwise need to be done manually. Once tests have been automated, they can be run quickly and repeatedly. This is the most cost effective method for software products that have a long maintenance life, which often requires copious regression testing to verify that there is no breakage in baseline functionality introduced by added features.
Traditionally software houses employ a different set of standards and practices when it comes to software development versus software delivery. In fact, it often is the responsibility of two completely different teams, whom often use a different set of tools and environments. The delivery team’s focus is to compile and ship working software, not necessarily developing code. However Continuous Integration calls for a shared environment for both – integrating and automating as much as possible. Some principles of Continuous Integration are:
Development:
1) Stay current (merge code early and often)
2) Deliver working code (don’t submit changes that break the build) 3) If the code changes, write a new test
Delivery:
1) Build from a clean environment.
2) Fixing the build is top priority.
3) Tests should be thorough and repeatable, and run automatically to verify the build.
Research into agile methodologies has revealed a set of recurring patterns and similarities across the software industry. We have captured the essence of what we think makes a software project Agile in the following seven characteristics we now dub the “Genome of Agile” – see Table 4 – The Genome of Agile.
