Just how much can people factors influence your project cost and effort?  24.6 percent!  In other words, the least experienced team (the bottom 15 percent) can require up to 24.6 times as much effort to complete a project as the most experienced team (top 10 percent.) In Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers, Steve McConnell writes about the Cocomo II model and how personnel factors influence project cost and effort.

The Cocomo II Model
How much do personnel factors influence the project’s cost and effort over the base estimate?  The Cocomo II Estimation model uses 7 factors to figure out the influence score.  The influence score is used to adjust a base effort estimate.

7 Personnel-Oriented Factors
According to McConnell, these are the 7 personnel-oriented factors and their influence rating:

• Application Experience (1.51)
• Communications Factors (1.53)
• Language and Tool Experience (1.43)
• Personnel Continuity (1.51)
• Platform Experience (1.40)
• Programmer Capability (1.76)
• Analyst Capability (2.00)

The 7 personnel-oriented factors can exert a cummulative influence range of 24.6.  (Multiply each factor … 1.51 x 1.53 x 1.43 … etc.)

3 Seniority-Oriented Factors
Experience alone is a big factor.  According to McConnell, here’s the three seniority-oriented factors and their influence rating:

• Application Experience (1.51)
• Language and Tool Experience (1.43)
• Platform Experience (1.40)

The 3 seniority-oriented factors can exert a cumulative influence range of 3.02.

Key Take Aways
I think this gem supports what I already intuitively know and have experienced but helps quantify it.  Here’s my key take aways:

• Experience plays an enormous role in cost and effort.
• No matter how good your process is, it won’t make up for good people.
• Nonprocess-oriented organizations succeed if they have the right people.

Additional Resources

• Cocomo II (Wikipedia)
• Cocomo II Website
• Steve McConnell

Do you practice the habits of highly successful software architects? Can you deliver a solution while acting as a technical mentor, empowering others, improving the process, and developing a focused, high-performance team along the way? In Software Architect Bootcamp, Raphael Malveau and Thomas J. Mowbray, Ph.D. write about the habits of successful software architects..

7 Habits of Highly Successful Software Architects
According to Malveau and Mowbray, the seven successful habits are:

• Keep it simple.
• Let others defend the architecture.
• Act don’t argue.
• Keep an eye on the prize.
• Be willing to change, but never too much at once.
• Learn where to stop.
• Know how to follow.

Keep It Simple
Avoid complicated explanation.  Keep it high level and grounded in principle.  Malveau and Mowbray write:

When communicating various architectural concepts or software mechanisms to team members, resist the temptation to provide a complete and detailed explanation of how things work or a detailed comparison against all the alternatives in front of a group.  Instead, the software architect should say enough to communicate the idea at a level that is high enough to be generalizable but just low enough to be understood in principles, so that the individual team members can do their own homework or meet separately with the architect to address their specific concerns.

Let Others Defend the Architecture.
If you’re the only one defending the architecture, there’s a problem.  Malveau and Mowbray write:

It is always preferrable to have someone respond to a technical concern rather than have the software architect appear to be the sole source of knowledge.  it reinforces teamwork, provides the architect with insights from people who agree as well as disagree, and is a key aspect in mentoring others, among other benefits.

Act Don’t Argue
Rather than argue, focus on results.  Keep it objective and keep things moving forward.  Lead by example.  Malveau and Mowbray write:

Arguing technical points in a meeting wastes, time, hurts feelings, and seldom if ever fully resolved any technical issues.  When such an argument starts, the software architect must act - by assigning people to get or verify the relevant information, setting up a meeting specifically for resolving the debated topic, or, if time requires an immediate course of action, laying down the law by explaining why the time constraints force an end to the matter.

Keep an Eye on the Prize
Have the overall vision in mind.  Malveau and Mowbray write:

Software architects must always be aware of the end goal.  It is easy to be distracted by tasks and smaller technical issues, and frequently other team members will succumb to oneform of tunnel vision or the other.  However, it is vital that the architect always be focused on the overall vision of the system and relate every task or technology to how it contributes to the end goal.

Be Willing to Change, But Never Too Much at Once
Be flexible in your approach, but make incremental changes.  Malveau and Mowbray write: 

After the initial bootstrapping of a software development effort, the architect should be wary of implementing too many process improvements all at once because there is a risk of compromising the effective parts of the process.

Learn Where to Stop
Don’t micromanage the design.  Malveau and Mowbray write the following:

Software architects must resist the temptation to go into too many details and to micromanaging design decisions.  For example, it would typically be enough to specify that caching is required in client applications and that the caching code should be resused throughout the application.  However, detailing the specific caching algoritm used or writing the caching pseudocode is probably overkill.  Learning to trust other team members to provide design and implementation details and letting them ask for help is essential.

