Geeks With Blogs
Murat Uysal

3) Agile Project Management Model


3.1) Envision


“The purpose of envisioning phase is to clearly identify what is to be done and how the work is to be accomplished.” (Highsmith 2004 p89)


“During the Envision phase the vision constantly evolves based on new information. After the Envision phase it needs to be reviewed periodically to ensure that the team continues to understand the vision. (Highsmith 2004 p90)


Envision stage in Agile Project Management includes activities to answers questions like what is the vision of the product, what will the product deliver to the customer, what will be the structure of the team, how the development team will develop the product and so on. You can compare the activities in this stage with the activities in define/analysis stage of traditional project management stage.


Highsmith discusses some activities in this stage such as creating product image box which is the image of the product and product data sheet which is a single page summary of business objectives, product specification and project management information. For the sake of this review, these activities are not discussed in detail. You can find detailed explanations at the chapter 5.


“Envisioning doesn’t stop after the Envisioning phase. At the beginning of each iteration (or milestone), as the team meets to speculate to next iteration, team members need to revisit the vision. This revisiting can be for the purpose of modifying the vision or to remind the team, amid the hectic daily grind, of the purpose of their endeavors.” (Highsmith 2004 p125)


3.2) Speculate


“The product of the Speculate phase is a release plan that outlines, to the best of the project team’s initial knowledge, a plan that is based on features delivered rather than activities. The release plan utilizes information about the product’s specification, platform architecture, resources, risk analysis, defect levels, business constraints, and target schedules


There are crucial components of an iterative planning and development approach – short iterative timeboxes and features. For software projects, iterations are generally two to six weeks in length. … Short iterations act to accelerate projects. By keeping timeframes short, teams have to figure out faster ways of accomplishing every aspect of development. .. In iterative development, QA activities are completed every iteration. (Highsmith 2004 p129)


During the Speculate phase the project team will come together with the customer and create a feature list, prioritize the features. After the list is defined and prioritized the features for each development iteration is scheduled. However during the planning of each iteration the features listed in this plan can change.


It is better to schedule the high risk features early in development. For highly uncertain features prototypes can be developed to explore different alternatives. 


“Iterations produce acceptance-tested features. The goal is to have partial-feature product that could be deployed at the end of any iteration –that is, the features, tests, documentation, and other product deliverables could be packaged up and deployed.” (Highsmith 2004 p142)


Scheduling features for each iteration bring feature-driven development which uses features instead of tasks during planning.  This way the progress is determined by the number of features implemented/not implemented in the iteration and provides a better communication with customer regarding customers do not understand or care about the specific tasks to implement a feature instead they are directly interested in the feature (value).  Milestones can be scheduled in the release plan to conduct reviews that are not appropriate for each iteration like reevaluation of project vision, scope, team’s progress and performance.


3.3) Explore


“The purpose of the Explore phase is to deliver tested, accepted features” (Highsmith 2004 p167)


“…Delivering customer today and tomorrow—they are driven by the desire to keep the cost of change, the cost of experimentation, to a minimum, thereby greatly expanding the design possibilities…. Four technical practices –simple design, frequent integration, ruthless testing and opportunistic refactoring … are critical to adaptability” (Highsmith 2004 p171)


3.3.1) Simple Design

“There are two fundamental approaches to managing change – anticipation and adaptation… Anticipation involves planning for the future and predicting what kinds of change are probable. Adaptation means waiting until requirements evolve or changes manifest themselves and building them into the product. Adaptation also means experimenting, selecting those experiments with the best results and incorporating those results into the product. The lower the cost of change, the lower the cost of experimentation, the higher the likelihood of significant innovation” (Highsmith 2004 p173)


While the design needs to provide flexibility for the foreseeable changes (anticipated changes) more important than this it should be flexible enough in order to adapt to a change. This will require designing the product that is easier to refactor. The design should welcome changes and shouldn’t be rigid. In most cases this can be achieved by designing the system to solve the existing challenges firstly but refactoring it to design patterns which provides proven and tested solutions for a set of problems and makes the design better aligned with the upcoming challenges. High cohesion and low coupling are the principles that need to be observed through the design to make it open to changes.


3.3.2) Frequent Integration


“The objective of frequent integration is to ensure that product features fit together into an integrated whole early and often during development in order to reduce both the high cost of late misalignment and the burden of testing… the less frequent the integration, the more susceptible the development effort will be to major problems late in the process and the mire difficult, and expensive, it will be to find and fix them.” (Highsmith 2004 p175)


