For many teams, agile adoption represents an attempt to improve their software process. As an industry, we've been through these process improvement efforts before. Yet we continue to fail. Software development efforts fail because our attempts to improve process are fundamentally flawed. Many adaptations of the most popular iterative and incremental processes are little more than reinventions of faulty practices. They result in slightly varied manifestations of the same problems that have plagued the software industry for years. We will continue to experience this problem until we divert our attention away from software process improvement as an attempt to improve process toward software process improvement as an attempt to speed software delivery. To start, we must focus on the only software artifact required to deliver an application - the code - and begin treating source code as a corporate asset.
Software Delivery
For many teams, the birth of an agile transformation begins with adopting an agile process such as Extreme Programming or Scrum. We might believe that if we write test cases, we are agile. Or if we refactor. Or practice continuous integration. Or manage a Sprint backlog. Each of these may help increase agility, but none guarantee agility. Agility is not defined by process or practice. Agility is defined by ability, the ability to remain nimble and responsive to change. Most importantly, the ability to deliver valuable and reliable software as frequently as possible in the face of change. Yet without the source code teams do not have the ability to deliver software. {sidebar id=1} By nurturing software development's most important artifact, agile teams are able to realize the following benefits from frequent software delivery:
- Soliciting Customer Feedback. Only our customers can provide final judgment on the value of a software application. Neither well articulated requirements specifications nor magnificent architecture diagrams are worth their weight on the paper they are printed if the system doesn't satisfy our customer's needs. Allowing the customer to interact with the application, experience its navigation scheme, and simulate business processes that the software system must support generates feedback that is critical to ongoing development. Obtaining this feedback throughout the development lifecycle ensures the development team has time to respond to customer requests.
- Demonstrating Architecture. Resilient software architecture has a significant impact on the ability of an application to grow as change surfaces. Proving that the application functions beyond the developer's desktop is critical. Can the architecture withstand the load of thousands of users? Is application code synchronized to accommodate multi-threading? Is transactionality setup correctly? These questions can only be answered if we deliver the application to an environment where we can demonstrate architecture.
- Verifying Functionality. Arguably, the most important of all software development activities is testing. This includes unit tests, integration tests, acceptance tests, usability tests, load testing, failover testing, and more. Frequent delivery allows for frequent testing, ensuring that defects are discovered shortly after they are introduced. This continuous emphasis on software verification also establishes a continuous emphasis on software quality.
- Proving the Lifecycle. Failing to establish a software delivery strategy is a challenge that has plagued agile and iterative transition efforts. The common misconception is that software delivery implies a production release. While untrue, this misunderstanding is a formidable force influencing the tendency of many teams to revert to traditional practices. Instead, software delivery involves performing as many lifecycle activities as possible to deploy to a production environment - a subtle yet important distinction. By frequently navigating through the full software lifecycle, agile teams address many of the implementation issues typically encountered when releasing the application to a production environment. For example, agile teams who frequently deliver to a near production environment are forced to establish the necessary procedures to promote database schema changes simultaneously with the application versions requiring those changes. As the production date nears, these teams view production deployment as a logical progression of the application to another tier.
The goal of increased agility is to achieve results through frequent, iterative and incremental delivery of functional software. The more frequently a team delivers a functional application, the more likely the feedback generated from the deliverable ensures the team never strays to far from its intended destination. Beyond simply adopting an agile process, increased agility demands injecting practices throughout the development lifecycle that aim to speed delivery, manage customer feedback, and increase software quality and resiliency.
Agile Injection
Many teams do a good job applying practices espoused by agile processes such as Extreme Programming and Scrum, yet software development continues to be a painful experience because they are not realizing many of the potential benefits of the processes. In lieu of adopting an agile development process, injecting practices that emphasize frequent delivery and feedback can help ease the pain. Such an approach makes an agile transition easier, less risky, and ultimately more beneficial.
There are three important - but narrow - aspects of software delivery and verification that allows you to experience the benefits discussed in the bulleted list above. If you develop a codebase that is infinitely malleable, fully tested, and frequently deployed, your team possesses the ability to continuously deliver a functional software application in the face of change. By emphasizing creation, growth, verification, and deployment of your code from initial project inception to final solution delivery, you are developing an inherently agile software development environment. After injecting these practices, allow them to evolve in a way that helps your team continue to increase agility.
- An Automated Build and Deploy environment enables frequent delivery of functional software. The build and deploy process is the heartbeat of the application development effort. To get started, teams should develop a repeatable build process that includes bundling all application modules and deploying them to a shared environment where the application can be accessed by all key project stakeholders. Initially, teams might correlate their build and deploy process with iteration milestones. For example, monthly iterations might result in a monthly release schedule. However, teams ready to take the next step should deploy a stable version of the application as frequently as daily. Failed builds or failed deploys inform the project team that they have strayed, and must spend the time necessary to rectify the situation. Frequent builds and deploys offer a security blanket to the team - developers know that any problem is only as old as the last successful build and deploy. The more frequent you are able to build and deploy the application, the more frequently you will be able to prove you are still on target. And if your development team doesn't currently have any source code to build and deploy, that should serve as your first warning sign.
- Tracking Running Tested Features (RTF) allows the project team to maintain alignment with key business stakeholders. Tested features correspond to user acceptance tests. In Keep Moving with Running Tested Features, I presented an approach to adopting an RTF strategy. By scripting test cases using a tool like Selenium or FitNesse, you can include these tests into your automated build and deploy process. Each time the application is deployed, it must pass all acceptance tests. Project teams tracking RTF should experience linear growth of tested features throughout the application development lifecycle. Instead of attempting to achieve requirements traceability, surrounding the source code with automated acceptance tests reporting on the current status of an application offers undeniable evidence of the teams progress... or lack thereof.
- Managing Dependencies between software modules enables extensibility, reusability, and maintainability. But excessive dependences cause software to rot. The most common cause of rotting software is tightly coupled code with excessive dependencies. When you establish your initial vision for the software's design and architecture, you imagine a system that is easy to modify, extend, and maintain. Unfortunately, as time passes, changes trickle in that exercise your design in unexpected ways. Undoubtedly, accommodating change is a trademark of agile teams. Yet to deal with change requires an application structure that is extensible, flexible, and resilient. For large teams and large applications, managing dependencies is especially important. In Using Metrics to Help Drive Agile Software, I discussed metrics that offer feedback on dependencies between software modules.
Emphasizing these three key aspects of software development results in a very fluid development process, and serve as the foundation of an agile team. In fact, each plays a critical role in fulfilling the requirements of traditional process activities, but with a significant advantage - each result in executable artifacts, offering a real-time up-to-date glimpse into the application development effort.
Executable Artifacts
The traditional software lifecycle consists of high level activities, each producing an artifact fed into subsequent phases. Many teams adopt agile practices that supplement these traditional lifecycle phases and artifacts. But allowing the three key aspects above to dominate the software lifecycle enables the team to surround the source code with executable artifacts that replace many of the traditional artifacts currently dominating software development teams. Each of these artifacts, executable against the source code, help prove the reliability and resiliency of the application. Exploring these executable artifacts by examining a development scenario is quite revealing.
The Development Scenario
As a project commences, the development team meets with the customer to elicit high level requirements. In lieu of producing a detailed software requirements specification and obtaining signoff from the customer before moving onto development, the development team adopts an RTF strategy. A business analyst develops a suite of acceptance tests using a tool such as Fitnesse or Selenium. Simultaneously, the developers create an automated and repeatable build process scheduled to run hourly. Incorporating execution of the acceptance tests into the build process ensures that the application always satisfies the current set of acceptance tests, which serve as a set of executable requirements for the application development effort.
The priority of the development team is to ensure the application always remains in a functional state by passing all acceptance tests. Because the application is always functional, the development team can deliver the software into the hands of the customer on a frequent basis. As a stop gap to ensure they maintain a high degree of customer feedback, the development team hosts regular application demonstrations for their customers. As customers participate in these demonstrations or interact with the application, the feedback they offer can be managed via an issues backlog that is a valuable input artifact to subsequent iteration planning sessions. As change trickles in and new features are identified, additional acceptance tests are added to the suite.
To ensure the application architecture maintains a high degree of resiliency and adaptability, the team places constant focus on growing their unit test suite and makes certain all unit tests are executed as part of the build process. By ensuring unit tests verify classes and methods in isolation from outside forces, application components are naturally decoupled. To further enhance application architecture, the development team generates a number of software artifacts as part of the build process. Class and component diagrams in conjunction with dependency metrics offer valuable feedback that lead the development team to targeted refactoring efforts to maintain a high degree of architectural and design resiliency.
Eventually, the build process updates a project dashboard that includes important project metrics, including the number of Running Tested Features supported in the current software build. All project participants, including the software development team, customer team, and management team, have access to the project dashboard via a URL, ensuring the team always knows the current state of the application. The consistency and repeatability of this micro process allows the team to identify important trends in development, such as development velocity in terms of the RTF metric. They are able to develop burn down charts, backed by evidence, that help the team provide more reliable estimates based on historical evidence.
In this development scenario, each of the three key aspects of agility served as a powerful catalyst for other important practices. Yet each practice requires the presence of software development's most important artifact - the source code. Once a team begins injecting the practices above into the software development lifecycle, a vicious, self-generating, and remarkably powerful process emerges.
Conclusion
As you consider adopting agile practices, reflect for a moment on the ultimate goal. The purpose of any software development effort is software delivery, not software process improvement. The only artifact required to deliver software is the source code, and it's imperative that we treat source code as a corporate asset. By emphasizing three key aspects of agility, teams surround the source code with important executable artifacts that prove its quality, resiliency, and functionality, Through frequent delivery of functional software, they ensure they never stray to far from the desired destination.
About the Author
Kirk Knoernschild is Senior
Technology Strategist at TeamSoft, where he leads based on his firm belief in
the pragmatic use of technology. In addition to his work on large development
projects, Kirk shares his experiences through courseware development, teaching,
writing, and speaking at seminars and conferences. Kirk has provided training to
thousands of software professionals, teaching courses on UML, Java J2EE
technology, object-oriented development, component based development, software
architecture, and software process.
{mos_sb_discuss:10}
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Show/hide comment form