Know How to Follow
Avoid public confrontation.  Malveau and Mowbray write:

No matter who is in charge, software architects should avoid publicly confronting others on major design issues.  This can be accomplished by knowing ahead of time what is going to be discussed and the reasons for the various decisions.  This is a key aspect to developing a focused, high-performance team.

Key Take Aways
Being in the software building business, I can easily relate to this. I think there’s a couple of themes that underly the habits:

• Balance connection-focus with task-focus. Building software is a team sport. It often means building rapport and getting others to buy into ideas over time. While knowing your stuff is a good thing, you should use it to lift others up and produce a great results. Winning technical battles at the expense of the human relations war, will cause unecessary friction and reduce your results and drain your energy.
• Focus on value delivered over the shiny object. If you’re passionate about the technology, it’s easy to fall into the trap of focusing on the technology or the shiny objects. At the end of the day, your credibility and perception will be about the solution you deliver and the team impact.
• Be a mentor and a coach. It’s true that knowledge is power. The trick is to grow yourself, by growing others. What you share comes back to you tenfold.

My Related Posts

• Why Do We Need Software Architects

I cycle through a lot of books each year on software development, project management, design, patterns, architecture … etc.  While many are throw aways, some of the books have stood the test of time.  I continue to turn to them time and again.  Here’s a list of my favorite software books::

General

• Microsoft 2.0: How Microsoft Plans to Stay Relevant in the Post-Gates Era - (Mary Jo Foley) - This is a relatively new book in my collection.  It’s a thought proving book with insight into Microsoft’s future.  It includes thoughts on leadership, potential products, management, product development styles, licensing issues, rising stars, and business models,

Agile

• Agile Project Management: How to Succeed in the Face of Changing Project Requirements - (Gary Chin) - Learn practical strategies for taking charge of crucial but unpredictable projects.  Lear how to develop a strong and supportive project management infrastructure and culture.  Learn how to improve communication between project teams and business decision-makers.  Learn how to improve the productivity of fast-paced projects without increasing risk.  
• Agile Software Development, Principles, Patterns, and Practices (Alan Apt Series) - (Robert C. Martin) - Learn how to use Agile Development for getting projects done on time, and on budget.  See real-world case studies to learn how to plan, test, refactor, and pair program using eXtreme Programming.  Learn how to apply UML and Design Patterns to solve customer-oriented systems problems.
• Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series) - (Martin Fowler) - Learn expert techniques to improve the structural integrity and performance of existing software.  Learn how to take a bad design and rework it into well-designed, robust code.  Provides a detailed catalog of more than seventy proven refactorings with tips on when to apply them, step-by-step instructions for applying each refactoring, and an example that shows how the refactoring works.
• Scaling Software Agility: Best Practices for Large Enterprises (Agile Software Development Series) - (Dean Leffingwell) - Learn how to apply agile methods to enterprise-class development.  Learn an overview of Agile, learn seven agile team practices that scale, and learn how to achieve Enterprise agility.

Architecture

• A Practical Guide to Enterprise Architecture (Coad Series) - (James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo) - Learn which strategies work and why for Enterprise architecture.  Learn proven product-line practices for streamlining the design of enterprise software.  Learn how to translate key business drivers into enterprise architecture output.  Learn agile architeture and modeling techniques.  Learn how to create a reusable base of core assets.  Learn how to transition to agile methods.
• Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures (Addison-Wesley Object Technology Series) - (Hassan Gommaa) - Learn product line engineering process.  Learn how to model the common and variable functionality of a product line.  Learn how to model common, optional, and alternative product line features.  Learn software architectural patterns for product lines.
• Enterprise Architecture Using the Zachman Framework (MIS) - (O’Rourke, Fishman, Selkow) - Learn a complete introduction to the fundamental concepts of enterprise architecture.  Learn a framework that promotes holistic thinking, teamwork, individuality, and responsibility.
• Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) - (Martin Fowler) - Learn how to divide an application into layers.  Learn the major approaches for organizing business logic.  Learn how to map between objects and relational databases.  Learn how to use Model-View-Controller.  Learn how to handle concurrency for data that spans multiple transactions.  Learn how to design distributed object interfaces.
• Software Architect Bootcamp - (Raphael Malveau, Thomas J. Mowbray, Ph.D.) - Learn how to choose the right architetural model for your project.  Learn how to manage complexity, scalability, reliability, security, latency, and flexibility.  Learn how to make the most of abstraction, refactoring, and architectural prototyping.  Leverage proven design patterns and anti-patterns.  Learn effective prototyping, business-case development, and project leadership.  Learn how to manage your own career as a software architect.
• Software Architecture in Practice (2nd Edition) (SEI Series in Software Engineering) - (Len Bass, Paul Clements, Rick Kazman) - Learn how to perform architecture design and analysis.  Learn how to capture quality requirements and achieve them through quality scenarios and tactics.  Learn how to use architecture reconstruction to recover undocumented architectures.  Learn how to document architecture using UML. 