As we all know the later we catch a bug the more prices we pay for it. Frequent integration where I would like to use the term Continuous Integration (CI) will provide us a better picture about the development. The power of CI comes with catching the problems as soon as they arises instead of waiting and letting it to cause some other problems. In a typical scenario you can implement policies that can be triggered at each check-in of the code to the source control system and automatically runs tests, performs code/design analysis, deploys the product and any custom task you define.


3.3.3) Ruthless Testing


“The objective of ruthless testing is to ensure that product quality remains high throughout the development process… Ruthless testing contributes the goal of creating adaptable products because finding faults early, when there is still time to correct them, reduces the cost of change… Constant ruthless testing, including acceptance testing, challenges the development team—no matter what the product—to face the reality of how its design actually works.


In software development, ruthless testing includes software engineers performing constant unit testing, integrating quality assurance and acceptance testing into each development iteration, and having a full range of those tests automated. The ultimate goal is to produce a deployable, limited feature product at the end of each iteration” (Highsmith 2004 p178 – p179)


Creating automated suite of tests includes but not limited to unit tests, regression tests, integration tests, acceptance tests provides direct feedback to technical and functional design of the software. By automating the test it becomes easier to get feedback and find faults. Having different sets of test, testing technical and functional requirements of software gives developer more confidence on changing the code-base without worrying checking-code in that breaks other parts of the software. Although ruthless testing does not specify the place of writing the unit test namely before or after writing the corresponding unit of code, there is tremendous value of writing the test before writing the code which is practiced under Test-Driven Development (TDD). TDD provides a more test-centric development and ultimately trying to achieve no line of code goes to production without a corresponding test.


3.3.4) Opportunistic Refactoring


“The objective of opportunistic refactoring is to constantly and continuously improve the product design—make it more adaptable—to enable it to meet the twin goals of delivering customer value today and in the future … Refactoring involves updating a product’s internal components (improving the design), without changing externally visible functionality, in order to make the product easier to enhance in the future…” (Highsmith 2004 p179)


Refactoring is the answer to adapt to the change in software design. By gaining knowledge at each change, the anticipated changes needs to be reevaluated which will require redesign the existing product. After redesigning and refactoring the code the code base needs to be leaved in a better condition. Having suite of test is really important to make sure that the refactoring does not cause any problems namely changes existing functionality.


Simple design, frequent integration, ruthless testing and refactoring are inter-dependent, hand in hand activities that need to be followed through the software development so that one can not be practices truly without practicing the others.


3.4) Adapt


“Adaptation depends upon understanding a wide range of information, including an assessment of the project’s progress, technical risks, the requirements evaluation, and ongoing competitive market analysis… Every project team needs to constantly evaluate and make appropriate adaptations in the following four areas:


Ø       Product functionality, primarily from the customer team’s perspective

Ø       Product quality, primarily from the technical team’s perspective

Ø       Team performance

Ø       Project Status

” (Highsmith 2004 p213)


This stage includes but not limited to product evaluation, design/code review, team performance reviews, project status review. The purpose of this reviews and evaluations is to get more feedback from customer and team in order to gain more knowledge and take and adaptive action.


“Adaptive action conveys a sense of responding rather than correcting. … Adaptive actions run the gamut, from minor tweaks to the next iteration’s planned features, to adding resources, to shortening the project’s schedule (with appropriate feature adjustments). Adaptive adjustments can impact technical activities (e.g. allocating more time for refactoring) or modify delivery process to make them more effective. Any of the four review types – product, technical, team, project status-- can result in adaptive actions. ” (Highsmith 2004 p230)


3.5) Close


“Organizations have a tendency to spend too much time initiating projects and too little time closing them. … Since resources are always scarce, people moved on the next project quickly, often without taking time to close up the last project and get credit for its completion.” (Highsmith 2004 p231)


Activities like celebration, cleaning up open items, finalizing documentation and production or manufacturing support material and prepare required end-of-project administrative financial reports. These activities will increase the knowledge throughout the organization and provide knowledge transfer for other projects. (Highsmith 2004 p231-p232 rephrased)


Now that we know how to and where to apply agile principles throughout project development, let's end the series with a brief summary about the APM in the next post...

Posted on Sunday, November 13, 2005 1:54 PM Book Reviews , Agile Project Management | Back to top

Comments on this post: Agile Project Management - Jim Highsmith Ch 3

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Murat Uysal | Powered by: