Agile was a loose collection of techniques used that were immortalized in "The Agile Manifesto" that was written after a summit of software's leading minds.
On February 11-13, 2001, 17 software developers met in the Wasatch mountains of Utah to find what worked and what didn't with their different approaches to developing software. The Manifesto for Agile Software Development was what came out of that event and gave us the method companies employing coders use. Several members of that discussion went on to found the Agile Alliance, of which Blast Off Apps is a member.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the 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.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.NOTE: Blast Off Apps & Mission Command work through online communication portals and are available for video/phone calls 1 hour a week. This is due to high demand and we hope you are willing to overlook this slight tweak on the process. Thank you!
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Terms & Positions Defined
Acts as the coach responsible for facilitating and guiding the team. Mission Command handles this responsiblity, obtaining resources when required, and removing impediments that keep the team from doing their work. The Scrum Master role often encompasses the soft skills of project management more than planning and technical skills, which are often left to the team as a whole. It is important to note that this person is not necessarily the team’s manager. Rather, this role should reflect knowledge and responsibilities over rank.
Each "sprint" of development is only committed to (paid for) after your approval. After refining your backlog list (priorities), you will make a cut line. This is when your quote for the iteration will be generated through itemizing the app in a completely transparent, unrivaled manner to give you the most contorl and insight into the hard decisions needed to stay under budget.
Development sprints are ideally done in 1-2 week segments. The first iteration, your minimum viable product (MVP), will take longer (2-3 months avg.) due to the infrastructure needing built with code. This time to develop should become less and less over time, eventually landing on the target 1-2 weeks.
Represents a broad category of people who can be users, managers of users, operations, support, Portfolio Managers, other Agile teams with dependencies, executive team, investors, and more.
Development happens in Sprints. In SCRUM, there are Sprint review meetings and retrospectives to keep the cycle moving forward. Take a look at this overview of SCRUM to see how these operate.
A backlog is a list of features or technical tasks which the team maintains and which, at a given moment, are known to be necessary and sufficient to complete a project or a release:
- if an item on the backlog does not contribute to the project's goal, it should be removed;
- on the other hand, if at any time a task or feature becomes known that is considered necessary to the project, it should be added to the backlog.
These "necessary and sufficient" properties are assessed relative to the team's state of knowledge at a particular moment; the backlog is expected to change throughout the project's duration as the team gains knowledge.
The backlog is the primary point of entry for knowledge about requirements, and the single authoritative source defining the work to be done.
Behavior Driven Development (BDD) is a synthesis and refinement of practices stemming from Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD). BDD augments TDD and ATDD with the following tactics:
- thinking "from the outside in", in other words implement only those behaviors which contribute most directly to these business outcomes, so as to minimize waste
- describe behaviors in a single notation which is directly accessible to domain experts, testers and developers, so as to improve communication
- apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behavior, so that evolution remains cheap
In consultation with the customer or product owner, the team divides up the work to be done into functional increments called "user stories".
Each user story is expected to yield, once implemented, a contribution to the value of the overall product, irrespective of the order of implementation; these and other assumptions as to the nature of user stories are captured by the INVEST formula.
To make these assumptions tangible, user stores are reified into a physical form: an index card or sticky note, on which a brief descriptive sentence is written to serve as a reminder of its value. This emphasizes the "atomic" nature of user stories and encourages direct physical manipulation: for instance, decisions about scheduling are made by physically moving around these "story cards".
"Card, Conversation, Confirmation"; this formula (from Ron Jeffries) captures the components of a User Story:
- Card on a bulletin board that represents the work that is needed, giving tangible and durable form to what would otherwise only be an abstraction
- Conversation taking place at different times and places during a project between the various people concerned with a given feature of a software product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation
- Confirmation, finally, the more formal the better, that the objectives the conversation revolved around have been reached