Consulting

• Secrets of Consulting: A Guide to Giving and Getting Advice Successfully - (Gerald M. Weinberg) - Learn how to price and market your services, measure your effectiveness, and deal with client resistance.  Learn memorable rules, laws, and principles for effective consulting.

Design

• About Face 2.0: The Essentials of Interaction Design - (Alan Cooper, Robert Reimann) - Learn Goal-Directed Design, how to design behavior and form, how to apply visual design principles, effective user interaction, and how to communicate with users effectively.
• The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience - (Douglas K. Van Duyne, James A. Landay, Jason I. Hong) - Learn proven solutions to common Web design problems, including naviation, content management, e-commerce, and site performance.  The book is organized as collections of patterns and uses visual examples from actual sites on the Web.

Fundamentals

• Code Reading: The Open Source Perspective (Effective Software Development Series) - (Diomidis Spinellis) - Learn how to identify good (and bad) code, how to read it, what to look for, and how to use the knowledge to improve your own code.
• The Pragmatic Programmer: From Journeyman to Master - (Andrew Hunt, David Thomas) - Learn how to write flexible, dynamic, and adaptable code, bullet proof your code, capture real requirements, effective testing, delight your users, build teams of pragmatic programmers.
• Write Great Code: Volume 1: Understanding the Machine - (Randall Hyde) - Learn the foundation upon which all great software is built.  Learn how computer systems execute programs and how abstractions in programming languages map to the machine’s low-level hardware.

Interviews / Jobs

• How Would You Move Mount Fuji? Microsoft’s Cult of the Puzzle - How the World’s Smartest Company Selects the Most Creative Thinkers - (William Poundstone) - Learn “puzzle interview” techniques and examples that challenge your intelligence, imagination, and problem-solving ability.
• My Job Went to India: 52 Ways to Save Your Job (Pragmatic Programmers) - (Chad Fowler) - Learn 52 ways to keep your job, despite the changing tech landscape.  Learn a decision-making process for choosing wich technologies to focus on and which business domains to master so that you invest your time and energy in the right areas.  Learn how to develop a structured plan for keeping your skills up-to-date so that you can complete with both the growing stable of developers in so-called low-cost countries as well as your higher-priced local peers.  Learn how to shift your skillset up thte value chain, from an offshore-ready commodity to one in high demand.  Learn how to market yourself both inside your company and to the industry in general.
• Programming Interviews Exposed: Secrets to Landing Your Next Job (Programmer to Programmer) - (John Mongan, Noa Suojanen) Learn how to ace programming interviews.  Learn how to gain critical interviewing skills, how to ask effective questions, how to best approach a problem, and what to do when you get stuck.

Management

• Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Coad Series) - (David J. Anderson) Learn how to develop management disciplines for all phases of the engineering process, implement realistic financial and production metrics, and focus on building software the delivers maximum customer value and outstanding business results.  Learn how to make the business case for agile methods.  Learn how to choose an agile method for your next project.  Learn how to apply Critical Chain Project Management and constraint-driven control of the flow of value.
• Antipatterns: Identification, Refactoring, and Management (Auerbach Series on Applied Software Engineering) - (Phillip A. Laplante, Colin J. Neill) Learn 48 bad management practices and environments common to software development, IT, and other organizations.  Learn how to correctly identify problems in your own work environment and take action to correct them.
• How to Run Successful Projects III: The Silver Bullet (3rd Edition) - (Fergus O’Connell) Learn the Ten Steps of Structured Project Management.  Learn how to do the least amount of project management possible and still be sure of a successful outcome.  Learn how to identify and monitor your project’s vital signs.  Learn a quick and easy way to assess project plans and proposals so you can catch potential disasters before they happen.  Learn daily, weekly, and monthly routines.
• Managing the Design Factory - (Donald G. Reinertsen) Learn a methodical approach to consistently hit the “sweet spot” of quality, cost, and time in developing any system.  Combines the powerful analytic tools of queuing, information, and system theories with the proven ideas of organization design and risk management.
• Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers - (Steve McConnell) - Learn effective software development practices.  Learn how to create career paths for software professionals.  Learn the impact of personnel and processes.  Learn how much difference there is between the worst software companies and the best.
• Software Architecture: Organizational Principles and Patterns (Software Architecture Series) - (David M. Dikel, David Kane, James R. Wilson) Learn how to establish product-line architectural frameworks and vision that managers, administrators, and developers can buy into.  Learn how to implement architectures that anticipate and predict change, and can easily adapt to new business requirements.  Learn how to address the organizational issues that make or break enterprise software architectures.
• Successful Project Management - (Gido, Clements) Learn the essential concepts and processes to work successfully in a project management environment.  Learn how to organize and manage effective project teams.  Learn how to document and communicate project developments within and outside the team.
• The Project Manager’s Pocket Survival Guide - (James P. Lewis) - Learn how to keep your projects and your career on track. Learn the nitt-gritty realities of project management as politics, personalities, motivation, teamwork, and leadership.
• Under Pressure and On Time (Pro-Best Practices) - (Ed Sullivan) - Learn practical strategies and a proven model for developing great teams and world-class software.  Learn how to recruit, interview, and retain the right people, build the right organizational structure, and create the right corporate culture for a great software-development effort.  Learn how to acquire the best development tools and establish the correct processes for quality assurance and release engineering.  Learn how to manage the relationship between your requirements, usability model, technology foundation, and schedule.

