Playing the Software Development Game

In his book Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development Craig Larman provides this contrasting view of Agile, Iterative development with the sequential or Waterfall approach: We rely on short quick development steps, feedback, and adaptation to clarify the requirements and design. To contrast, waterfall values promoted big up-front speculative requirements and design steps before programming. Consistently, success/failure studies show that the waterfall is strongly associated with the highest failure rates for software projects and was historically promoted due to belief or hearsay rather than statistically significant evidence. Research demonstrates that iterative methods are associated with higher success and productivity rates and lower defect levels. I especially like his description of the up-front requirements and designs as "speculative." In the interest of keeping a project on schedule, the project mana

As a project manager who does not have a programming background, I find it essential to understand as much as possible about the way developers craft solutions to business problems in their code design and implementation. The best developers I know follow a set of design principles and patterns that ensure strong, flexible, extensible, modular code. Writing on this subject at his website http://www.objectmentor.com/ , Robert C. Martin identifies a set of design principles and design patterns that all software development project managers should understand (see http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf ) Here they are in summary: Principles of Object Oriented Class Design The Open Closed Principle (OCP) - A module should be open for extension but closed for modification. The correct use of this principle and its related techniques allow developers to add new features to existing code without changing the existing code and by only adding new code. It is

This is my experience implementing agile development at a commercial software company while I was manager of engineering operations there between April and November 2007. Software development was performed by the company's offshore partner. Until April 2007, the development process used a waterfall approach wherein functional requirements were written in a Functional Requirements Document. Based on that document, the assigned developer would create a technical Design Document. After an engineering development manager in our office approved the Design Document, the developer began development. During the development phase, a tester would create test cases and at the completion of development that tester would perform the quality assurance tests on the software. At one point during the spring and summer of 2007, the combined number of managers, developers, and testers dedicated to our products by our partner exceeded 115. The rationale for moving to an agile methodology included: ma

In order to deliver working software at the end of each iteration and a complete set of features at the end of a release cycle it's important to prioritize features logically to allow testing to begin as early as possible. For example, in one release cycle we added document upload functionality to our citizen access application. The complete set of features included: Upload Document List Documents View Document Delete Document The release cycle included 3 iterations of development and testing. The logical order in which to develop these features would be as they appear above. By developing the upload feature in the first iteration, it could be tested while developers worked on subsequent features. By the same logic, it makes sense to develop the list documents feature before developing the delete document feature (it's hard to test a delete document feature if the software doesn't allow the user to upload a document and see the list of uploaded documents). A developmen

In his book Agile and Iterative Development-A Manager's Guide, Craig Larman compares defined processes, which are suitable for predictable manufacturing domains, with empirical processes, which are used for high-change and unstable domains. When I read this it immediately made sense based on my earliest experiences with software project management. My first experience was development of a Visual Basic client application to monitor and report on translation projects. I had two developers and I was the subject matter expert as well as the project manager. I followed an agile method without even knowing what it was. I wrote the user stories, built simple screen mockups, and prioritized features for rapid delivery and testing. My next experience involved a much larger project, a web application for facilities management, and a large team from a contracted development service provider. We used the contractor's project methodology, which was a very formal, document-intensive process.

In his evaluation of Musashi's The Book of Five Rings , Cockburn asks the question, "Who or what is the opponent in software development?" I have to admit that my initial reaction to that question was to think of the higher levels of management and beauracratic bean counters I have worked with in some organizations. It seems to me that at times they are the only ones standing between the development team and success. But this is Cockburn's observation: The "opponent" is the problem you are trying to solve, the obstacles to delivering the system. "Killing the opponent" is solving the problem, delivering the system. When I considered this it completed the game metaphor. I discussed this idea with members of my team and we had the following thoughts: To the extent we create a solution that is well designed, modular, extensible, and elegant, we win the game, set and match. A solution that lacks some of these attributes may provide a momentary victory,

In his book Agile Software Development - The Cooperative Game (Second Edition) , Cockburn uses an example of an American firm contracting their development to a Russian company. In my own experience I worked for a company that contracted their development to a Chinese company. This presented some significant challenges, including: Language - a minority of the Chinese members of the team spoke English, and even fewer spoke well enough to communicate effectively. Culture - the products we developed were used by city and county agencies in the US for licensing and permitting. They were designed to support processes that are commonly used and understood by US citizens. The business domain supported by our software was unknown to the Chinese team members. They had no first-hand knowledge of the business use cases we supported. Technological Maturity - while I'm sure there are many skilled Chinese software developers, our partner's philosophy was to run a development team along

I recently completed a project manager job application that asked, "when initiating a project, what are the first 3 things that are important to establish?" Here's how I answered, with a little more elaboration than I provided in the application: First, who is the project sponsor (who determines project success or failure; who determines what absolutely must be delivered as opposed to what would be nice to have; who will provide answers to the tough questions and help resolve tough issues? This is important to know because many people will have an opinion about what the project has to deliver, but the PM has to know who's opinion matters most. Next, what are the required features and functions (what must be delivered for the project to succeed) and what are the desired (as opposed to required) features and functions? It's especially important to have something published, like a product roadmap and product requirements document that lists and prioritizes features