So-called lightweight software development methods evolved in the mid-1990s as a reaction against heavyweight methods, which were characterized by their critics as a heavily regulated, regimented, micromanaged, waterfall model of development.

Proponents of lightweight methods (and now agile methods) contend that they are a return to development practices from early in the history of software development

http://en.wikipedia.org/wiki/Agile_software_development

iterative and incremental collaboration adaptive http://en.wikipedia.org/wiki/Agile_software_developm

ent

Agile Backlog (critical tasks at bottom, less critical above, unclassified at right)

http://www.cleverhamster.com/

The product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product.

QUESTION: what kind of things do you think should go in a backlog?

A typical product backlog comprises the following different types of items:

Features Bugs Technical work Knowledge acquisitionTechnical work and knowledge acquisition activities also

belong on the product backlog. An example of technical work would be, "Upgrade all developers' workstations to Windows 7." An example of knowledge acquisition could be a product backlog item about researching various JavaScript libraries and making a selection.

http://www.mountaingoatsoftware.com/scrum/product-backlog

By far the predominant way for a Scrum team to express features on the product backlog is in the form of user stories, which are short, simple descriptions of the desired functionality told from perspective of the user. An example would be, "As a shopper, I can review the items in my shopping cart before checking out so that I can see what I've already selected."

Think of user stories as representing a collaboration between the customer and the developers, as opposed to documenting customer requirements. The purpose of this collaboration is to reveal and understand the details of the user stories, which are recorded in the confirmation.

Some people write a short description of the user story on the index card, while others like a statement of the format: [Role] can [capability], so that [benefit] .

The customer writes the user stories because she’s in the best position to know the desired functionality. Each user story must be written in the language of the business. This enables the customer to prioritise the user stories according to their value to the business and their cost, and select the user stories for each iteration. The developers can assist the customer but the responsibility for writing stories must reside with the customer.

http://www.energizedwork.com/weblog/2006/02/user-stories-part-1-what-is-user-story.html

Each iteration involves a team working through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders.

SCRUM ScrumMaster, Product Owner, Development TeamRob Purdie!Sprint (timeboxed )the daily standupDuring the meeting, each group member answers

three questions:[12] What have you done since yesterday? What are you planning to do today? Any impediments/stumbling blocks?Seen this in action with guardian developers

burn down chart

After the first iteration of a project, the efficiency factor can be recalculated to allow for more accurate estimates during the next iteration.

Hybridmethods exist on a continuum from adaptive to

predictivePredictive methods, in contrast, focus on planning the

future in detailPHILOSOPHY

see also :SHOW http://www.pmhut.com/are-we-agile-yet-are-

we-agile-yet

Like open source etc. - moved beyond software

“I have written before about the need to move from Waterfall to Agile thinking for Policy delivery...”

also marketing, international development

Most startups just seem to fail because of lack of market adoption. So it seems to a case of either incorrect understanding of the customer needs

The model is not really bad, in fact it is a great approach if you are building an offering where the customer’s problem and the solution are well known (e.g extending an existing and successful offering). However, we all know that the majority of startups are dealing with ambiguity not only in one but both of these areas (i.e. both the customer’s problem and possible solutions are not completely clear at the start).

Steve blank a serial entrepreneur from the valley articulates this problem in his book the four steps to the epiphany ... He proposed the use of a “customer development model“, where the customer and his needs were at the heart of the startup’s approach and not the product.

http://kuliza.com/2011/05/kickstarting-a-new-age-startup/

rapid prototypes - test market assumptions- increasing the frequency of contact with real customers,

therefore testing and avoiding incorrect market assumptions as early as possible

Continuous Deploymenthttp://en.wikipedia.org/wiki/Lean_StartupMantras flow fast and thick: "Fail fast", "Validate your

vision", "Get out of the building"; there is talk of pivots and iterations, early adopters and positioning.

a successful project is no longer centred on specifications, change requests and resource management; instead lean exponents preach continuous deployment with a continuous feedback loop.

Truthfully, it probably means right now you're doing it wrong. Your projects are cumbersome; you're meddling with Gant charts, when you should be prototyping; you're frittering away time on project status updates, when you could be talking to your end users.

http://madebymany.com/blog/a-baptism-of-lean

Pivot Working with agile methodologies negates the shame of

getting it wrong; conversely, it's acceptable to revisit your idea, revise your plan. Pivoting is at the heart of this concept. The sooner your realise your hypothesis is wrong, the quicker you can revise and retest it, hence the phrase "Fail fast". A pivot is one change - a new customer segment, a different feature - it's not a full abandonment of the work so far. Whatever the amend, you're still learning

http://madebymany.com/blog/a-baptism-of-leanc.f. Apps for good. Also Flickr!a very good presentation on some techniques for testing

ideas without programming, an important part of Lean Startup and something we practice at MxM a lot.

http://madebymany.com/signals/the-lean-startup-movement/get-going-build-and-test-your-idea-without-programming

Getting Real is the business, design, programming, and marketing philosophies of 37signals — a developer of web-based software used by over 1 million people and businesses in 70 countries.

37signals used the unconventional Getting Real process to launch five successful web-based applications (Basecamp, Campfire, Backpack, Writeboard, Ta-da List), and Ruby on Rails, an open-source web application framework, in just two years with no funding, no debt, and only 7 people.

http://gettingreal.37signals.com/toc.phpcrowdfundingJargon to spot:Extreme Programming, Scrum, Kanban, Theory of

Constraints, Lean Thinking and Systems Thinking.STARTUPSThe Business Model Canvas in 2 minutes:http://www.businessmodelgeneration.com/canvasVIDEO http://www.youtube.com/watch?

feature=player_embedded&v=QoAOzMTLP5s