Modeling

• Agile Modeling: Effective Practices for Extreme Programming and the Unified Process - (Scott W. Ambler) - Learn how to model on an XP project.  Learn how to model to explore an issue or to facilitate communication.  Learn how to write agile documents to reduce your documentation burden. Learn how to use simple modeling tools, such as index cards, and whiteboards.

Patterns

• Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition) (Sun Core Series) - (Deepak Alur, John Crupi, Dan Malks) Learn the 21 patterns in the J2EE Pattern Catalog.  Learn effective patterns, strategies, and refactorings.  Learn design strategies for the presentation, business, and integration tier.  Learn how to refactor to improve existing designs using patterns.
• EJB Design Patterns: Advanced Patterns, Processes, and Idioms - (Floyd Marinescu) Learn effetive architectural, transaction, concurrency, client-side, and primary key generation patterns.  Includes a catalog of twenty advanced EJB patterns.  Learn strategies for applying the patterns, best practices for J2EE development, and useful EJB tips and techniques.
• Head First Design Patterns (Head First) - (Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates) Learn the patterns that matter, when to use them and why, how to apply them to your own designs, when not to use them, and OO design principles that patterns are based.
• J2EE Design Patterns Applied - (Cragy A. Berry, John Carnell, Matjaz B. Juric, Meeraj Moidoo Kunnumpurath, Nadia Nashi, Sasha Romanosky) - Learn how to apply patterns to construct a robust and manageabile web tier.  Learn how to apply patterns to construct a resuable persistence framework.  Learn how to apply patterns to improve your application’s performance and scalability.  Learn how to apply patterns to manage your application’
  s security.  Learn how to apply patterns to enable enterprise integration.
• Patterns in Java: A Catalog of Reusable Design Patterns Illustrated with UML, 2nd Edition, Volume 1 - (Mark Grand) Learn seven fundamental design patterns, six creational patterns, three partitioning patterns, nine structural patterns, eleven behavioral patterns, and eleven concurrency patterns.  Includes practical, hands-on examples of pattern implementation in Java.

Performance

• Code Optimization: Effective Memory Usage - (Kris Kaspersky) Learn typical mistakes.  Learn how to eliminate problems with effective patterns and practices.  Learn how to perform algorithmic optimization.
• Concurrent Programming in Java(TM): Design Principles and Pattern (2nd Edition) (Java Series) - (Doug Lea) - Learn key concepts of concurrent programming including: confinement and synchronization, deadlocks and conflicts, state-dependent action control, asynchronous message passing, and control flow, coordinated interaction, and how to structure web-based and computational services.
• Java 2 Performance and Idiom Guide - (Craig Larman, Rhett Gurthrie) - Learn how to optimize for speed and space.  Learn design-level optimization principles.  Learn environment and tool strategies.  Learn algorithm and data structure strategies.  Learn language and library specific optimization techniques.
• Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software (Addison-Wesley Object Technology Series) - (Connie U. Smith, Lloyd G. Williams) - Learn proactive versus reactive performance management.  Learn how to use UML for software performance engineering.  Learn how to specify key performance scenarios and performance objectives.  Learn how to construct and solve performance models.  Learn how to plan and conduct performance measurements.  Learn principles for performance-oriented design.  Learn patterns for achieving responsiveness and scalability.  Learn anitpatternsthat illustrate what not to do and how to fix a problem when you find it.  Learn effective performance tuning strategies.  Learn how to integrate software performance engineering into the life cycle.
• Web Performance Tuning, 2nd Edition (O’Reilly Internet) - (Patrick Killelea) - Learn principles and patterns for thinking about the performance of your web site.  Includes case studies of performance problems and solutions.  Learn how to measure performance.  Learn performance tuning in depth.

Process

