Three simple facts to be accepted:
- It is impossible to gather all the requirements at the beginning of a project
- Whatever requirements you do gather are guaranteed to change
- There will always be more to do than time and money will allow
Agile Principle: regular delivery of working, tested software made up of your most important features each and every week.
- Break big problems down into smaller, simpler and more manageable milestones
- Focus on the really important stuff and forget everything else
- Make sure that what you are delivering works (lots of testing early and often)
- Constant looking for feedback
- Change course when necessary
- Become accountable (quality, schedule, budget)
If you like the visibility, have a passion for quality and a fierce desire to execute, working on an agile team can be personally very rewarding. In case the one week delivery is stressing you out, don’t worry about most agile teams start by delivering something of value every two weeks (really big teams every three).
Agile Principle: The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
In agile, the master story list is your project to-do list. It contains all the high-level features (user stories) your customer will want to see in their software.
It’s prioritised by the customer, it’s estimated by the development team, and it forms the basis of the project plan. An iteration is a 1 to 2 week period where you take your customers’ most important stories and transform them into running, tested software.
By tracking your velocity and using it as a predictor of how much you’ll get done in the future, you will keep your plans honest and your team from over-committing.
Agile Principle: Business people and developers must work together daily throughout the project.
Agile Principle: Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
The agile customer
It’s someone closely familiar with the business, who really cares what the software does, what it looks like, and how it works, and who is committed to guiding the team, answering questions, and giving feedback. He also set the priorities (from the business point of view), decides what gets built and when.
Read more: Jonathan Rasmusson. “The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)” Pragmatic Bookshelf