12 Principles of Agile Manifesto (Expectation vs Reality)

So, today I’ll tell you about 12 things (or principles, whatever) of agile manifesto (theory vs reality in our projects), here it goes:

1. Expectation: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Reality: We try our best to deliver product as fast as we can, but sometimes, unexpected thing happens.
2. Expectation: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Reality: We’re open to any changes, as long as it possible and fit with our timeline.
3. Expectation: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Reality: It’s 2 AM in the morning, and we’re still deploying.
4. Expectation: Business people and developers must work together daily throughout the project. Reality: Yeah, it’s true, we develop feature and they check if it fits with their criteria.
5. Expectation: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Reality: We’re team of motivated individuals, but we lost with other course’s deadlines.
6. Expectation: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Reality: We did several hackathons together.
7. Expectation: Working software is the primary measure of progress. Reality: We celebrate every feature deployment.
8. Expectation: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Reality: We’re trying to keep up with our product owner needs.
9. Expectation: Continuous attention to technical excellence and good design enhances agility. Reality: We never ever sacrifice technical excellence for agility.
10. Expectation: Simplicity — the art of maximizing the amount of work not done — is essential. Reality: It’s true.
11. Expectation: The best architectures, requirements, and designs emerge from self-organizing teams. Reality: It’s true?
12. Expectation: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Reality: We try our best? But still lacking in many areas.

That’s all. Personally, MeetU Engineering team has already implement most of it (or all of it), but before we knew this thing, we don’t realize that we’ve already implement it, how about your team?