• Software Engineering: A Practitioner’s Approach - (Roger S. Pressman, Ph.D) Learn the software process.  Learn modern analysis, design, and testing methods.  Learn how software engineering practices can be adapted to Web applications.  Learn how to plan, manage and control a software project.  Learn formal methods. cleanroom software engineering, component-based approaches, and reengineering.
• Software Engineering Processes: With the UPEDU - (Pierre N. Robillard, Philippe Kruchten) Learn the essentials of the software development process.  Learn the methods, tools, and concepts of the software life cycle. Learn the core engineering and management disciplines.  Learn the quality aspects of the software process.  Learn a software process metamodel that is the a theoretical foundation for any software process.

Requirements

• Managing Software Requirements: A Use Case Approach (2nd Edition) (Addison-Wesley Object Technology Series) - (Dean Leffingwell, Don Widrig) Learn the five steps in problem analysis.  Learn business modeling and system engineering.  Learn techniques for eliciting requirements from customers and stakeholders.  Learn how to establish and manage project scope.  Learn how to apply and refine use cases.  Learn product management.  Learn how to transition from requirements to design and implementation.  Learn how to transition from use cases to test cases.  Learn agile requirement methods.
• Mastering the Requirements Process (2nd Edition) - (Suzanne Robertson, James Robertson) - Learn the requirements process.  Learn how to bring rigor, traceability, and completeness to requirements.  Includes checklists to help identify stakeholders, users, non-functional requirements, and more.  Learn how to exploit use cases to determine the best product to build.  Learn how to reuse requirements and requirement patterns.
• Requirements-Led Project Management: Discovering David’s Slingshot - (Suzanne Robertson, James Robertson) Learn how to use requirements as input to project planning and decision-making.  Learn how to determine whether to invest in a project.  Learn how to deliver more appropriate products with a quick cycle time.  Learn how to measure and estimate the requirements effort.  Learn how to define the most effective requirements process for a project.  Learn how to set requirements priorities. Learn how to manage requirements across multiple domains and technologies.  Learn how to use requirements to communicate across business and technological boundaries.
• Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle - (Ian F. Alexander, Neil Maiden) Learn a rang of scenario techniques from light, sketchy and agile, to careful and systematic.
• Writing Better Requirements - (Ian F. Alexander, Richard Stevens) - Learn how to write simple, clear requirements.  Learn how to organize requirements as scenarios.  Learn how to review requirements.
• Writing Effective Use Cases (Agile Software Development Series) - (Alistair Cockburn) - Learn a proven methodology for taking advantage of use cases.  Learn the key elements of use cases, including actors, staeholders, design scope, scenarios, and more.  Includes a use case style guide with action steps and suggested formats.  Learn time-saving use case writing tips.

Security

• Secure Coding: Principles and Practices - (Mark G. Graff, Kenneth R. van Wyk) Learn effective security principles and practices for design, coding, and operations. 

Writing

• The Best Software Writing I: Selected and Introduced by Joel Spolsky - (Joel Spolsky) - Experience well-writen essays on ideas in software, edited and introduced by Joel Spolsky.
• Weinberg on Writing: The Fieldstone Method - (Gerald M. Weinberg) Learn secrets for gathering, organizing, and discarding ideas.

What’s your favorite software books?

Extreme Programming (XP) is a lightweight software development methodology based on principles of simplicity, communication, feedback, and courage.   I like to be able to scan methodologies to compare approaches.  To do so, I create a skeleton of the activities, artifacts, principles, and practices.    Here are my notes on XP:

Activities

• Coding
• Testing
• Listening
• Designing

Artifacts

• Acceptance tests
• Code
• Iteration plan
• Release and iteration plans
• Stories
• Story cards
• Statistics about the number of tests, stories per iteration, etc.
• Unit tests
• Working code every iteration

12 Practices

Here’s the 12 XP practices:

• Coding Standards
• Collective Ownership
• Continuous Integration
• On-Site Customer
• Pair Programming
• Planning Game
• Refactoring
• Short Releases
• Simple Design
• Sustainable Pace
• System Metaphor
• Test-Driven Development

For a visual of the XP practices, see a picture of the Practices and Main Cycles of XP.

5 Values (Extreme Programming Explained)

• Communication
• Courage
• Feedback
• Respect
• Simplicity

Phases

The following are phases of an XP project life cycle.

• Exploration Phase
• Planning Phase
• Iteration to Release Phase
• Productionizing Phase
• Maintenance Phase

For a visual overview, see Agile Modeling Throughout the XP Lifecycle.

12 Principles (Agile Manifesto)

These are the 12 Agile principles according to the  Agile Manifesto:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development.   The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

4 Values (Agile Manifesto)

These are the four Agile values according to the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Additional Resources

