Projects have been the main working mode of software development activities since the beginning of computers. According to Allan Kelly, it is however not the best mode to develop software. He fosters the #noproject movement to fight project myopia that he defines as the “belief that the project model is the only way of managing business change and development.”
In this short book, a little bit more that 100 pages, Allan Kelly explains why the project model is bad, even in the Agile world, because it denies reality and side-lines business benefit chasing the wrong goals in the wrong way. The goal of a team should be to deliver value over time from small components not to achieve global project delivery goals. This is somewhat that the author relates to programme management. The book lists the important points that an organization needs to follow to be successful outside the project model.
I would recommend this book to every software project manager, product owner, product manager, scrummaster or software developer that are interested in having a different point of view on software development projects.
Reference: Project Myopia, Allan Kelly, http://leanpub.com/myopia
Quotes
Type 1 Project Myopia: Success. Failing to recognize that meeting project success criteria are not the same a successfully delivering business benefit. Project success criteria may actually reduce business benefit in the short term and even more in the long term.
The tension between Agile working and the project model are visible to anyone who must manage or govern projects. Successful Agile teams working under the project model need to satisfy two conflicting regimes.
Fundamentally the project model is about temporary while successful products have longevity, this mismatch imposes costs: management overhead, technical liabilities and most of all lost value. In the past companies could get away with this, but in the digital age, short-sighted project thinking is a price too high.
Ironically, deadlines are useful, deadlines are a great way of organizing work, creating focus and motivating people. Artificial end dates positioned at unnatural times damage software quality.
Rather than ask “How long will this take?” ask “What is the date of maximum value?” and then “What can we build to capture as much of that value as possible?” Effort estimation may have a role in the discussion but it is secondary to business imperatives. Business dates should drive work, not effort estimates.
For many organizations, “agile” is something that happens within a project box. The organization plans projects and projects get delivered. Whether what happens within the box is “agile” or something else is of little concern to the project planning process.
Rather than thinking of “agile project” and doing all the good “agile stuff” within the confines of a project I’m suggesting the organization changes how it understands work altogether.