What follows are some quick thoughts on how to apply insights from the “Agile Manifesto” (see also Martin Fowler’s excellent essay on “The New Methodology” for a nice overview of what agile development entails) to early stage software startups.
| Value This More | In Preference To |
|---|---|
| Individuals And Interactions | Processes And Tools |
| Working Software | Comprehensive Documentation |
| Customer Collaboration | Contract Negotiation |
| Responding to Change | Following a Plan |
Principles behind the Agile Manifesto
| Agile Principle from Manifesto | My Comments for Startups |
|---|---|
| Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. | “early and continuous” are the two key adjectives here. Startup needs to move fast and be able to continue to adapt, refine, and improve subsequent releases. |
| Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. | Ultimately your value is to contribute to your 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. | I think for Saas this is going to work out to be one to two weeks between releases. |
| Business people and developers must work together daily throughout the project. | Co-Evolution of Business and Technical Plans |
| Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. | Essential in a startup. |
| The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. | Certainly where there is a need to get emotional calibration you need at least voice (telephone, VoIP) but face to face is the highest bandwidth. |
| Working software is the primary measure of progress. | If only because it’s the easiest thing for customer’s to judge. But a sales pitch that accurately represents what will be delivered is as necessary, and should in fact precede working code in the early days of a startup. Sell, then Build. |
| Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. | This is a “no finish line” model that assumes you will need to continue to tune and evolve your offering rapidly after it’s introduction. |
| Continuous attention to technical excellence and good design enhances agility. | Especially if you can measure what you mean by excellence and keep score transparently for the whole team. |
| Simplicity–the art of maximizing the amount of work not done–is essential. | Simplicity forces you to focus on customer’s key needs and minimizes the work needed for the next release. Giving the customer software to work with speeds their understanding of their true needs faster than almost anything else (if you start by observing their actual behavior in their environment). |
| The best architectures, requirements, and designs emerge from self-organizing teams. | This to me seems a little to IT or development centric. Many times visionary customers will supply critical insights on architecture and requirements. |
| At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. | Wynton Marsalis advises that “the humble improve.” You need to balance regular celebrations with an appropriate amount of both internally driven and customer solicited evaluation of quality and productivity (yes your customers are making an assessment of how productive the team is and how quickly you can understand, master, and deliver on emerging needs). |
More to come on this, in particular what one to two week release cycles mean for how you organize and execute as a software startup.
Pingback: SKMurphy, Inc. » Quotes For Entrepreneurs–February 2014