• Using an Agile Software Process with Offshore Development (Martin Fowler)
• Extreme Programming (Ward Cunningham’s Wiki)
• XProgramming.com (Ron Jeffries)
• Agile Manifesto
• Extreme Programming (Wikipedia)
• Practices and Main Cycles of XP (Ron Jeffries)
• Extreme Programming Core Practices (Ward Cunningham’s Wiki)

My Related Posts

• MSF Agile at a Glance
• Rational Unified Process (RUP) at a Glance
• Microsoft Solution Framework (MSF) at a Glance

The Microsoft Solutions Framework (MSF) provides people and process guidance—the proven practices of Microsoft—to help teams and organizations become more successful in delivering business-driven technology solutions to their customers.  Note that this MSF is not the same as the MSF Agile process included in VSTS.  I like to be able to scan process methodologies.  To do so, I create a skeletal view of the activities, artifacts, … etc.   Here’s my notes on the Microsoft Solution Framework circa 2005, which might be a bit dated, but provide a quick lens into the main ideas:

Artifacts

Envisioning

• Vision/scope document.
• Risk assessment document.
• Project structure document.

Planning

• Functional specification
• Risk management plan
• Master project plan
• Master project schedule

Developing

• Prototype
• Source code
• Executables
• Installation scripts and configuration settings for deployment
• Frozen functional specification
• Performance support elements
• Test specifications
• Test cases

Stabilizing

• Golden release
• Release notes
• Performance support elements
• Test results and testing tools
• Source code and executables
• Project documents
• Milestone review

Deploying

• Operation and support information systems
• Procedures and processes
• Knowledge base, reports, logbooks
• Documentation repository for all versions of documents, load sets, and code developed during the project
• Project close-out report
• Final versions of all project documents
• Customer/user satisfaction data
• Definition of next steps

Additional Resources

• Microsoft Solutions Framework (TechNet)

My Related Posts

• MSF at a Glance
• Rational Unified Process (RUP) at a Glance

I like to be able to scan process methodologies so I create skeletal views that let me quickly see the key activities, artifacts, principles, and practices of a methodology.  MSF for Agile Software Development is a scenario-driven, context-based, agile software development process.   Here’s my notes on MSF Agile circa 2005, which might be somewhat dated, but at least give me a quick lens into the main ideas:

Principles

• Partner with customers
• Foster open communications
• Work toward a shared vision
• Quality is everyone’s job every day
• Stay agile, adapt to change
• Make deployment a habit
• Flow of value

Mindsets

• Quality Is Defined By Customer
• Pride of Workmanship
• Team of Peers
• Frequent Delivery
• Willingness to Learn
• Get Specific Early
• Qualities of Service
• Citizenship

Workstreams

• Capture Project Vision
• Create a Quality of Service Requirement
• Create a Scenario
• Guide Project
• Plan an Iteration
  Guide Iteration
• Create a Solution Architecture
• Build a Product
• Fix a Bug
• Implement a Development Task
• Close a Bug
• Test a Quality of Service Requirement
• Test a Scenario
• Release a Product

Activities By Workstream

Capture Project Vision

• Write Vision Statement
• Define Personas
• Refine Personas

Create a Quality of Service Requirement

• Brainstorm quality of Service Requirements
• Develop Lifestyle Snapshot
• Prioritize Quality of Service Requirements List
• Write Quality of Service Requirements
• Identify Security Objectives

Create a Scenario

• Brainstorm Scenarios
• Develop Lifestyle Snapshot
• Prioritize Scenario List
• Write Scenario Description
• Storyboard a Scenario

Guide Project

• Review Objectives
• Assess Progress
• Evaluate Test Metric Thresholds
• Triage Bugs
• Identify Risk

Plan an Iteration

• Determine Iteration Length
• Estimate Scenario
• Estimate Quality of Service Requirements
• Schedule Scenario
• Schedule Quality of Service Requirement
• Schedule bug Fixing Allotment
• Divide Scenarios into Tasks
• Divide Quality of Service Requirements into Tasks

Guide Iteration

• Monitor Iteration
• Mitigate a Risk
• Conduct Retrospectives

Create a Solution Architecture

• Partition the System
• Determine Interfaces
• Develop Threat Model
• Develop Performance Model
• Create Architectural Prototype
• Create Infrastructure Architecture

Build a Product

• Start a Build
• Verify a Build
• Fix a Build
• Accept Build

Fix a Bug

• Reproduce the Bug
• Locate the Cause of a Bug
• Reassign a Bug
• Decide on a Bug Fix Strategy
• Code the Fix for a Bug
• Create or Update a Unit Test
• Perform a Unit Test
• Refactor Code; Review Code

Implement a Development Task

• Cost a Development Task
• Create or Update a Unit Test
• Write Code for a Development Task
• Perform Code Analysis
• Perform a Unit Test
• Refactor Code
• Review Code
• Integrate Code Changes

Close a Bug

