You are previewing Agile Development & Business Goals: The Six Week Solution.

Agile Development & Business Goals: The Six Week Solution

Cover of Agile Development & Business Goals: The Six Week Solution by Bill Holtsnider Published by Morgan Kaufmann
  1. Copyright
    1. Dedication
  2. Preface
    1. Who is This Book Written for?
      1. Types of Individuals
      2. Types of Development Teams
      3. Start-Ups
      4. Internal Software Development Groups
    2. Chapter summary
    3. Acknowledgments
      1. Reviewers
      2. Graphics
      3. People at MKP
      4. Families
  3. 1. Introduction: Ask Yourself These 10 Key Questions
    1. Introduction
    2. Ten Questions to Ask about Your Software Development Process
      1. 1. Align software development with business needs
      2. 2. Compensate aggressively
      3. 3. Addresses both core business and core technical components
      4. 4. Make it simple to describe
      5. 5. Produce revenue-generating software
      6. 6. Tie your investment to software delivery
      7. 7. Account directly for quality
      8. 8. Hit your short-term goals while...
      9. 9. Addressing your long-term goals at the same time
      10. 10. Reward success and make tangible the effects of failure
    3. Why Listen to us?
      1. Our experience
      2. We are extensively experienced professionals
      3. This process is different
      4. The process has been vetted
      5. Grosch’s law, paraphrased
      6. The other half
  4. 2. The Problem: Why Software Projects Fail
    1. Introduction
    2. Historical Perspective
    3. The Scope of Software
      1. Complexity
      2. Delivery
      3. Even developers seldom understand the scope of the software they work with
    4. Software Development Often Fails
    5. The Need for Process
    6. A Common Question
      1. Delivery
      2. Build the right software—that is, the software you need
      3. Poorly understood requirements
      4. Adapting software development to business processes
      5. Another issue: needs change over time
      6. Newly exposed opportunities
    7. Software Development is Hard—Very Hard
      1. It requires an unusual mix of art and science
    8. Why Other Agile Methodologies Often Fail
      1. If a release fails, developers don’t lose money
    9. Why Waterfall Processes Often Fail
      1. Waterfalls and crystal balls
      2. Killing your project with process
      3. Specific costs of change
      4. Reactions to this list
      5. Software reality #1: software changes
      6. Software that is not changing is dying
    10. High Visibility
      1. The business gets regular updates on what development is doing
    11. Death March
      1. A death march story
    12. Man in a Room
    13. The Rogue Developer
    14. “Are you Done Yet?”
    15. Budget Black Hole
      1. Tuesday/Friday problem
    16. Why the Six Week Solution is different
  5. 3. Expectations: What It Means for Software to Succeed
    1. Introduction
    2. Software Development Sometimes (Accidentally) Succeeds
    3. Is Aligned with Business Needs
    4. Manages the Cost of Change
    5. Is Built in an Automated Way
    6. Factors Quality into the Core of the Process
    7. Is Not Constantly Being Redeployed
    8. Progress is Constantly Being Made
    9. Delivers Something of Value
    10. Is Evangelical
    11. Is Predictable
    12. Is Both Tactical and Strategic
    13. Is Game Changing
    14. Allows Management to Stay Informed
    15. Is Measurable
  6. 4. Overview of the Six Week Solution
    1. Introduction
      1. 1980s Company culture
    2. Additional Problems
      1. Product management
      2. Long- and short-term goals
      3. Sales
      4. Marketing
      5. Advance planning
      6. It’s like building a house, only it is not
    3. Components of Agile Alignment
    4. Why Six Weeks?
      1. Establishing a rhythm
      2. The need for rhythm
      3. Six Week Solution calendar
      4. Manageable time frame
      5. Most things can wait
      6. Boundary to benchmark progress and make commitments
      7. Two cycles per quarter
      8. Opportunity to change direction
      9. Forcing scope
    5. Cycle Commitments
    6. Developer Compensation: COD
      1. Provides Motivation
    7. Six Week Iterations
    8. Time Boxing Development: Key Deadlines
    9. Week 1: Cycle Kickoff
      1. Planning week
      2. You get to play with technology
      3. Cycle finalization
      4. Cycle sign-off
    10. Week 3: Mea Culpa
      1. Gut-check time
      2. Other Mea Culpa issues
    11. Week 6: Testing
      1. Cycle sign-off
    12. Steering with Business Goals
      1. Avoiding obstacles
      2. Delayed decision making
      3. The challenge for the business
      4. Hitting a wall
      5. When to quit
  7. 5. The Solution’s Critical Pieces
    1. Introduction
    2. The Big Game
    3. The Entire Company Must Buy In
      1. Hybrid won’t work
      2. Business involvement
      3. Evangelism
      4. Eleven weeks
      5. Why senior management involvement is key
      6. Full cycle business participation
      7. Delivery channels
    4. Work Space
      1. The bullpen
      2. Work area
      3. Size of teams
      4. Teams of teams
    5. Personnel Roles
      1. Bullpen leads
      2. Developers
      3. The cowboy coder
      4. Quality Assurance
      5. Documentation
      6. Product management
    6. Hiring Smart
      1. College graduate
      2. Five to 10 years of experience
      3. The seasoned developer
      4. The sweet spot: 10–20 years
      5. Team building through hiring
      6. Interviewing
      7. “D-IQ” (Developer IQ)
      8. Probing questions
      9. Tour of the physical workplace
      10. Profiling
      11. Things to watch out for
      12. Other considerations
      13. Hiring summary
    7. Compensation
      1. Base pay
      2. Compensating QA
      3. Team compensation
    8. Development Tools
      1. Coding standards
      2. Collective code ownership
      3. Automation
      4. Testing levels
    9. Cycle Commitments
      1. Inputs
      2. Let management know what you need
      3. True Negotiation
      4. Good commitment definition
      5. Coordinate the dependencies
      6. Never commit to delivery of external dependencies
      7. Software changes and upgrades
      8. Hardware changes and upgrades
      9. Scoping
      10. Fixed iteration scope
      11. Scope control
      12. Negotiate task lengths
      13. Commit to full utilization
      14. Communicate dependencies
      15. Sample cycle commitment pitfalls
      16. Do not deviate from cycle commitments
      17. Cycle success
  8. 6. Managing the Cost of Change
    1. Introduction
    2. Flattening the Curve with Feedback Loops
      1. Frequent releases (product feedback)
      2. Customer is on-site
      3. Deploy every release?
      4. Frequent iterations (planning feedback and Mea Culpa)
      5. Frequent status updates (work coordination feedback and the daily stand-up meeting)
      6. Frequent programmer rotation (directional feedback and intraday reviews)
      7. Frequent integrations (product progress feedback and automated regression test)
      8. Frequent testing (task progress feedback and unit tests)
      9. Frequent discussion (concept feedback and pair programming)
    3. Avoiding the Curve by Managing the Unknown
      1. Unknown #1: how do I plan the future?
      2. New technological opportunities/threats
      3. Unknown #2: what is needed?
      4. Unknown #3: when will it be done?
      5. Unknown #4: when is it done?
      6. Unknown #5: how do we not block ourselves?
      7. Unknown #6: what will implementation require?
      8. Unknown #7: what was broken in the process?
      9. Unknown #8: will the product be maintainable in the face of change?
    4. Lowering the Curve by Increasing Productivity
    5. Providing Effective Tools
    6. Languages and Tooling
      1. Pace of tools
      2. Tools
    7. Buy, Don’t Build
    8. Effective Communication
      1. Colocation
      2. IM
      3. Documentation
      4. Tests as documentation
      5. Executable requirements
      6. Unit tests
      7. Code as documentation
      8. Tools as communication
      9. Documentation archives
      10. Documentation archives, really
      11. Wiki
      12. Sustainable pace
      13. Quality again
      14. Pair programming makes it all go smoother
    9. Gauging Performance with Pairs
      1. Taking on responsibilities over assigning work
      2. Leaving programmers room to problem solve
  9. 7. Assuring Software Quality
    1. Introduction
    2. The Value of Quality
      1. Debt management strategies
    3. External Software Quality
      1. Feature set
      2. Usability
      3. Reliability
    4. Internal Software Quality
      1. Software fundamentals
      2. Error-free execution
      3. Flexible code structure
      4. Expressive code
    5. Symptoms of Design Rot
      1. Constant open heart surgery
      2. Groundhog day
      3. Four-letter features
      4. Single-use tools
      5. Lipstick on a pig
      6. Fear of the future
      7. Fortress of solitude
    6. Quality and Software Craftsmanship
      1. Marks of a craftsman
      2. Managing complexity
      3. Code cleanliness
    7. Size of Work Pieces
    8. Unit Testing
      1. Peer input
  10. 8. Integrating Automation into Your Development Process
    1. Introduction
    2. Continuous Integration
      1. QA doesn’t need every build!
      2. Continuous integration provides high visibility without a lot of work
      3. Problems with visibility
    3. Build Process
    4. Metrics
      1. Stupid coder tricks
      2. Unused code
      3. Cyclomatic complexity
      4. Inconsistent synchronization
      5. Code test coverage
      6. Productive code discussions
      7. Unproductive code discussions
    5. Automation Tools
      1. The IDE—Eclipse
      2. Source control
      3. The repository—Maven
      4. Metrics—PMD, CPD, and FindBugs
      5. Build server—Hudson
      6. Bug tracking
      7. Communications
      8. Documentation tools
      9. X-unit test frameworks
      10. Executable requirement integration test tools
      11. Code coverage—Cobertura
  11. 9. Other Software Development Approaches
    1. Introduction
      1. Delivery
      2. Build the right software
      3. Build the software right
      4. Visibility and adaptation
    2. Simplified Evolution of Software Processes
      1. First industry driver: automation
      2. Process version 0.0: man in a room
      3. Process version 1: analyze, design, code, test, and maintain
      4. Process version 2: waterfall
      5. Spiral development traps
      6. Agile
      7. Next driver: the loose customer link
  12. 10. Risks with Using This Approach
    1. Introduction
    2. Workplace Challenges
      1. Risk: personality issues
    3. Work Environment
      1. Risk: no offices
    4. Why This is Not a Risk
      1. Risk: noise level
      2. How to mitigate this risk: cry room
      3. How to mitigate this risk: meeting rooms
      4. Risk: if you mismanage any aspect of the Six Week Solution, you are going to have to lie to developers
      5. Risk: if you mismanage any aspect of the Six Week Solution, you are going to have to lie to customers
      6. Poison customers
      7. Risk: there is no place to hide, physical or virtual
      8. Why this is not a risk
      9. Risk: this is a different culture
      10. Why Six Weeks is not a risk
      11. Risk: how to sell the Six Week Solution
      12. Risk: convincing the development team
      13. Risk: convincing executives
      14. How to mitigate this risk: keep your promises
      15. Risk: why are developers getting bonuses?
      16. How to mitigate that risk: two possible responses
      17. Why this is not a bad thing: the safety to fail
      18. Why this is not a bad thing: nobody bats .1000
      19. Why the short-term fix won’t work for the long term
    5. Risk: Abandoning Quality for Bonuses
      1. Planning iterations with four dials
      2. Risk: if you are a screwup, everyone will see it
    6. Management Challenges
      1. When to cut losses
      2. Cultural shift within the company
      3. The “Next Client-Facing Release” is not an option
      4. Temptation of giving up the rules under pressure
      5. Band-Aid fixes
    7. Quality Concerns
      1. Developer temptation to cut quality to meet the cycle
    8. Design Debt
    9. Hard to Transition
      1. Possible solution: hire an outside development team
      2. Risk: business wants a death grip on the assembly line
    10. Smaller but Still Potentially Problematic Risks
      1. Half-ass requirement requests
      2. There need to be consequences for not following the rules
      3. Too flat/too hierarchical
      4. No clear career path
      5. People will go over your head
  13. 11. Transitioning to the Six Week Solution
    1. Introduction
    2. Before you do Anything, Though
      1. Use source control
    3. Automate the Build
    4. Selling This Idea up the Chain
      1. Senior management backing
    5. Selling It to Sales and Marketing
      1. Sales department
      2. Marketing department
      3. Release numbers: a small but important point
    6. Determine your Aggressiveness on Cycles and Compensation
    7. Set Expectations from the Start
      1. Restructuring event
      2. Legacy fortresses
    8. Pick the Date for the Cutover
    9. Use the Language of the Process
    10. Transitioning the Development Team
      1. Starting A New Team
      2. Taking over an existing team
      3. Transitioning from Agile
      4. Transitioning from “wingin’ it”
      5. Transitioning from a “death march”
    11. Creating the Baseline—Your First Six Week Cycle
  14. 12. Conclusions
    1. Introduction
    2. Aligns Software Development with Business Needs
    3. Developers are Compensated Based on Their Performance
    4. Addresses Both Core Business and Core Technical Components
    5. Simple to Describe to Everyone in the Company
    6. Designed From the Ground Up to Produce Revenue-Generating Software
    7. Ties Directly into your Investment in your Software Development
    8. Accounts Directly for Quality
    9. Allows you to Hit your Short-Term Goals While Addressing your Long-Term Goals at the Same Time
    10. Rewards Success and Penalizes Failure
    11. What to do Next
  15. Glossary
  16. Sources
O'Reilly logo

Chapter 1. Introduction: Ask Yourself These 10 Key Questions

Introduction: Ask Yourself These 10 Key Questions

Introduction

Creating software is a difficult, expensive, and time-consuming process fraught with perils for your budgets and your deadlines. It is also challenging, potentially very rewarding financially, and filled with pockets of excitement and unpredictability that will keep you on your corporate toes. It is not for the faint of heart.

The Six Week Solution is a unique and powerful process of creating software. To determine if this process is right for you, ask yourself the following ...

The best content for your career. Discover unlimited learning on demand for around $1/day.