Rationale

toc =Decision Making and Project Planning=

Today's current constructs for implementing decisions and planning projects in educational environments takes little advantage of current methodologies active in other fields where changing conditions mean that changes must take place in a fast and efficient manner. One such field that was considered was the area of Computer Software Engineering; more specifically, the [|Agile software development] model provides a framework for quickly and efficiently keeping the end-user of a solution involved in the process of its creation so that as changes in the problem take place, changes can take place in the development process for the solution. While the [|Agile software development] model is efficient for development of software solutions for computers, an adaptation of the [|Agile Manifesto] has led to the development of a similar set of four principles by which the process used to make decisions and plan projects can be evaluated.

In decision making and project planning, Leadership 2.0 values:
 * Individuals and our Interactions with them rather than the process or tool that we are using
 * Working Solutions rather than a lengthy meetings or comprehensive documents
 * Collaboration with Teachers, Students, and other Administrators rather than deadlines and procedures
 * Quick Response to Change over following a plan

Problem Matrix
In discussing the Agile process, a set of parameters emerged by which a problem could be evaluated and a solution could be found.

Example:
This example is concerned with the problem of not receiving input or data as to how a solution to a problem has been implemented locally.

Problem: Though requested through mail, few responses come back to the district office concerning recent changes in school curriculum.

 * Condition || Barriers to Change (Yes...But) || User Stories (Yes...And!) || Resources to Facilitate Change ||
 * Lack of Data from Teachers, Students, Parents, Administrators || Lack of Time/Feasability || I **would like to** increase the frequency of responses from teachers, administrators, parents, and students concerning recent changes to curriculum || iPhone-based Survey, Web Forum, Facebook ||

By evaluating the problem, a condition is found in which data is lacking from Students and teachers. From that condition, we can evaluate the obstacles that need to be overcome by our current process in order to find a better and more efficient solution. The [|User Story] is a specific and pointed requirement for the solution that that must be met if the solution is going to solve our condition; our solution to this problem must address both a Lack of Data (our Condition) and the Lack of Time/Feasability (our Barrier). This [|User Story] could be one among many under the heading of our problem. As the problem is broken down into smaller components, small teams can be formed to find ways to address the problem. In this test case, our team found that a survey via iPhone to administrators, the start of a "curriculum change" web forum, or a Facebook survey could be ways to gather information from the community of people we need to test. In fact, this user story would most likely be broken down in the future so that individual solutions for teachers, students, parents, and administrators could be developed. Following this implementation, an evaluation should take place from which new user stories can be developed and new solutions could be found by new teams if and when needed.

More about User Stories
[|User Stories] are not meant to be an exhaustive exploration of a problem but are meant to be a quick and cheap means of identifying problems to be overcome and solutions that already work. By stating what it is that the end-user of the solution needs in simple, no-nonsense terms, the concerns of that user can be prioritized and reevaluated continuously throughout the development process and the solution which solves those problems will be efficient, streamlined, and robust. Following the development process, the testing of the implementation will result in more user feedback and can, if needed, begin the cycle again. Since anecdotal stories can be difficult to interpret, this sort of systematic deconstruction results in direct, actionable statements about a sentence or two long that take into account background knowledge and changes to the situations surrounding the problem. A set of seperate success criteria should also be included so that the suitability of the solution to the problem can be evaluated.

Agile methodologies favour face-to-face communication over comprehensive documentation and quick adaptation to change instead of fixation on the problem. Our User Stories achieve this by:
 * Being very short. They represent small chunks of value that can be implemented in a period of days to weeks.
 * Allowing developer and user to discuss requirements throughout the project lifetime
 * Needing very little maintenance
 * Only being considered at the time of use
 * Maintaining a close contact with the end-user throughout the process
 * Allow projects to be broken into small increments
 * Suited to projects where the requirements are volatile (change often) or are poorly understood. Iterations of discovery drive the refinement process.
 * May be easier to estimate effort in larger, more unwieldy projects

Success Criteria
Success Criteria are important in these projects. Agile calls them [|Acceptance Tests] but for our purposes, a larger concept of over-arching success criteria are necessary to properly evaluate the success of a solution. This sort of testing promotes many of Leadership 2.0's major principles and keeps administrators accountable to the people they are developing solutions and projects for. It also allows for more community interaction with higher levels of administration and breaks down barriers in the education system hierarchy allowing for a more associative social network within the education system. Parents, students, teachers, and administrators would all set these criteria as changes in policy and projects affect all levels of the education system.

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