• Verify a Fix
• Close the Bug

Test a Quality of Service Requirement

• Define Test Approach
• Write Performance Tests
• Write Security Tests
• Write Stress Tests
• Write Load Tests
• Select and Run a Test Case
• Open a Bug
• Conduct Exploratory Testing

Test a Scenario

• Define Test Approach
• Write Validation Tests
• Select and Run a Test Case
• Open a Bug
• Conduct Exploratory Testing

Release a Product

• Execute a Release Plan
• Validate a Release
• Create Release Notes
• Deploy the Product

Artifacts (Work Products)

• Vision Statement
• System Architecture (See DSI and Whitehorse)
• Test Plan (see Context-Driven Testing)
• Personas
• Scenarios
• Storyboards
• Development Tasks
• Interface Models
• Architectural Prototypes
• Unit Tests
• Classes
• Change Sets
• Check In Notes
• Test Cases
• Bug Reports

Disciplines

• Requirements
• Planning
• Architecture
• Development
• Test

Who Does What

Business Analyst

• Capture Project Vision
• Create a Quality of Service Requirement
• Create a Scenario

Project Manager

• Guide Project
• Plan an Iteration
• Guide Iteration

Architect

• Create a Solution Architecture

Developer

• Build a Product
• Fix a Bug
• Implement a Development Task

Tester

• Close a Bug
• Test a Quality of Service Requirement
• Test a Scenario

Release Manager

• Release a Product

Cycles and Iterations

• Product definition, development, and testing occur in overlapping iterations resulting in incremental completion of the project.
• Different iterations have different focus as the project approaches release.
• Small iterations allow you to reduce the margin of error in your estimates and provide fast feedback about the accuracy of your project plans.
• Each iteration should result in a stable portion of the overall system.

Iterations

Iteration 0

• Project Setup
• Plan

Iteration 1

• Plan
• Develop and test
• Feedback

Repeat as needed

• Plan
• Develop and test
• Feedback

Iteration N

• Develop and test
• Release product

Team Model

Advocacy Groups

• Architecture.
• Development
• Product Management
• Program Management
• Release Management
• Test
• User Experience

Who Advocates What

• Architecture - advocates for the System in the Large.
• Development - advocates for the Technical Solution.
• Product Management - advocates for the Customer Business.
• Program Management - advocates for Solution Delivery.
• Release Management - advocates for the smooth delivery and deployment of the solution into the appropriate infrastructure.
• Test - advocates for Solution Quality from the Customer Perspective.
• User Experience - advocates for the most effective solution in the eyes of the intended users

Team Principles

• Team of Peers.  A team of peers with clear accountability, shared responsibility and open communications. Each role is accountable for a specific share of the quality of the overall solution.
• Advocacy for All Key Constituencies.  Advocacy for all key constituencies who must be represented on a successful software project. Every perspective is represented to provide the checks and balances that prevent errors of omission and lopsided decisions.
• Stretch to Fit.  Stretch to fit to the scale necessary for the specific project. Constituencies may be combined in small teams or further refined as teams scale for larger projects.

Governance

Concerns the control of time and money relative to the flow of value:

• Are we doing the right thing?
• Can we do it within time and budget?
• Are we ready to integrate?
• Are we ready to deploy?
• Are we realizing the value?

Additional Resources

• Microsoft Solutions Framework (Wikipedia)

My Related Posts

• Rational Unified Process (RUP) at a Glance

I like to be able to scan process methodologies so that I can quickly compare approaches.  I found my old notes on Rational Unified Process (RUP).  I think they’re circa 2005, so they could be a bit dated:

Six Key Principles

• Adapt the process
• Balance stakeholder priorities
• Collaborate across teams
• Demonstrate value iteratively
• Elevate the level of abstraction
• Focus continuously on quality

Activities

Analysis and Design

• Assess viability of Architectural Proof-of-Concept (Architect)
• Architectural Analysis (Architect)
• Identify Design Mechanisms (Architect)
• Identify Design Elements (Architect)
• Construct Architectural Proof-of-Concept (Architect)
• Incorporate Existing Design Elements (Architect)
• Describe the Run-time Architecture (Architect)
• Describe Distribution (Architect)
• Capsule Design (Capsule Designer)
• Database Design (Database Designer)
• Use-Case Analysis (Designer)
• Use-Case Design (Designer)
• Subsystem Design (Designer)
• Class Design (Designer)
• Design Testability (Designer)
• Elements (Designer)
• Design the User-Interface (User-Interface Designer)
• Prototype the User Interface (User-Interface Designer)
• Review the Architecture (Technical Reviewer)
• Review the Design (Technical Reviewer)

Implementation

