April 22, 2008
As agile software development approaches are more and more adopted in software development organizations, the title of this book from Kurt Bittner and Ian Spence seems to be right on the target. The book contains two major parts. The first gives an overview of iterative project management. It defines the concepts, discuss controlling and gives tips to assess your readiness for iterative project management. The second is a more detailed walk-through to the planning and management of iterations at different levels. It provides also information on how to assess the results of iterations, discuss the relation between iterative project management and project scales. The last chapter is dedicated to the information needed to start your first iterative project. Finally, appendices provide material on use case development (the topic of a former book from the same authors), templates, checklists and an example of 50 pages.
The process behind the book is widely based on the RUP approach; thus practitioners of a “pure” agile approach could be disoriented by the content. However, this book contains very valuable and pragmatic material about managing iterative project management that could be used in any iterative context. It will also provide good transition information towards an iterative process for project managers that operate in a more traditional organization. With 600 pages, it is a not an easy book that is quickly digested. It will nevertheless helps you to improve you grasp on iterative project management, whether you read the book sequentially or you pick sections according to your current project management questions.
Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk
April 17, 2008
The Software Development Article Directory has now more than 1000 articles in its database. This directory references knowledge-providing articles related to all software development activities (programming, testing, configuration management, process and project management) selected from the best sources on the web.
Some of the last interesting additions to the directory are
Use the best open source tools to work with Web pages, scripts, and styles, and make development of new sites and pages easy.
* Schedule Adherence: A Useful Measure for Project Management
This article utilizes the new practice of Earned Schedule (ES) to discuss a proposed measure for further enhancing the practice of EVM. The measure, Schedule Adherence, provides additional early warning information to project managers, thereby enabling improved decision making and enhancing the probability of project success.
* Focus on Value: How to create value-driven user stories
Agile has a tool that can help organizations re-focus on return on investment: value-driven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea.
March 31, 2008
A you move ahead, keep in mind the following:
* Never confuse the map with the journey – The project plan is only an outline (and a guess at that), so you should believe the team’s results and not the plans. Remember, it is the achievement of the objectives that is important, not the production of artifacts or the completion of activities. Be careful not to confuse the ends (objectives) with the means (artifacts and activities).
* Adopt the attitude that continuous planning is a good thing – In every iteration, expect your plans to change (albeit in small ways if your planning is effective). Don’t fall into the trap of thinking that the plan is infallible.
* Mature your process alongside your team – Tune the working practices alongside the plans, adapt your team’s skills as necessary to improve over time.
* Be prepared to cut your losses – Canceling bad projects early is success because you save time, money and resources that can be applied to better opportunities.
* Be honest – Without objectivity and honesty, the project team is set up for failure, even if developing iteratively.Source: “Managing Iterative Software Development Projects”, Kurt Bittner, Ian Spence, Addisson Wesley.
Transitioning from a traditional approach to iterative software development is more a change of mind than a schedule adjustment. So try to be honest… or at least as honest as you can be ;o)
December 20, 2007
Get additional visibility as your postings will be reproduced in Methods & Tools issues and will reach a worldwide community of more than 50’000 software development professionals. Distribution: Asia 37%, North America 27%, Europe 23%, South America 8%, Africa 3%, Australia 2%.
October 3, 2007
Rest In Peace (from Latin requiescat in pace) is a sentence that typically appears on christian tombstones. Software development projects have usually the same destiny. Once they are finished, often the best thing that will happen is a little celebration for the project team. Nobody will formally look back at a project to understand what went well or wrong and why those things happen, so that this project can actually rest in peace and lessons learned could be used for the next projects. There is however an activity to analyze project after their completion. It is called “post mortem” analysis (so the RIP reference is not far) or “retrospective” in the agile approach. If you have not heard about this practice or never performed such activity, you should not be ashamed. I have never seen its implementation in my software development life. Even in the last Agile survey published by Version One, where a large majority of respondents are using an agile approach, only 39% of the participants are using this practice. Why?
The first explanation is that time is a rare resource in software development organizations. It is often associated to money in budget-driven companies. As there is a sense of urgency, people try to use their available time for the more essential (for them) activities. It is sometimes already difficult to justify taking some time to think before coding, that trying to have time to think after coding could seems an utopia. It is also difficult to tell as a project leader that you will spend some man/days after the project’s completion to think about what went wrong. Are you not supposed to do things right in the first time?
Our difficulty to create a context for constructive criticism is another issue faced when you try to institute some “post mortem” reflections. This is mainly due to the difficulty to separate the problems from the people that are associated to them. This is an important issue in organizations where professional excellence is a driver for monetary gains and career evolution. Will you speak openly about project problems if part of your (or your colleague) salary is a bonus linked to achieving certain professional goals? Maybe not…
There are however techniques that could help you to profit from lessons learned without creating personal issues, so that your past projects could really rest in peace and everybody could improve from a shared experience. You will find more resources about post-mortem or retrospectives for software development projects in the following articles:
* Refactoring Your Development Process with Retrospectives by Rachel Davies (HTML)
* Retrospective Agility by Tim MacKinnon in Objective View issue #8 (PDF)
* Plan of Action by Bas Vodde (HTML)
* Project “Post Mortem” Review Questions by Michael Greer (HTML)
* A Review of Small and Large Post-Mortem Analysis Methods by Mauri Myllyaho1 et al. (PDF)
June 28, 2007
The Software Development Article Directory has just registered its 700th article with “What Have the Romans Ever Done for Us?” ;o) This article is an interesting digression of the differences between software development and software engineering that evolves in a comparison of the agile and planned approaches to software development using the differences between the Greek and Roman civilisations.