Resources

toc =Resources= //Apple Distinguished Educators are invited to join this wiki and add resources...//

Standards

 * NETS•Administrators - []
 * FREE Assessment of NETS*Students [|http://www.simpleassessment.com]
 * ISTE Technology Observation Tool -[| http://icot.craftyspace.com/]
 * Edutopia[| - http://www.edutopia.org/]
 * Partnership for 21st Century Skills - []

Video

 * What kind of Leader are you? - []
 * Presentation Video
 * media type="youtube" key="cf0wwGglmQU" height="344" width="425"
 * Outtakes Video
 * media type="youtube" key="DeWfEFrE1kI" height="344" width="425"

Models of Leadership 2.0 in action

 * Tim Tyson/Mabry Middle School ** - **  []
 * Michael Hyatt- Leadership 2.0 **-** []
 * Chris Lehman
 * Principal of the Science Leadership Academy, Philadelphia, PA
 * Blog: Practical Theory -- [|http://www.practicaltheory.org]
 * Twitter: chrislehmann

Articles

 * Fast Company - Leadership 2.0 - []
 * Control Vs. Influence? - []

Books

 * [|Influencer: The Power to Change Anything] by Kerry Patterson, Joseph Grenny, David Maxfield, and Ron McMillan
 * [|The Global Achievement Gap: Why Even Our Best Schools Don't Teach the New Survival Skills Our Children Need--And What We Can Do About It] by Tony Wagner
 * [|Death by Meeting: A Leadership Fable...About Solving the Most Painful Problem in Business (J-B Lencioni Series)] by Patrick Lencioni
 * [|Outliers: The Story of Success] by Malcolm Gladwell
 * [|Disrupting Class: How Disruptive Innovation Will Change the Way the World Learns] by Clayton Christensen, Curtis W. Johnson, and Michael B. Horn
 * [|A Whole New Mind: Why Right-Brainers Will Rule the Future] by Daniel H. Pink
 * [|The Element: How Finding Your Passion Changes Everything] by Ph.D., Ken Robinson and Lou Aronica

Game Theory
Below is a short article describing Game Flow and the elements that need be included in an activity to make it fun as well as a chart that shows the relationship between ability and challenge, a cornerstone of the Flow theory. Take a look. I think it has some direct application that could be useful as selection criteria for possible solutions to our challenge.

[] > The [|idea behind Planning Poker] is simple. Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again. > User stories define what is to be built in the software project. User stories are prioritized by the customer to indicate which are most important for the system and will be broken down in tasks and estimated by the developers. When user stories are about to be implemented the developers should have the possibility to talk to the customer about it. The short stories may be difficult to interpret, may require some background knowledge or the requirements may have changed since the story was written. Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the customer to verify it. Without a precise formulation of the requirements, prolonged nonconstructive arguments may arise when the product is to be delivered. XP and other agile methodologies favour face-to-face communication over comprehensive documentation and quick adaptation to change instead of fixation on the problem. User stories achieve this by:
 * Game Flow Article.pdf**
 * Agile vs Waterfall resources**
 * Agile Development - []
 * Agile Software Menifesto - []
 * Scrum - Pigs/Chickens - [|http://en.wikipedia.org/wiki/Scrum_(development)]
 * Planning Poker - []
 * Collaborative software development model - [] - A style of software development whose focus is on public availability and communication, usually via the Internet.
 * Agile Modelling - [] - A construct for documentation
 * User Stories - [] - User stories are a quick way of handling customer requirements without having to elaborate vast formalized requirement documents and without performing overloaded administrative tasks related to maintaining them. The intention with the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.
 * Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
 * Allowing developer and client to discuss requirements throughout the project lifetime
 * Needing very little maintenance
 * Only being considered at the time of use
 * Maintaining a close customer contact
 * Allow projects to be broken into small increments
 * Suited to projects where the requirements are volatile (change often) or poorly understood. Iterations of discovery drive the refinement process.
 * May be easier to estimate development effort

Waterfall method -[] - A [|sequential] software development process, in which progress is seen as flowing steadily downwards (like a [|waterfall]) through the phases of Conception, Initiation, [|Analysis], [|Design] (validation), Construction, [|Testing] and [|Maintenance]. Requires early commitment in concept and design phases with little deviation in lower stages resulting in poor agility to deal with new circumstances, challenges, and requirements during the development porcess. Leaves you with a solution that may have worked when you began but now that you are done does not meet all the requirements of your users.
 * Waterfall Method - The old way of doing things. Becomes harder to change as projects grow and develop.

DIscussion
include component="comments" page="home" limit="25"