• Structure the (Software Architect)
• Implementation Model (Software Architect)
• Implement Developer Test (Implementer)
• Execute Developer Test (Implementer)
• Analyze Runtime Behavior (Implementer)
• Implement Design Elements (Implementer)
• Implement Testability Elements (Implementer)
• Develop Installation Artifacts (Implementer)
• Plan System Integration (Integrator)
• Plan Subsystem Integration (Integrator)
• Integrate Subsystem (Integrator)
• Integrate System (Integrator)
• Review Code (Technical Reviewer)

Artifacts

Analysis and Design

• Deployment Model
• Software Architecture Document
• Analysis Model
• Design Model
• Architectural Proof-of-Concept
• Reference Architecture
• Interface
• Signal
• Event
• Protocol
• Capsule
• Testability Class
• Design Class
• Analysis Class
• Use-Case Realization
• Design Subsystem
• Design Package
• Navigation Map
• User-Interface Prototype
• Data Model
• Test Design

Implementation

• Implementation Element
• Implementation Subsystem
• Testability Element
• Test Stub
• Integration Build Plan
• Build
• Implementation Model

Phases

• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase

Disciplines

Development Disciplines

• Business Modeling
• Requirements
• Analysis & Design
• Implementation
• Test
• Deployment

Support Disciplines

• Configuration Management & change management
• Project management
• Environment
• Operations & support

Enterprise Disciplines

• Enterprise business modeling
• Portfolio management
• Enterprise architecture
• Strategic reuse
• People management
• Enterprise administration
• Software process improvement

Additional Resources

• IBM Rational Unified Process (Wikipedia)
• Rational Unified Process Home (IBM)

How do you create a candidate architecture in XP?  The solution is to pick a set of stories that force you to build a skeleton of the system as a whole in your first iteration.  If you can’t find the stories that force you to create the architecture you need, then you either put as much architecture in place as you need for now or you put the whole architecture in place on speculation.  In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes about building a functional skeleton of the system.

System Architecture

Beck writes:

Architecture is just as important in XP projects as it is in any software project.  Part of the architecture is captured by the system metaphor.  If you have a good metaphor in place, everyone on the team can tell about how the system as a whole works.

The First Iteration Must Be a Functioning Skeleton of the System as a Whole

Beck writes:

The next step is to see how the story turns into objects.  The rules of the Planning Game state that the result of the first iteration must be a functioning skeleton of the system as a whole.  But you still have to do the simplest thing that could possibly work.  How can you reconcile these two?

Pick a Set of Stories that Force You to Create the Whole Architecture

Beck writes:

For the first iteration, pick a set of simple, basic stories that you expect will force you to create the whole architecture.  Then narrow your horizon and implement the stories int eh simplest way that can possibly work.  At the end of the exercise you will have your architecture.  It may not be the architecture you expected, but then you will have learned something.

Put as Much Architecture as You Need or Put the Whole Architecture in Place on Speculation

Beck writes:

What if you can’t find a set of stories that force you to create the architecture you know, you absolutely know, you are going to need?  Either you can put the whole architecture in place on speculation, or you can put as much architecture in place now as you need to meet your current needs, and trust that you can put more in later.  I put in the architecture I need now and trust my ability to change it later.

Key Take Aways

Here’s my key take aways:

• Have a system metaphor.
• Pick a set of stories that force you to build a skeleton of the system as a whole.
• If you can’t find the right stories, then either base the architecture on speculation or put as much architecture in place as you need for now.

Additional Resources

• System Metaphor (C2.com)

My Related Posts

• Periodic Design Refactoring
• Architectural Styles, Patterns, and Metaphors
• Architectural Patterns vs. System Metaphors

How can you leverage XP practices in a fixed-price contract?   One approach is to fix the price and the schedule, but somewhat vary the scope.  You reduce risk by fixing the cost and schedule.  Flexing the scope means that you can respond to the customer’s changing needs as you deliver value.  You can think of this as the customer subscribing to your development team’s service for a period of time.  In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes about how to deal with fixed price contracts in XP.

Fixed Price / Fixed Date / Roughly Variable Scope

Beck writes:

Folks seem to have the most trouble running a fixed price contract extreme.  How can you do a fixed price / fixed date / fixed scope contract if you play the Planning Game?  You will end up with a fixed price / fixed date / roughly variable scope contract.

Read more »

How do you gradually shift responsibility for a system to the customer?  How do you reduce the risk of a customer inheriting a system they can’t sustain?  Rather than outsourcing, you can consider “insourcing.”   In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes that insourcing is where you gradually replace the members of the team with technical folks from the customer.

Gradually Replace Team Members with the Customer

Beck writes:

The “big thump” delivery of outsourcing violates the incremental change principle.  There is a slight twist on outsourcing that XP can deliver.  What if you gradually replaced the members of the team with technical folks from the customer?  I call this “insourcing.”

Read more »