VTransparency 3.0

Agile Methodology

Iterative, Incremental, Evolutionary
Efficient and face-to-face communication
Short Feedback Loop & Adaptation Cycle Focus on Quality

From The Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Agile: Translated

The meanings of the manifesto items on the left within the agile software development context are:

• Individuals and interactions: in agile development, self organization and motivation are important, as are interactions like co-location and pair programming.
• Working software: working software will be more useful and welcome than just presenting documents to clients in meetings.
• Customer collaboration: requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
• Responding to change: agile development is focused on quick responses to change and continuous development.

Adaptive vs. Predictive

Iterative vs. Waterfall

Code vs Documentation

Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

SCRUM

A flexible, holistic product development strategy where a development team works as a unit to reach a common goal. It challenges assumptions of the "traditional, sequential approach" to product development and enables teams to self-organize by encouraging physical co-location of all team members, as well as daily face-to-face communications.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called "requirements churn"), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.

The product at the end of the sprint is "done". This means the system that is integrated, fully tested, end-user documented, and potentially shippable.

• Single person responsible for maximizing the return on investment (ROI) of the development effort
• Final arbiter of requirements questions
• Accepts or rejects each product increment
• "When the product owner also happens to be "the boss", the invisible gun effect hampers self-organization and emergent leadership. People lacking real experience of team self-organization won’t see this problem, just as fish are unaware of water"

• Self-organizing / self-managing, without externally assigned roles
• Has autonomy regarding how to reach commitments

• Facilitates the Scrum process
• Helps resolve impediments
• Captures empirical data to adjust forecasts
• Keeps Scrum artifacts visible
• Has no management authority over the team (anyone with authority over the team is by definition not its ScrumMaster)

Daily Workflows

• Daily standup
• Sprint Task List
• Sprint Burndown Chart
• Indicates the total remaining team task hours within the sprint
• Re-estimated daily, thus may go up before going down
• Often misused as a management report. Discontinue if it becomes an impediment.
• Impediments List
• Impediments caused by issues beyond the team's control are considered organizational impediments.

Timeboxing

Instead of fixing the scope of the project, we are fixing the amount of time that we can dedicate to solve the problems at hand. There is some risk in developing new systems in the manner, so by limiting the amount of time spent it contains that risk.

Minimum Viable Product

The product with the highest return on investment versus risk. It has just those core features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent.

Daily Standup

Each day during the sprint, a project team communication meeting occurs.

The Daily Scrum is intended to disrupt old habits of working separately. Members should remain vigilant for signs of the old approach. For example, looking only at the ScrumMaster when speaking is one symptom that the team hasn’t learned to operate as a self-organizing entity.

Guidelines:

• All members of the development team come prepared with the updates
• The meeting starts precisely on time even if some development team members are missing.
• The meeting should happen at the same location and same time every day.
• The meeting length is set timeboxed to 15 minutes.
• Each team member answers three questions:
• What have you done since yesterday?
• What are you planning to do today?
• Any impediments/stumbling blocks?

Any impediment/stumbling block identified in this meeting is documented by the Scrum Master and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.

User Stories

A user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. This is how we'll define the functions a business system must provide. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard.

"As a role, I want goal/desire so that benefit."

"As who when where, I what because why."

As a user, I want to search for my customers by their first and last names.

As a non-administrative user, I want to modify my own schedules but not the schedules of other users.